- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- ZTE Blade A34 - nem a legélesebb kés a fiókban
- Redmi Note 13 Pro+ - a fejlődés íve
- Redmi Note 12 Pro - nem tolták túl
- Samsung Galaxy A55 - új év, régi stratégia
- Samsung Galaxy A54 - türelemjáték
- Android alkalmazások - szoftver kibeszélő topik
- Honor Magic5 Pro - kamerák bűvöletében
- iPhone topik
- Yettel topik
Hirdetés
-
Irányíthat-e atomfegyvereket az AI?
it Az USA politikusai sürgetik Kínát és Oroszországot, hogy rögzítsék: csak ember irányíthat atomfegyvereket, AI nem.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
ZTE Blade A34 - nem a legélesebb kés a fiókban
ma Visszautaztunk az időben a ZTE furcsa belépőajánlatával.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Gondolom nekik lesz tempósabb dedikált gyorsítójuk. Elképzelhető egyébként, itt még mindig elviszi a fogyasztási keret egy részét a procirész.
(#7) Fiery: Ez nem a Knights Landing ellenfele. Az AMD korábban is mondta már, hogy kipróbálták a sokmagos koncepciót. Egyrészt directory protokollt igényel, ami azt eredményezi, hogy a tranzisztorok felét csak a cache-be verik, illetve szimuláción sem működött több feladatban 20 magnál jobban a skálázódás. Ugyanezt egyébként az Intel is folyamatosan elmondja, hogy nem a maximális kihasználásra kell törekedni, hanem az optimálisra, mert a Xeon Phi-vel ma is előfordul, hogy kevesebb aktív mag több sebességet ad. Szerintem az AMD valami gyakorlatban is használható rendszert szeretne, aminek lehetséges a programozása.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nagymértékben meghatározza a rendszer működését a szálkezelés. A legfőbb oka annak, hogy a mai gyorsítók hardveres szálkezelést és hardveres szinkronizációt használnak az, hogy a programozó képtelen lenne biztosítani a manuális kezelésüket és szinkronizálásukat. A Xeon Phi esetében is látszik a probléma, mert se OpenMP, se OpenCL alól nem lehet igazán használni.
A Phi egy újszerű paradigmát igényel. Figyelembe kell venni az algoritmust és nem az a jó, ha mindegyik magot befogják, hanem az, ha annyit fognak be, amennyivel gyors lehet. Ha ez csak 10-20 mag akkor annyit, de érdemes limitálást figyelembe venni, mert sokszor ettől gyorsul. Ez az oka annak is, amiért a Xeon Phi az iparág által el van könyvelve szarnak. Pedig nem rossz, csak nagyon speciális programozást igényel.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ma az ipar arról beszél, hogy 48 000 Xeon Phi-t nem használ a Thiane-2, mert nem tudják befogni. Ez nem az első eset. Az első Knights terméket az Intel ki sem hozta, mert tudták, hogy rossz. A másodikat kihozták, majd mikor kiderült, hogy nem úgy működik ahogy ígérték megdobták a piacot egy OpenCL meghajtóval. Azokat a megrendelőket, akik direkt azért kértek Xeon Phi-t, hogy úgy használják ahogy az Intel ígérte és ne OpenCL-en keresztül. Mennyi bizalom maradt?
Nem az x86 miatt bukdácsol a Xeon Phi vonal, hanem leginkább amiatt, hogy azok a programozási paradigmák, amelyek kialakultak nem működnek rajta. A hardver egyébként működik az Intel assembly példakódjaival.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mivel a szálkezelés és a szinkronizáció nem változik, így a programozónak ugyanazt kell csinálnia.
Annyiban igen, hogy az Intel mondta, hogy a meglévő OpenMP kódok használhatók lesznek. Sokan ezért választották ezt a gyorsítót, mert az Intel így promótálta. Aztán amikor kiderült, hogy ez nem igaz, akkor kidobtak egy OpenCL-t rá. A gond az, hogy az OpenCL alatt a legtöbben úgy közelítik meg a Phi-t, mint a FirePro és a Tesla rendszereket. És ez okozza a rossz megítélést. Nyilván másra nehéz gondolnia egy programozónak, minthogy rossz a hardver, ha egy FirePrón és Teslán tökéletesen működő kód Phi-n nem működik.
Az Intelnek el kell magyaráznia a piacnak, hogy a Phi nagyon specifikus rendszer, amit sokkal nehezebb programozni, mint a GPGPU-kat. Ez biztosíthatná a Phi jövőjét.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Széles SIMD-ek esetében a koncepció ugyanaz. Az AMD és az NV megoldásai esetében annyi a különbség, hogy a programozónak nem kell törődnie a vektorizálással a SIMT modell miatt, míg az Intel koncepciójában ez egy kritikus rész.
Az Intel nem véletlenül hozott OpenCL-t a processzoraihoz. A helyzet az, hogy ezen egyszerűbb programozni széles SIMD-eket, mint vector intrinsics-szel. Nagyon sokan ezért szeretik az OpenCL-t, és nem feltétlenül a GPGPU-s lehetőségek miatt.
Ne gondold, hogy egyszerűbb vector intrinsics-szel 512 bites SIMD-eket kivágni manuális szinkronizálással 280+ szálra. Az Intelnek arra kellene figyelnie, hogy megértesse a programozókkal, hogy ez nem annyira könnyű, mint a GPGPU paradigmák, amelyeket ráadásul megszokott a piac. Ez sokat segítene a KNL helyzetén.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nekem mindegy, hogy az Intel oktat-e belőle vagy sem. Nekik nem lesz jó, ha nem tudják használni a hardvert.
Ki mondta, hogy a SIMD szar? Ez jó, csak nem olyan könnyű, mint a SIMT. És a Xeon Phi kihasználatlanságához nagyban hozzájárul az, hogy a programozók nem tudják hogyan kell programozni. Ez részben az Intel felelőssége, mert a "plusz két sor a meglévő OpenMP kódba és minden fasza lesz" szöveg mellé adhattak volna támpontot is.
Tehát ha meg tud írni a programozó két szálra egy 128 bites SSE2 kódot, akkor ebből következik, hogy 288 szálra is tudnia kell 512 bites AVX-et?
Hallgass meg egy pár Andrew Richards előadást. Ő dolgozott a Phi-n és megpróbálta meggyőzni az Intelt, hogy ez a koncepció nagyon nehéz lesz a programozóknak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem értem a PR katasztrófa részét. Az Intelnek azt kell megértetnie a programozókkal, hogy amit eddig tapasztaltak a FirePro vagy a Tesla rendszerekről az a Phi esetében nem teljesen igaz. Amit az egyetemen tanítanak az a Phi-nél nem teljesen igaz. Egyszerűen csak fel kellene erre hívni a figyelmet, és leírni, hogy mire kell optimalizálni. Nagyon sokszor elhangzik az előadásokon, hogy a mai vektorarchitektúráknál a függőségre nem kell figyelni, mert ez már nem limitálja a feldolgozást, de ez a Phi-re nem igaz. Ugyanígy a szinkronizálás és a szálkezelés. Majd megoldja a hardver? Egy csomó rendszer igen, de nem a Phi. Ha ezekről beszámolnak az pont azt szorgalmazza, hogy a programozó jobban megértse a hardvert.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Andrew Richards a CodePlay elnök-vezérigazgatója volt mindig is. Az Intel egy rakás magasan jegyzett és elismert szakmai zsenit felkért a projekthez, akik segítették a munkát. Ezek az emberek ugyanakkor eltávolodtak az Inteltől, amikor a cég nem fogadta meg a tanácsaikat. Ezek közül a legfőbb az volt, hogy dobják az x86-ot, mert nagyon öreg ISA, és nem is tervezték túl skálázódóra a memóriamodelljét. Persze az Intel kifizette a szakértelmüket attól, hogy nem fogadták meg a tanácsaikat, csak ezek az emberek nem akartak úgy a projektben részt venni, hogy tudták, hogy nem fog működni. Ezért a szerződésüket felbontották.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az x86 alapjait több éve rakták le. Természetes, hogy egy újabb tervezésű ISA jobb lehet nála. Ez egyszerűen csak a fejlődéssel megmagyarázható. Nem véletlenül cserélgetik a gyártók a GPU-architektúrák ISA-ját pár éves ciklusokban. Aki azt hiszi, hogy ez megkerülhető az előbb-utóbb belefut egy óriási falba.
Hogyan oldja meg a hardver? Ezek szerint a KNL csak emulálja az x86-ot? Van benne egy új ISA, amit már skálázásra terveztek hardveres szálkezeléssel és szinkronizálással? Ez nekem új információ.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Andrew Richards az iparág egyik legelismertebb koponyája a complier technológiák területén. Ha ő nem képes valamire, akkor nem sokan. Nem véletlenül szerződtette pont őt az Intel anno. Drágán dolgozik, de pontosan tudták, hogy szakmájában ő a legjobb.
Az Intel arra kérte őket, hogy tanáccsal lássák el a mérnökeiket. Ezek a szakemberek pedig megtették a legjobb tudásuk szerint. Az már az Intel saját döntése, hogy nem fogadták meg a tanácsaikat. Nyilván a vezetőség gazdaságilag vizsgálta a kérdést, míg a szakemberek technikailag írták le a helyzetet, hogy egyáltalán az, amit az Intel elgondolt működhet-e. Ők azt mondták, hogy nem, és az eddigi gyakorlati produkcióból is az derült ki, hogy igazuk volt. De nyilván a pénzügyi szakemberek jobbnak látták, ha nem hallgatnak a mérnökökre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#58
Abu85
HÁZIGAZDA
Balala2007
#56
Abu85
HÁZIGAZDA
válasz
Balala2007
#56
üzenetére
A kulcsszó a socket. Négyutas rendszerben nincs igazán gond. Egy lápkán belül jönnek elő a limitek. Ezek is kezelhetők a gyorsítótárak méretének extrém növelésével, csak ez nem feltétlenül kifizetődő, mert egy újabb ISA-val meg feldolgozókat is építhetsz ugyanarra a területre.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Li-Shiuan Peh professzornak volt egy előadása, ahol beszélt róla, hogy a cache-koherencia azonos szinten borzalmasan nehéz egy bizonyos magszám felett. A több socket azért működik, mert a cache-koherencia többszintű. Például, ha van négy processzorod, akkor két mag közötti kommunikációra a hardver szintjén kisajátítják a procimagok az összeköttetésre szolgáló buszt. Ezzel 8 mag közötti kommunikáció oldható meg 4 socket esetében egyszerre (socketenként 2-2 mag). De ha ugyanannyi mag csak egy foglalatban, egy processzorban van, akkor már 2 magra korlátozódik a busz kisajátítása. Ez limitálja a rendszert.
(#60) Fiery: Több céget és szakembert bíztak meg. Egyébként minden külsős ugyanazt ajánlotta, még Michael Abrash is. A pénzügyi szakemberek ezzel nem értettek egyet.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az összeköttetés típusa nem annyira lényeges, mert az csak a sebességre van hatással. A buszt így is ki kell sajátítani a szinkronizációra.
A KNL biztos nem snoopingot használ. Egyetlen Xeon Phi-re sem jó ez a megvalósítás. A directory protokollt alkalmazza az Intel bizonyos magszám felett. Ez lassabb, mint a snooping, illetve sokkal több tranyót visz el, de a snooping meg nem skálázódna ennyire sem.Andrew Richards egyszer leírta a sztorit, csak az Intel annyira befenyítette, hogy mindenhonnan letörölték. De abban egyébként volt szó róla, hogy az Intel saját mérnökeivel és a többi külsős szakemberrel együtt ajánlották a vezetőségnek, hogy dobják az x86-ot, mert nem fog működni. A pénzügyi vezetők álláspontja az volt, hogy csinálják meg az eredeti tervet és majd lenyomják a piac torkán.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
ph A 2016 végén érkező lapka gyorsítókhoz hasonló előnyt kínálna a mély integráció előnyével fűszerezve.
- Autós topik látogatók beszélgetős, offolós topikja
- Politika
- Synology NAS
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Milyen billentyűzetet vegyek?
- Apple notebookok
- Kerékpárosok, bringások ide!
- Otthoni hálózat és internet megosztás
- Mibe tegyem a megtakarításaimat?
- ZIDOO médialejátszók
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen