Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Takže to vypadá, že grafiku se zavrhli, tak co s načatou včelkou Májou (Larra Bee) :)
Tak to vyzerá, že Intel už opúšťa aj klasické binárne násobky v štruktúre chipov
"...61 výpočtových blokov..."
"...zvýši až na 62..."
To čo sú za počty boha jeho?!
VR-Zone tvrdí, že 62 je maximum, co fyzicky nese čip, ale to číslo je tak nekulaté, že jsem ten údaj radši nepřebíral, dokud se nepotvrdí i z jiných zdrojů.
kypec: Asi jich mají fyzicky 64 a tvrdě pracují na snížení zmetkovosti.
taky mi to tak připadá
Jednoznačná výhoda Phi bude ta kompatibilita - přecijen je to víceméně x86 procesor, takže skutečně stačí znovu zkompilovat zdrojový kód (ti, jenž jej zahodili si budou trhat vlasy) pro novou architekturu a všechno může pokračovat. Na tomhle CUDA (ta už je trochu v pohybu) a Steam troskotá.
Jak jste na tohle prosimvás přišel? Instrukční sada je dnes zcela irelevantní, protože stejně nikdo nepíše kód v asembleru. Pokud pouze zkompilujete kód pro Phi, poběží 10x pomaleji než na CPU, protože poběží v jednom vlákně. Hlavní problém je spíš v úpravě algoritmu, tak aby mohl běžet ve více vláknech.
Ne.
Nikdo neprogramuje v assebleru, mluvím tu o vyšším programovacím jazyku, jako třeba C++. Nevím co používají tady. Nicméně aplikace (třeba Windows Kalkulačka), která běží na x86, aby běžela na CUDA, by musela být značně upravena. Ale pro Intel Phi, tedy skupinu x86 procesorů, je potřeba jen pár kosmetických změn (třeba mohou být jiné flagy procesoru, pořadí kroků jedné instrukce atp.), takže stačí, aby někdo sestrojil kompiler pro Phi (o to se Intel rád postará) a může se vesele pracovat.
Optimalizace pro více jader je věc druhá. Jelikož už teď máme logicky 16-ti jádrový (8 * HT) serverový Xeon, některé apliakce by s tím už mohly počítat a jádra zjišťovat automaticky a přizpůsobit se. Ovšem problém je zde stejný - jádra jsou nyní fyzicky oddělena a komunikují společně jnak, stejně tak se k nim může odlišně přistupovat. Všechny tyhle rozdíly řeší kompilace softwaru (ze zdrojového kódu) pro požadované architektury.
Nelze ale jednoduše vzít zdroják aplikace pro x86 procesor a překompilovat to na CUDA. Kdyby tohle šlo, jsme asi trochu jinde.
Jenže ta skupina x86 procesorů má vcelku ubohý výkon, srovnatelný s obyč CPU, pokud nebude využívat pro výpočet vektorové jednotky. Takže i pro Larrabee je nutné výpočet přepsat tak, aby mohl využít výpočetní výkon, který Larabee má.
klid. uvidíme na podzim v aplikačních testech ;)
Mě se docela zamlouvá "odhad", že je to skupina ubohých x86 procesorů, používaných jako x86 procesory, s výkonem 1+ Tflop. Pokud ano, je to bomba. Pokud ne, bude se pro dohnání jak ty říkáš omezit nutnou úpravou, což ji připraví o nespornou výhodu.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.