- Honor Magic6 Pro - kör közepén számok
- QWERTY billentyűzet és másodlagos kijelző is lesz a Titan 2-ben
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Amazfit Active 2 NFC - jó kör
- Yettel topik
- Apple iPhone 16 Pro - rutinvizsga
- Google Pixel topik
- iPhone topik
Új hozzászólás Aktív témák
-
Fiery
veterán
Egy Haswell-EP-szeru dual ring-bus-nal nem tul valoszinu, hogy ki kellene sajatitani a teljes buszt 2 mag kozotti szinkronizacio eseten
"A KNL biztos nem snoopingot használ. Egyetlen Xeon Phi-re sem jó ez a megvalósítás"
Megint osszemosod a Knights Cornert es a Knights Landinget, holott mar tobbszor leirtam, hogy nem sok kozuk van egymashoz. De feladom, ha Te szakmailag ugy gondolod, hogy egy kartyara pakolt, dedikalt RAM-mal rendelkezo, nyakatekert Linux implementacioval meghajtott, sajat egyedi utasitaskeszlettel (LRBNI) biro, in-order P54C architektura kore epulo (GP)GPU-t egybemosol egy socketelt CPU-val, ami out-of-order Silvermont architekturara epul, a rendszermemoriat hasznalja, tekintelyes meretu es sebessegu near memory-val rendelkezik, es standard utasitaskeszlet architekturara (x86 + AVX-512) epul, akkor legyen ugy.
"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."
Mint ahogy fentebb leirtam, Intel = x86, es aki ilyet ajanl az Intelnek, annak elgurult a gyogyszere.
-
Fiery
veterán
Iszonyatosan leegyszerusited a dolgokat. Nem mennék bele a reszletekbe, de lenne egy fontos kerdesem: milyen osszekottetes van a CPU-tokon belul a magok kozott, es milyen osszekottetes van az alaplapon a CPU-foglalatok kozott? Ugyanaz a 2? Pont-pont mindegyik, vagy ring-bus mindegyik?
Mert ha nem ugyanaz, akkor nem ertem, miert kellene oket egymassal szembeallitani. Raadasul, semmi garancia arra, hogy a snooping es cache koherencia pontosan ugyanugy mukodik a KNL-nel, mint manapsag mondjuk egy Xeon E5-nel. Siman lehet, hogy idovel le kell mondanunk az x86 platformokon (is) a teljes cache koherenciarol, a teljesitmeny novelese erdekeben. Onnantol pedig ertelmet veszti az a nyavalygas, amit csinalsz a core skalazas vs. cache koherencia problema miatt -- ami egyebkent sem feltetlenul okoz olyan oriasi problemat, lasd a fentebb idezett ZLib skalazodasi lista. A Westmere-EX egyszerre sokmagos (socketenkent 10 mag) es 4 socketes, tehat eleg sokretu a snooping, megis tud skalazodni. Es nem 4 vagy 8 magrol beszelunk, ugyebar."Több céget és szakembert bíztak meg. Egyébként minden külsős ugyanazt ajánlotta, még Michael Abrash is."
Es mindegyik cegrol pontosan tudjuk, hogy mit ajanlott? Ezek tok nyilvanosan mentek? Azt is tudjuk, az Intel mernokeinek mi volt az allaspontja? Azt is tudjuk, a felsovezetesnek mi volt az allaspontja? Azt is tudjuk, ahhoz kepest, amit ajanlottak, ill. ahhoz kepest, hogy milyen volt az elozo generacio, pontosan hol is helyezkedik el a KNL? Mert ugye ha azt vesszuk, hogy a javaslat az volt (bar kizart, hogy egyetlen javaslat lett volna), hogy csinaljanak egy klasszikus GPU-t (masoljak le a GCN-t, hiszen mindannyian tudjuk, hogy annal jobb nincs es nem is lesz
![;]](//cdn.rios.hu/dl/s/v1.gif)
); es a Knights Corner-t hagyjak a francba, akkor nem lehet azt mondani, hogy a KNL-nel egyertelmuen erre vagy arra huzott az Intel. Akarhogy probalod beallitani annak, a KNL nem a Knights Corner pepitaban, hanem egy teljesen uj architektura, ami -- ahogy fentebb is irtam -- sokkal jobban hasonlit egy Xeon E5-re (Haswell-EP), mint egy Knights Cornerre. Ennyi erovel a Conroe-t is el lehetett volna asni elore, annak fenyeben, hogy a NetBurst mennyire nem jott ossze -- csak ugye tok mas architektura volt a Conroe, tehat ertelmes ember nem a NetBurst alapjan derivalta le a Conroe potencialis kepessegeit.Azt sem igazan ertem, miert kellene mindenkinek GPU-t keszitenie. Mi van, ha valamilyen problemat, problema kort mas megoldassal is ugyanolyan jol meg lehet oldani? Tudtommal mar manapsag is vannak, akik inkabb egy sokmagos Xeon E5/E7-re szavaznak, Tesla helyett, mert mondjuk a Haswell-EP/EX architektura jobban fekszik az igenyeikhez (pl. ray-tracing).
-
Fiery
veterán
Egyre viccesebb, amiket irsz. Lassuk csak, mi tortent. Az Intel megbizott egy ceget, hogy adjon tanacsokat GPU compiler temaban. Esetleg -- ezt nem tudjuk ugye -- megbizott me'g nehany ceget, plusz vannak ugye sajat mernokei is, akik biztos nem zsenik (szerinted), biztos nem nagy koponyak (szerinted). Mindegyik szakerto/szakember mond valamit, hogy szerintuk mi lenne a jo megoldas. Aztan az Intel ugy dont, hogy marad az egyik megoldasnal a sok kozul, es megkoszoni mindenkinek a munkat, a kulso szakertoket kifizeti, mindenki megy az utjara, mindenki orul. Ezutan az egyik kulso szakerto elkezdi fikazni az Intelt, mert nem az o megoldasat valasztotta a sokfele opcio kozul. Vilagos, csak ez az ember lehet a zseni a sok szakerto kozul
Azert megneznem a CodePlay uzleti eredmenyet, es mondjuk melletennem az Intel uzleti eredmenyenek, es aztan csinaljuk meg ugyanezt 10 ev mulva, amikorra a KNL kapcsan hozott "rossz" dontes csodkozeli allapotba juttatja az Intelt, mikozben a CodePlay tobbtiz milliard dollaros eves forgalmat general 
-
#56
Balala2007
tag
Abu85
#13
Balala2007
tag
szimuláción sem működött több feladatban 20 magnál jobban a skálázódás
Ez az AIDA64 ZLib tesztje egy 4 socketes Westmere-EX-en, 30MB L3-mal. Minden thread 32MB tomorites. En erre ra merem mondani, hogy az x64 legalabb 40 core-ig egesz jol skalazodik.
# 0 Pmask:0x0800000000000000:0000000000000000 T: 1 : 28.572 MiB/sec( 1.00000)
# 1 Pmask:0x0a00000000000000:0000000000000000 T: 2 : 57.136 MiB/sec( 1.99970)
# 2 Pmask:0x0a80000000000000:0000000000000000 T: 3 : 85.613 MiB/sec( 2.99642)
# 3 Pmask:0x0aa0000000000000:0000000000000000 T: 4 : 114.029 MiB/sec( 3.99087)
# 4 Pmask:0x0aa8000000000000:0000000000000000 T: 5 : 142.716 MiB/sec( 4.99490)
# 5 Pmask:0x0aaa000000000000:0000000000000000 T: 6 : 171.148 MiB/sec( 5.98998)
# 6 Pmask:0x0aaa800000000000:0000000000000000 T: 7 : 199.931 MiB/sec( 6.99735)
# 7 Pmask:0x0aaaa00000000000:0000000000000000 T: 8 : 228.132 MiB/sec( 7.98436)
# 8 Pmask:0x0aaaa80000000000:0000000000000000 T: 9 : 256.596 MiB/sec( 8.98057)
# 9 Pmask:0x0aaaaa0000000000:0000000000000000 T: 10 : 285.006 MiB/sec( 9.97489)
# 10 Pmask:0x0800008000000000:0000000000000000 T: 2 : 57.115 MiB/sec( 1.99896)
# 11 Pmask:0x0a0000a000000000:0000000000000000 T: 4 : 114.222 MiB/sec( 3.99764)
# 12 Pmask:0x0a8000a800000000:0000000000000000 T: 6 : 171.293 MiB/sec( 5.99506)
# 13 Pmask:0x0aa000aa00000000:0000000000000000 T: 8 : 228.555 MiB/sec( 7.99927)
# 14 Pmask:0x0aa800aa80000000:0000000000000000 T: 10 : 285.620 MiB/sec( 9.99653)
# 15 Pmask:0x0aaa00aaa0000000:0000000000000000 T: 12 : 341.518 MiB/sec( 11.95272)
# 16 Pmask:0x0aaa80aaa8000000:0000000000000000 T: 14 : 398.875 MiB/sec( 13.96017)
# 17 Pmask:0x0aaaa0aaaa000000:0000000000000000 T: 16 : 455.253 MiB/sec( 15.93333)
# 18 Pmask:0x0aaaa8aaaa800000:0000000000000000 T: 18 : 512.796 MiB/sec( 17.94727)
# 19 Pmask:0x0aaaaaaaaaa00000:0000000000000000 T: 20 : 567.009 MiB/sec( 19.84465)
# 20 Pmask:0x0800008000080000:0000000000000000 T: 3 : 85.326 MiB/sec( 2.98632)
# 21 Pmask:0x0a0000a0000a0000:0000000000000000 T: 6 : 171.413 MiB/sec( 5.99927)
# 22 Pmask:0x0a8000a8000a8000:0000000000000000 T: 9 : 257.052 MiB/sec( 8.99666)
# 23 Pmask:0x0aa000aa000aa000:0000000000000000 T: 12 : 341.985 MiB/sec( 11.96908)
# 24 Pmask:0x0aa800aa800aa800:0000000000000000 T: 15 : 427.328 MiB/sec( 14.95598)
# 25 Pmask:0x0aaa00aaa00aaa00:0000000000000000 T: 18 : 511.770 MiB/sec( 17.91135)
# 26 Pmask:0x0aaa80aaa80aaa80:0000000000000000 T: 21 : 595.182 MiB/sec( 20.83067)
# 27 Pmask:0x0aaaa0aaaa0aaaa0:0000000000000000 T: 24 : 683.108 MiB/sec( 23.90797)
# 28 Pmask:0x0aaaa8aaaa8aaaa8:0000000000000000 T: 27 : 762.421 MiB/sec( 26.68385)
# 29 Pmask:0x0aaaaaaaaaaaaaaa:0000000000000000 T: 30 : 842.788 MiB/sec( 29.49659)
# 30 Pmask:0x0800008000080000:0000000000080000 T: 4 : 113.341 MiB/sec( 3.96681)
# 31 Pmask:0x0a0000a0000a0000:00000000000a0000 T: 8 : 228.124 MiB/sec( 7.98408)
# 32 Pmask:0x0a8000a8000a8000:00000000000a8000 T: 12 : 342.240 MiB/sec( 11.97800)
# 33 Pmask:0x0aa000aa000aa000:00000000000aa000 T: 16 : 456.621 MiB/sec( 15.98119)
# 34 Pmask:0x0aa800aa800aa800:00000000000aa800 T: 20 : 568.893 MiB/sec( 19.91059)
# 35 Pmask:0x0aaa00aaa00aaa00:00000000000aaa00 T: 24 : 681.146 MiB/sec( 23.83932)
# 36 Pmask:0x0aaa80aaa80aaa80:00000000000aaa80 T: 28 : 790.318 MiB/sec( 27.66022)
# 37 Pmask:0x0aaaa0aaaa0aaaa0:00000000000aaaa0 T: 32 : 898.272 MiB/sec( 31.43848)
# 38 Pmask:0x0aaaa8aaaa8aaaa8:00000000000aaaa8 T: 36 : 1009.439 MiB/sec( 35.32917)
# 39 Pmask:0x0aaaaaaaaaaaaaaa:00000000000aaaaa T: 40 : 1112.584 MiB/sec( 38.93913) -
Fiery
veterán
Tok mindegy, mennyire archaikus az x86, az Intel akkor is ragaszkodik hozza. Ezt el kell fogadni, mint tenyt, nem erdemes ez ellen harcolni vagy ezzel a dontessel vitatkozni. Amugy meg, ha megnezed pl. az ultramobil piacot, az x86 kozel sem szerepel annyira rosszul, mint sokan szeretnek hinni
A megoldast arra ertettem, hogy ha nem akar valaki a szalkezelessel foglalkozni, akkor hasznalhat OpenCL-t. Nem hardveres megoldaskent gondoltam ezt, hanem nyilvan szoftvereskent. Es az, hogy mennyire lenyeges vagy sem a hardveres szalkezeles, az majd a gyakorlatban ki fog derulni. De az alapjan, hogy a mostani 2/4/8 utas Xeon E5/E7 prociknal nem hallani, hogy annyira nagy problema lenne a 72+ szal kezelese, nem gondolnam, hogy a KNL-en hirtelen ez most elobukkanna, mint megoldhatatlan problema. Hiszen a KNL vegeredmenyben nem mas, mint egy Xeon E5, csak tobb magja van, nagyobb cache-ei, 4x HTT, es AVX-512-t tamogat. Ezert sem ertem, miert kell allandoan a mostani Xeon Phi-hez hasonlitani. Sokkal-sokkal tobb koze van a Haswell-EP/EX vonalhoz, mint a Knights Corner-hez.
-
Fiery
veterán
Mar megint jossz a zseni kifejezessel. Mibol szurted le, hogy Andrew Richards zseni? Volt egy olimpia a zseniknek, es ott o elodontos volt? Mibol derivaltad le, hogy epp ra kellene hallgatni, es nem mondjuk arra a par emberre, aki Intel reszvenyt vasarol, es ezzel tamogatja a KNL projektet? Ha a KNL egy borzalmas katasztrofanak nezne ki, akkor szerinted a reszvenyesek/igazgatotanacs nem kezdett volna el morgolodni, hogy miert pont abba a projektbe teszik a penzt az Intelnel, ahelyett, hogy mondjuk felvasarolnak az nVIDIA-t, es igy megszereznek mondjuk a CUDA-t?
Miert pont Andrew Richards a legnagyobb koponya, akinek minden szavat el kellene hinni, es minden joslatat keszpenznek kellene venni?"Ezek az emberek ugyanakkor eltávolodtak az Inteltől, amikor a cég nem fogadta meg a tanácsaikat. [...] Ezért a szerződésüket felbontották."
Aham, tehat bepoccentek, es most fikazzak az Intelt. Tehat amit ok mondanak, az 100%-ig objektiv. Vilagos.
"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."
Tehat tancsoltak valamit az Intelnek, ami nyilvanvaloan hulyeseg, hiszen Intel = x86, ergo sosem fogjak eldobni. Megprobaltak, nem kellett senkinek (Itanium), most miert gondolja barki is azt, hogy az x86 eldobhato? Aki meg ilyeneken gondolkozik (Intel minusz x86), annak en egyetlen szavat sem vennem komolyan, ugyanis eleve komolytalan (szak)emberrol van szo. Ennyi erovel probald meg a Microsoftot lebeszelni a Windowsrol, vagy a VW csoportot probald meg lebeszelni a Golf es Passat markanevekrol
-
Fiery
veterán
A PR katasztrofa akkor alakulna ki, ha az Intel arrol kezdene beszelni, hogy az x86 nem (eleg) jo, es helyette hasznalj valami mast. Nem, ilyen nem fordulhat elo. Az Intel az x86-rol szol, akarcsak a Microsoft a Windowsrol. A Microsoft sem fogja sosem azt mondani, hogy a Windows sz*r, hasznalj helyette mast. Az megint mas kerdes, ha csinalnak egy szuboptimalis (oke, mondjuk ki, sz*r) termeket egy adott koncepciora, majd tobb generacion at foldozgatjak, mig vegul osszeall, es hasznalhato lesz. De me'g ebben az esetben sem lehet azt mondani, hogy hasznalj mast, es nem lehet hatraarcot csinalni. Jo pelda erre a Xeon Phi is, de pl. a Windows is. A Windows Vistanal felresiklott az Microsoft, de nem adta fel, es a Windows 7-re osszerakta a dolgokat, ami megint jo lett. A Windows 8 is felrecsuszott, jott a korrekcio a Windows 8.1-gyel, de me'g mindig nem lett (eleg) jo. Vegul a Windows 10-zel kerulnek a helyere a dolgok (remelhetoleg), _de_ ez nem jelenti azt, hogy a Windows 8.x alapjan elore el lehetne konyvelni f*snak a Windows 10-et. Szerintem varjuk meg mindkettot (KNL, Windows 10), mielott az elozo generacios benazasok okan elore eltemetjuk oket.
"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."
Mintha el sem olvasnad, amit irok
Direkt leirtam, hogy _semmi_ de semmi bizonyitek arra, hogy a KNL-en fejlesztok mas GPGPU platformokrol erkeznek. Es ha x86-rol erkeznek, akkor mi van? Akkor ki a francot erdekel, hogy mi van a Teslaval? Amugy meg, ennyi erovel en ha x86-on programozok mondjuk Pascalban, akkor elore lelkileg fel kellene keszitenie a Google-nak engem arra, hogy milyen megrazkodtatas lesz az androidos fejlesztes Javaban? Hol nem sz*rja ezt le a Google? Ha programozo vagyok, es nem vagyok teljesen bena, akkor meg fogom tudni tanulni az Android+Javat is, nem kell a kis kezemet fogni. Ne nezd mar teljesen gyamoltalan f*sznak a programozokat Van biztos olyan is, de en szemely szerint nem ismerek olyat, aki ne lenne kepes valamilyen szinten x86 SIMD vagy OpenCL/CUDA programozasra, vagy epp a ketto kozott valtani, ha ugy hozza a sors."Majd megoldja a hardver?"
Ha OpenCL stack lesz a KNL-re (marpedig lesz), akkor igen, a hardver megoldja, ha azt szeretned.
-
Fiery
veterán
Egyebkent errol az Andrew Richards-rol van szo?
Mert ha igen, akkor eleg fura, hogy nem irta be az elozo munkahelyei koze az Intelt. Vagy az annyira elhanyagolhato ceg, hogy nem erdemes megemliteni sem, mert ugyse ismeri senki?
Vagy nem is dolgozott valojaban a Xeon Phi-n (ahogy irod), hanem a Xeon Phi-vel dolgozott? Vasarolt egyet, kiprobalta, azt mondta, hogy sz*r?
Persze latom en, hogy GPU compilerekkel foglalkozik, de ugye a KNL-en nem kell (ujfajta) compiler, az nem holmi GPGPU, hanem egy sima CPU... Tehat a mostani Xeon Phi sz*r, mert Andrew Richards nem tudott ra GPU compilert irni, ergo a kovetkezo, teljesen mas architekturaju Xeon Phi (azaz a KNL) is az lesz, hiszen ............ <-- es ide jon egy nyakatekert logikai manover, amit kitalaltal? -
Fiery
veterán
"A nehezebb és a szart pedig ne keverjük össze."
Ha az Intel elkezdené azt sujkolni a programozokba, hogy az x86 nem eleg jo a KNL-re valo fejlesztes kapcsan, az lenne az igazi PR katasztrofa. Ok nem a Microsoft, hogy maguk alatt vagjak a fat
A programozok meg hidd el, eleg okosak ahhoz, hogy eldontsek, x86 SIMD-vel akarnak molyolni, vagy OpenCL-lel probalkoznak inkabb. Nagyban fugg ez attol is, mit csinalsz pontosan, mit akarsz elerni, es hogy van-e mar meglevo kodod. Ha mar van mondjuk egy Xeon E5-re fejlesztett x86 kodod, akkor hulye leszel OpenCL-re portolni azt, ha minimalis modositassal a KNL-en is szakitani fog. De persze a masik oldalrol meg ha OpenCL-ben vagy CUDA-ban mar van egy kesz kerneled, akkor meg nem fogsz nekiallni x86-tal szorakozni, ha az OpenCL kod is remekul fut."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?"
Igy van. Vagy ha nem megy neki, akkor nem eleg jo x86 SIMD programozo az illeto. Ez esetben pedig lehet OpenCL-lel probalkozni.
"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."
Asszem innentol felesleges is tovabb vitazni errol. Te egyetlen ember velemenyebol derivalod le, hogy az egesz KNL koncepcio (ami egyebkent _nem_ azonos a mostani Phi koncepciojaval, csak ezt se igazan vagy kepes megerteni, vagy csak elegansan atleped a kerdest, mint ha nem ez lenne az egyik legfontosabb valtozas) ugy ahogy van, rossz. Tegyel igy, en azt mondom, a piac majd eldonti a kerdest. Ugyanigy, a piac mar sok kerdest eldontott, pl. Seattle, Kaveri GDDR5, Itanium, stb.
-
Fiery
veterán
Tovabbra sem ertem, mi a problemad, es miert kellene az Intelnek barkit is oktatnia a KNL programozasaval kapcsolatban. A SIMD uj dolog? Nem. Az, hogy milyen szeles, masodlagos kerdes, a programozo majd megoldja. Volt eddig is sok szalu konfig? Volt, hogyne lett volna. Aki meg 16 szalra tud kodot irni, az 240-re is tud. Az OpenCL sem egy uj dolog, raadasul egy plusz funkcio, amivel tagulnak a lehetosegek. Az OpenCL kapcsan pont nem az Intelt kellene **szogatni, hiszen az AMD es nVIDIA megoldasaival szemben, a KNL-et lehet direktben is programozni, mindenfele plusz retegek (OpenCL, CUDA) nelkul. Mig ugyanezt az AMD es nVIDIA vonalon nem tul sokan vallaljak be, hiszen baromira nem "coder-friendly" ott a nativ kodolas.
"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"
Eloszor is: az Intelnek kellene megertetni a vilaggal, hogy a (SIMD) x86 sz*r? Ennyire hulyenek nezed oket, hogy tökön lovik sajat magukat?
Es kulonben is, ha lesz OpenCL tamogatas, akkor minden programozo, sajat hataskorben el fogja tudni donteni, hogy mit akar hasznalni. Ha nem tetszik az x86, lehet OpenCL-t hasznalni. Ha nem tetszik az OpenCL, akkor viszont csak a KNL-en tudsz SIMD x86-ot hasznalni, ami viszont sok embernek sokkal ismerosebb, mint a mindenfele GPGPU-s hobortok.A megszokott a piacon meg csak nevetni tudok. Miota van x86? Miota van SIMD x86? Miota van OpenCL, amit gyakorlatban is lehet hasznalni? Miota van koherens (SVM) OpenCL? Miota van CUDA? Most akkor melyiket szokta meg tobb programozo? Nem kenyerem a szemelyeskedes, de rajtad qrvara latszodik, hogy nem vagy programozo. Akkora suletlensegeket, amiket irsz, egy programozo sosem irna le. Amivel persze nincs baj, marmint hogy nem vagy programozo, hiszen nem lehet minden informatikaval foglalkozo szakember programozo. De van egy pont, ahol meg kellene allni, es hagyni, hogy a programozok eldontsek maguknak, mi a jo nekik. Es szereny velemenyem szerint a programozok a KNL megjelenese utan nem az x86 miatt fognak eloszor utcara vonulni, kovetelve egy absztrakt GPGPU-s f*szsagot _helyette_. Hangsulyozom: helyette. Mert ugye lehet igy is, ugy is programozni a KNL-et.
-
Fiery
veterán
Szerintem nem latod a fatol az erdot
Probalod ugy beallitani a Xeon Phi-t meg a KNL-et, mintha az azoknak keszult volna, akik hatalmas spilerek GPGPU temaban, pl. OpenCL vagy CUDA alapokon. Mibol gondolod, hogy ez igy van? Mibol gondolod, hogy pl. a KNL nem azoknak keszul, akik jelenleg tobbszalu SIMD _x86_ kodot keszitenek mondjuk Visual Studioban? Mibol gondolod, hogy tobbsegeben vannak azok, akik OpenCL/CUDA platformokrol erkeznek; azokkal szemben, akik x86 programozassal tengetik az eletuket, es esetleg tobbszalu SIMD kodot is kepesek kesziteni valamilyen eszkozzel?"Az Intelnek el kell magyaráznia a piacnak, hogy a Phi nagyon specifikus rendszer, amit sokkal nehezebb programozni, mint a GPGPU-kat. Ez biztosítaná a Phi jövőjét."
A mostani Xeon Phi-t talan nehezebb programozni, mint az OpenCL ill. CUDA alapu AMD/nVIDIA megoldasokat, de nem igazan ertem, miert lenne olyan nagy varazslat programozni a KNL-et. Mas, ez teny. De ennyi erovel akkor egy 72 szalu (2 utas) Xeon E5-re is ugyanugy nehez programot kesziteni. Vagy ha a hagyomanyos szerver Xeonokkal megbirkoznak a programozok, akkor miert lenne nehezebb boldogulni a Knights Landinggel? Mindketto x86, mindketto sokszalu, mindketto AVXn (n = 1..512
), mindketto rendszermemoriabol dolgozik nagy cache-ekkel. -
Fiery
veterán
Es szerinted a mostani vagy epp az elozo generacios Xeon Phi-nek mennyi koze van a KNL-hez? Szerinted ugyanugy kell programozni?
Az az Intel sara, hogy valaki epit egy balf*sz modon osszerakott szuperszamitogepet, majd nem tud megfelelo kodot kesziteni hozza? Miert vettek meg, ha nem tudjak kihasznalni? Vagy ha arra gondolsz, hogy az egesz csak egy PR-fogas volt, akkor egyetertek, de akkor meg az Intel csinalta jol, hiszen a sz*rt milyen ugyesen tudta promotalni
Abban egyebkent nem fogunk vitatkozni, hogy technikailag nem jo megoldas a mostani Xeon Phi. De ne vetitsuk le azt elore a KNL-re is, mert az tok mas megkozelites. Nagyjabol annyi koze van egymashoz a 2 termeknek, mint mondjuk egy low-end GCN1 dGPU-nak a Carrizohoz.
A bizalom kerdest meg inkabb ne feszegessuk egy alapvetoen AMD-s hirhez kapcsolodo topikban szerintem
Teszek helyette inkabb egy meresz joslatot: _szerintem_ soha nem fog elkeszulni ez az AMD HPC APU. Vagy ha el is keszul, pont olyan sokat adnak el belole, mint a legutolso nagy szerver probalkozasbol, lasd Seattle. Az AMD nem ilyen speci cuccokkal kellene, hogy veszodjon. -
Fiery
veterán
Hadd kerdezzem mar, ennek, amit irtal, mi a frasz koze van barmihez is? Nehogy mar a Xeon Phi-t hasonlitsuk egy Knights Landinghez vagy az AMD HPC APU-jahoz. Teljesen mas megkozelites, mas utasitaskeszlet, mas architektura, minden **rvara mas. A Xeon Phi valoban korulmenyes, plane ha melleteszel egy Teslat. Onmagaban a Xeon Phi sem egy megoldhatatlan problema, hiszen mar reges-reg kitalaltak az x86 piacon a tobbszalu kodoknal a beallithato CPU maszkot
Egy 36 magos (2 utas) Xeon E5-nel sem kotelezo mind a 72 threadet kihasznalnia egy x86 szoftvernek, ha gyorsabb kevesebb thread hasznalataval a kod.Egy Knights Landingnel majd a programozok kimérik, hogy mi az optimalis thread leosztas. Legyen ez az o problemajuk, nemtom miert kellene Neked eldonteni helyettuk, hogy jo lesz-e a KNL nekik vagy sem. Az biztos, hogy nem igenyel uj paradigmat, hiszen x86. Ha az Itanium a nem-x86 architektura miatt bukott meg, akkor a KNL-rol elore eldontjuk, hogy pont az x86 miatt fog elbukni?
Amugy meg, remelem szamodra is teljesen vilagos, hogy se a KNL, se az AMD HPC APU-ja nem a mainstream piac szamara keszul. Egy nagyon specialis, nagyon vekony piaci reteg igenyt igyekeznek ezekkel kielegiteni a gyartok. Amikor pedig ennyire specialis termekrol van szo, hidd el, nem lesz problema a programozokkal megiratni a f*sza kodot. Mint ahogy arrol sem lehet sokat hallani, hogy a Tesla kapcsan problema lenne a programozas. Pedig ott masolgatni kell a memoriat, meg kell tanulni a CUDA-t, stb. Megis elboldogulnak vele azok, akinek ez a feladatuk. A CUDA-val szemben viszont az x86 programozok szama igencsak nagysagrendekkel nagyobb, me'g azoke is, akik adott esetben nem teljesen fogalmatlanok a multi-threaded + SIMD programozas kapcsan sem. Lesz, aki kodot gyartson majd a KNL-hez.
Az AMD HPC APU-ja pedig pont ugyanaz pepitaban, mint a Kaveri. Aki most is gyart kodot a Kaverihoz, az imadni fogja az AMD HPC APU-jat is. A gyakorlatban majd kiderul, melyik a tuti megoldas. Siman lehet, hogy a HSA-val parositva nagyon vonzo platform lesz az AMD HPC APU-ja -- de az is lehet, hogy a konkurens x86-os megoldas miatt megsem.
-
Fiery
veterán
Dehogynem a Knights Landing ellenfele. Mindket procit specialis szamitasokra szanjak, mindketto egy dGPU helyet veszi at, mindketto a megosztott memoria koncepciojara epit (bar nem feltetlenul ugyanolyan modon), mindketto tulajdonkeppen egy CPU tokba rakott dGPU, mindkettonel van near memory (tok mindegy, hogy hivjak), de mindketto elsosorban a rendszermemoriaba dolgozik. Ja, es mindketto nagyjabol ugyanolyan TDP-osztalyt celoz. Az, hogy az architektura heterogen vagy homogen, me'g tok ugyanaz a vegcel mindket HPC megoldassal.
"Szerintem az AMD valami gyakorlatban is használható rendszert szeretne, aminek lehetséges a programozása."
((( Kepzelj ide egy big f* facepalmot ))) Mert ugye a Knights Landing-et nem lehet a gyakorlatban programozni. Lassuk csak, irni kell egy 240 szalra skalazott x86 kodot. Jajj, vajon azt hogyan oldja meg a programozo? Az x86 valami tok uj dolog, nem tudom, hogyan fogjak a programozok elsajatitani hirtelen ezt az uj megoldast...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
); es a Knights Corner-t hagyjak a francba, akkor nem lehet azt mondani, hogy a KNL-nel egyertelmuen erre vagy arra huzott az Intel. Akarhogy probalod beallitani annak, a KNL nem a Knights Corner pepitaban, hanem egy teljesen uj architektura, ami -- ahogy fentebb is irtam -- sokkal jobban hasonlit egy Xeon E5-re (Haswell-EP), mint egy Knights Cornerre. Ennyi erovel a Conroe-t is el lehetett volna asni elore, annak fenyeben, hogy a NetBurst mennyire nem jott ossze -- csak ugye tok mas architektura volt a Conroe, tehat ertelmes ember nem a NetBurst alapjan derivalta le a Conroe potencialis kepessegeit.
Es kulonben is, ha lesz OpenCL tamogatas, akkor minden programozo, sajat hataskorben el fogja tudni donteni, hogy mit akar hasznalni. Ha nem tetszik az x86, lehet OpenCL-t hasznalni. Ha nem tetszik az OpenCL, akkor viszont csak a KNL-en tudsz SIMD x86-ot hasznalni, ami viszont sok embernek sokkal ismerosebb, mint a mindenfele GPGPU-s hobortok.
Teszek helyette inkabb egy meresz joslatot: _szerintem_ soha nem fog elkeszulni ez az AMD HPC APU. Vagy ha el is keszul, pont olyan sokat adnak el belole, mint a legutolso nagy szerver probalkozasbol, lasd Seattle. Az AMD nem ilyen speci cuccokkal kellene, hogy veszodjon.Új hozzászólás Aktív témák
Hirdetés
- Steam Deck
- Honor Magic6 Pro - kör közepén számok
- QWERTY billentyűzet és másodlagos kijelző is lesz a Titan 2-ben
- Luck Dragon: Asszociációs játék. :)
- Autós topik látogatók beszélgetős, offolós topikja
- Álláskeresés, interjú, önéletrajz
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Brogyi: CTEK akkumulátor töltő és másolatai
- Milyen autót vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- További aktív témák...
- Jo Nesbo: LEOPÁRD (nem olvasott)
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASRock B460M i5 10400 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA TT 500W
- Bomba Ár! Lenovo ThinkPad T540P - i7-4600M I 8GB I 180GB SSD I NVIDIA i 15,6" FHD I W10 I Gari!
- Bomba ár! Lenovo X1 Yoga 1st - i7-6G I 8GB I 256SSD I 14" WQHD Sérült I W10 I CAM I Garancia!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged