Niedawno Intel zaprezentował nam nową serię procesorów z rodziny Xeon, o oznaczeniu "Phi" zbudowanych na bazie architektury MIC (Many Integrated Core). Pierwsza generacja tych układów o kodowej nazwie Knight Corner, będzie występować w trzech odmianach, dysponujących 57, 60 lub 61 rdzeniami x86, wytwarzanymi w 22nm procesie produkcji z wykorzystaniem tranzystorów tri-gate. Obecnie Intel ma już rewizję B0 tych procesorów, które otrzymają również 1.8-1.9MB pamięci L1, 28-30.5MB pamięci L2 oraz 3GB, 6GB lub 8GB RAMu typu GDDR5. Najmocniejsza odmiana otrzyma interfejs pamięci 512-bit, który zapewni przepustowość na poziomie 300GB/s.
Dodatkowo rdzenie x86 oraz pamięć będą pracować z różnymi częstotliwościami, w zależności od modelu, co dokładnie obrazuje poniższa tabelka.
Wracając do samej architektury MIC, warto nadmienić, że, w porównaniu do obecnie sprzedawanych wersji desktopowych procesorów Intela, nowe Xeony Phi wyglądem będą przypominać karty graficzne i otrzymają pamięć RAM typu GDDR5, której jest maksymalnie 8GB. Sam Knight Corner jest co prawda rozwinięciem projektu Larrabee, ale nie służył do renderowania grafiki 3D, a głównym rywalem MIC mają być układy Tesla od Nvidii, przeznaczone do przeprowadzania skomplikowanych obliczeń matematycznych (geologia, finanse, medycyna, itp.).
Według Intela Knight Corner ma ogromną przewagę nad rozwiązaniami Nvidii i AMD, której na imię architektura x86. Aby korzystać z mocy MIC nie trzeba bowiem znać narzędzi takich jak CUDA, przez co programowanie jest znacznie łatwiejsze, a kod nie odbiega znacząco od tego, który musimy napisać chcąc korzystać z zasobów CPU. Co więcej producent deklaruje wysoką wydajność swojego nowego produktu, która w obliczeniach podwójnej precyzji ma oscylować wokół 1 TFLOPa.
Z pewnością dla Nvidii pojawienie się tak groźnego rywala nie jest zbyt komfortową sytuacją, tym bardziej że już od dłuższego czasu na rynku jest już inny rywal - architektura GCN AMD, która również powstała z myślą o GPGPU.
K O M E N T A R Z E
Głupota... (autor: Kenjiro | data: 2/08/12 | godz.: 16:00) Programowanie wielowątkowe w kodzie x86 jest o niebo trudniejsze niż operacje wielotorowe robione w OpenCL, do tego dochodzi problem z wykorzystaniem wszystkich rdzeni... Jak dla mnie to głupota.
P.S. Jak można pisać o architekturze x86, że jest plusem, skoro to najgorsza z obecnie istniejących architektur? Marketoidzi pozamieniali się głowami z ...
Kenjiro, no fakt (autor: Duke Nukem PL | data: 2/08/12 | godz.: 17:30) Tylko dlaczego te x86 tak wypłynęło? Może dlatego że przez to iż był to na początku układ głęboko siedzący w koncepcji kalkulatorowych rejestrów był wyceniany niżej niż reszta procesorów? Motorola miała piękne procesory. Sama lista rozkazów była już piękna. Krótka i symetryczna dla pamięci i rejestrów. Po prostu zgrabna. Nie to co x86.
Był kiedyś taki Zilog, który mocno rozszerzył listę rozkazów x86 o piękne rzeczy ale niestety nie wybił się. I miał piękne peryferia. Niestety był nieco droższy i chyba dlatego chłam wypłynął na wierzch. Marketing panie, marketing. Liczy się taniość a nie jakość i solidna wizja prostoty.
@Kenjiro (autor: Promilus | data: 2/08/12 | godz.: 18:49) "Programowanie wielowątkowe w kodzie x86 jest o niebo trudniejsze"
A kto ci każe pisać w x86, od tego masz m.in. OpenMP z C++ ;)
"skoro to najgorsza z obecnie istniejących architektur"
pokaż wydajniejszą w tej cenie.
x86 wygralo bo (autor: pandy | data: 2/08/12 | godz.: 23:32) sprzet byl zgodny z i8080 zwlaszcza wersja i8088 mogla bez problemow korzystac ze wszystkich perfyeriow i8080 a bylo ich cale mnostwo (wiecej niz w Z80 i MC68K),
zostalo wybrane przez IBM wlasnie ze wzgledu na i8088 i latwiejsza w produkcji plyte glowna.
a pozniej juz sie potoczylo - zamiast innowacji nasladownictwo i tyle
OMFG (autor: LoneStarr | data: 3/08/12 | godz.: 00:24) Dalej ciągną ten wóz z węglem x86, ile to już lat? :/
Ciagna ale z orginalego x86 malo co zostalo (autor: pandy | data: 3/08/12 | godz.: 21:53) juz PII wprowadzilo translacje kodu x86 na kod RISC i Intel (i nie tylko Intel) w ten sposob zalatwia problem CISC - tak naprawde implementuje sie jako RISC wiele instrukcji a reszte w postaci mikrokodu (zreszta z mozliwoscia update)
@pandy (autor: Promilus | data: 3/08/12 | godz.: 22:10) "juz PII wprowadzilo translacje kodu x86 na kod RISC"
Nie jest to zupełnie prawda. Nie ma tam żadnego rdzenia RISC i translatora który zamienia rozkazy maszynowe CISC na wewnętrzne RISC, a ten znowu dekoduje do mikrokodu. Dekoder x86 od razu dekoduje do postaci mikrokodu, a jak ktoś się wyrwie z tym, że przecież mikrokod jest RISC to muszę ostudzić - tak, ale rozkaz CPU w architekturze RISC nie musi oznaczać 1 operacji w mikrokodzie. Prawda jest taka, że RISC też się już spasły i o ile wewnątrz dalej działa szybkie i proste jąderko, o tyle na zewnątrz już spaślaczek rośnie. Intel zaś x86 nie pogrubia zbytnio na zewnątrz, a przy okazji wewnątrz jąderko też już ładnie zapieprza - stąd nie ma większych już różnic w wydajności np. PPC vs x86 gdy jeszcze dekadę temu różnica była bardzo wyraźna.
@Promilus (autor: pandy | data: 4/08/12 | godz.: 13:12) RISC czy CISC to w tej chwili umowne - PII ma oczywiscie zaimplementowane sprzetowo znaczna czesc rozkazow, ma rowniez translacje rozkazow na mikrokod.
Inny przyklad ze stajni intela - P4 ze brakiem barrel shiftera i jego implementacja w mikrokodzie...
What made the 386 so special? Well, Intel did a number of things right. First they made the chip more orthogonal. What that means is that they extended the machine language instructions so that in 32-bit mode, almost any of the 8 32-bit registers could be used for anything - storing data, addressing memory, or performing arithmetic operations. Compare this to the 8086 and 80286 whose 16-bit instructions could only use certain instructions for certain operations. The orthogonality of the 386 registers made up for the extra registers in the Motorola chips, which specifically had 8 registers which could be used for data and 8 for addressing memory. While you could use an address registers to hold data or use data registers to address memory, it was most costly in terms of clock cycles.
@9 Pierwszy byl NexGen (autor: pandy | data: 5/08/12 | godz.: 12:20) bo Nx586 byl w 1994 roku, K5 bylo w 1996. I zdaje sie ze w artykule jest blad AMD kupilo NexGen'a po failu K5 i technologia NexGen'a byla uzyta w K6. W K5 AMD uzylo elementow swojego RISC'a AM29050.
@pandy (autor: Promilus | data: 5/08/12 | godz.: 15:35) Źle to rozumiecie. NexGen miał swój RISCowy rdzeń i używał translacji rozkazów x86 na ten rdzeń (gdzie każdej instrukcji RISC odpowiadała jedna instrukcja mikrokodu). Tak samo AMD w K5 użyło rdzenia AM29k i tłumaczyło rozkazy x86 na rozkazy tego rdzenia. Ale w K7 nie użyło ani rdzenia am29k, ani alphy, ani żadnego innego RISC. 8086 (czy 8051) także mimo modelu programowego CISC nie miał instrukcji mov x,y jako najniższych niepodzielnych mikrooperacji, a tylko TAKŻE z mikrooperacji składał to co miał dekodek obsługiwać. Cały pic z wojenką CISC vs RISC był taki, że CISC na większość operacji potrzebował wiele cykli, szczególnie jeśli dot. pamięci zewn, natomiast operacji RISC zazwyczaj wykonywały się w 1 cyklu, ale nieraz potrzeba było tych instrukcji więcej do zrealizowania tego samego działania. W początkach kompilatorów z tego powodu CISC miały drobną zaletę bo łatwiej się tłumaczyło taki C czy Pascal na kompleksowe instrukcje niż grupy prostych. Ale co się stało później? :) Ano proste. CISC dostał superskalarną potokową architekturę i W TYM WŁAŚNIE momencie różnice między RISC, a CISC zaczęły się zacierać, bo CISC także mógł kilka instrukcji naraz przetwarzać oraz także wypadkowo wychodził w okolicach 1instrukcję/cykl dla danego potoku. RISC ma nadal taką przewagę, że mniej tranzystorów trzeba do dekoderów, a dodatkowo mogą pracować zazwyczaj z wyższymi zegarami taktującymi, ale nie jest tak, że nagle od K5/NexGen w x86 siedzi RISC - to nieprawda.
@11 Nie bardzo rozumiem (autor: pandy | data: 6/08/12 | godz.: 22:36) w K5 AMD uzylo elementow architektury AM29K akurat to mieli - calkiem niezly CPU, z kolei NexGen mial cos wlasnego natomiast nie utozsamialbym RISC z konkretna ISA.
Generalnie RISC operuja na rejestrach wewnetrznych ktorych maja duzo, ich lista instrukcji jest prosta i zoptymalizowana by wiekszosc instrukcji byla wykonana bezposrednio w hardware. Z rozwojem technologi duza ilosc rejestrow zastapil cache i przewaga RISC zmalala.
Co do reszty prosze zwroc uwage na P4 ktory ma wyrozniony Execution Trace Cache - tu nie chodzi o RISC w stylu AM29K czy Alpha ale o koncept rozbijania instrukcji na mikroperacje (to akurat rozwiazanie znane od dawna wystarczy wspomniec bitslice processors takie jak np AM2900 - mikroprogramowane ktore mogly w teorii udawac dowolna ISA - nawet Rosjanie zrobili w ten sposob swoj pierwszy komputer osobisty Agat - zgodny z Apple II emulujac 6502 ktorego nie produkowali).
@pandy (autor: Promilus | data: 7/08/12 | godz.: 18:22) "Generalnie RISC"
Generalnie RISC i CISC odnoszą się do listy rozkazów procesora, a nie mikrooperacji czy samej struktury wewn. rdzenia. W przypadku CISC masz kilkadziesiąt rozkazów * kilka trybów adresowania i już robi się zasadniczo kilkaset realnych różnych dla procka instrukcji. W przypadku RISC było inaczej. Zazwyczaj było dużo rejestrów ze względu na to, że nie było możliwości operować bezpośrednio na danych w pamięci. I tak jeśli wezmę 8051 mogę każdą komórkę z pierwszych 128B traktować niemal jak rejestr - tzn. mogę dać etykietę DUPA i stosować inc DUPA i procek to wykona. W przypadku RISC najpierw muszę załadować zawartość DUPA do rejestru, zinkrementować go i zapisać spowrotem do komórki pamięci DUPA. Obecnie RISC się mocno rozrosły w tryby adresowania i instrukcje, a CISC mają register renaming, mikrofuzje itp. Zasadniczo więc przynależność jest głównie historyczna, albo bardzo umowna.
D O D A J K O M E N T A R Z
Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.
