VISC lepsza niż CISC i RISC?

[KopalniaWiedzy.pl 357]

Niedawno założona firma Soft Machines zaprezentowała podczas Linley Microprocessor Conference nową architekturę nazwaną VISC. Przedsiębiorstwo twierdzi, że jest ona znacznie bardziej wydajna od obecnie używanych CISC i RISC.

Architektura VISC pozwala na wykonanie 3-4 razy więcej instrukcji w cyklu, co oznacza, że zarówno w zastosowaniach jedno- i wielowątkowych jest 2-4 razy bardziej wydajna niż współczesne architektury - czytamy w relacji prasowej. Architektura VISC bazuje na koncepcji 'wirtualnych rdzeni' i 'wirtualnych wątków sprzętowych'. To nowe podejście pozwalające na dynamiczną alokację i współdzielenie zasobów między rdzeniami. Mikroprocesory korzystające z architektur CISC i RISC korzystają z 'rdzeni fizycznych' i 'wątków programowych' przez co są ograniczone wydajnością tranzystorów, częstotliwością pracy i zapotrzebowaniem na energię - stwierdzają przedstawiciele Soft Machines.

Oczywiście do twierdzeń nieznanych firm, nawet jeśli pochodzą z Krzemowej Doliny, należy podchodzić sceptycznie. Jednak wagi słowom Soft Machines dodaje fakt, że w przedsiębiorstwo zebrało już 125 milionów dolarów dofinansowania, a wśród jego inwestorów są m.in. Samsung Ventures, AMD oraz Mubadala, firma z Abu Zabi, która jest właścicielem Globalfoundries.

« powrót do artykułu

[Astroboy 34]

 

 

Architektura VISC pozwala na wykonanie 3-4 razy więcej instrukcji w cyklu

 

Ciekawe. Jeśli taki typowy ARM (RISC jak najbardziej) wykonuje z założenia jedną instrukcję w cyklu, to czyżby tu chodziło o jakieś efekty kwantowe?

[Fred Onizuka 8]

Ogólnie, z tym wykonywaniem wielu instrukcji w jednym cyklu, chodzi o to, że procesor wykonuje jednocześnie kilka kolejnych instrukcji. Po zaladowaniu pierwszej instrukcji, ładowana jest druga (trzecia, czwarta itd), bez czekania na pierwszą. Oczywiście, kolejne instrukcje mogą się wykonać tylko wtedy, gdy nie mają być w nich użyte wyniki z poprzednich, które się jeszcze nie wykonały. Mimo, że cały cykl od chwili załadowania to wykonania pojedynczej instrukcji trwa kilka cykli, to ze względu na równolegle ich wykonywanie, daje to średnio powyżej jednej instrukcji na cykl.

Ta metoda jest stosowana od dawna i dość dobrze dopracowana, więc nie sądzę, by dało się ją jeszcze jakoś znacząco ulepszyć. A czy będą to rdzenie wirtualne, to nie ma to większego znaczenia - i tak, ostatecznie, będą to wykonywać "fizyczne" rdzenie. 

[Astroboy 34]

 

 

daje to średnio powyżej jednej instrukcji na cykl.

 

Nie wiem, nie znam się, ale dobry RISC przetwarza JEDNĄ instrukcję na cykl. Więc w czym ma być lepszy VISC? Oczywiście wiem, że naciskają programiści.

[Jajcenty 314]

Nie wiem, nie znam się, ale dobry RISC przetwarza JEDNĄ instrukcję na cykl. Więc w czym ma być lepszy VISC? 

W tym. że przetwarza więcej niż jedną instrukcję na cykl. No wiesz, ortodoksyjne podejście do liczb,  więcej niż jedna instrukcja na cykl to więcej niż jedna instrukcja w cyklu. Jeśli cykle są równe, to procesor wykonujący więcej instrukcji w cyklu możemy podejrzewać o bycie wydajniejszym od procesora o mniejszym współczynniku instrukcji/cykl. 

[Astroboy 34]

Ups. Potknąłem się; zabolało. Myślę, że to dobra ilustracja tego, czym kończy się więcej niż jedna instrukcja na cykl.

[Fred Onizuka 8]

Niestety, niefortunnie użyłem słowa "cykl" do opisu okresu od pobrania instrukcji do jej wykonania, przez co całe zdanie jest mało zrozumiałe. Mimo, iż przeczytałem tekst kilka razy przed wysłaniem, to zorientowałem się dopiero po fakcie (a nigdzie nie zauważyłem opcji umożliwiającej edycję wysłanych komentarzy).

 

Cyt: "Mimo, że cały cykl od chwili załadowania to wykonania pojedynczej instrukcji trwa kilka cykli, to ze względu na równolegle ich wykonywanie, daje to średnio powyżej jednej instrukcji na cykl."

[Jajcenty 314]

Ups. Potknąłem się; zabolało. 

 

Niepotrzebnie. Wszystkie moje komentarze są życzliwe^* i zakończone dużą liczbą uśmiechów i oczek. Nie umieszczam ich z wrodzonej  oszczędności. Z drugiej strony jednak przyznasz sam, że przepuścić taką okazję....

 

^*chyba że nie są, ale wtedy adwersarz zwykle nie ma wątpliwości.

[Fred Onizuka 8]

Ehh, teraz widzę, że jednak jest opcja edycji...  Przychodzi mi do głowy tylko jedno słowo: osioł 

[Astroboy 34]

Fred, całkowicie niepotrzebnie; na forum czasem bywają życzliwi (albo bywalcy bywają życzliwi).

Jajcenty: wiem; i przyznaję rację.

[thikim 119]

Tu jest opis VISC i ma to sens:

http://www.dobreprogramy.pl/VISC-to-tyle-wirtualnych-rdzeni-w-procesorze-ile-akurat-potrzeba,News,58763.html

 

A czy będą to rdzenie wirtualne, to nie ma to większego znaczenia - i tak, ostatecznie, będą to wykonywać "fizyczne" rdzenie.

No właśnie ma to zasadnicze znaczenie kiedy okazuje się że sprzętowo nie tak łatwo zbudować i zgrać wiele rdzeni, a potem okazuje się że optymalne dla takiej a takiej grupy instrukcji jest rdzeni 5 a dla innej 11 a mamy liczbę rdzeni CONST a VISC mamy liczbę VAR. Do tego dodajmy częsty postój nieużywanych rdzeni. Tutaj cała moc idzie w używane rdzenie.

Dobry pomysł.

[wilk 103]

Problem w tym, że zarządzanie tym także będzie kosztowne (czas/energia) zaś fizycznie na chipie i tak jest stała, określona liczba jednostek przetwarzających, wyznaczająca granicę możliwości. Z artykułu DP wynika, że będzie to jednak manager potoków (obecnych standardowo w RISC) pozwalający na lepszy przydział zasobów, więc zmniejszenie CPI będzie równie wirtualne, niemniej zapowiada się interesująco.

[thikim 119]

Napisali że zarządzanie to 5 % czyli mało. Nawet układy fizyczne potrzebują jakiegoś czasu/energii na zarządzanie.

Ilość jednostek fizycznie oczywiście jest stała ale jeśli jest to pełna wirtualizacja to po prostu możemy mieć bardzo dużo słabych jednostek. Więc to nie liczba jednostek jest problemem ale moc całego układu.

Obecnie problem polegał na fizycznym wykonaniu. Tu nie ma tego problemu.