- Ilyen videokártyát választana a DOOM Slayer
- Üvegben nem szűköldködő GameMax mikrotorony, "lopakodó" alaplapokhoz is
- 14 GB/s-mal olvasó, DRAM-os SSD az ADATA palettájáról
- A készülő legújabb node-ján is kerüli a legmodernebb EUV berendezéseket a TSMC
- Ez lenne a népkártya? Teszten a GeForce RTX 5060 Ti 16 GB
- Androidos tablet topic
- 14 GB/s-mal olvasó, DRAM-os SSD az ADATA palettájáról
- Házimozi belépő szinten
- Ez lenne a népkártya? Teszten a GeForce RTX 5060 Ti 16 GB
- Milyen belső merevlemezt vegyek?
- Vezeték nélküli fülhallgatók
- Kormányok / autós szimulátorok topikja
- Melyik tápegységet vegyem?
- IFA 2024: Erős, bár drága NAS-ok a Ugreentől
- Milyen billentyűzetet vegyek?
Új hozzászólás Aktív témák
-
-
Abu85
HÁZIGAZDA
A CLBenchmarknak van egy listája, hogy mi hogy teljesít.
Az OpenCL driver már végleges. Ettől persze még gyorsulhat, de már nem alfa meg béta driverek vannak.
Kiindulva abból, hogy a Larrabee legnagyobb problémája az volt, hogy nem skálázódott, könnyen lehet, hogy ennek is ez a legnagyobb gondja. Végtére is az x86-ot, mint a teljesítmény legnagyobb gátló tényezőjét nem cserélték le csupán változtattak rajta. -
#44
tocsa
senior tag
Meteorhead
#16
tocsa
senior tag
válasz
Meteorhead
#16
üzenetére
De jó hallani a szavaidat! Nekem is ez a gondom, és pontosan ezt pofáztam egy másik topic-ban, de az emberek 99.9% nem értette meg.
-
tocsa
senior tag
Mi a cikk forrása? Csak azért kérdezném, mert érdekelne a XeonPhi OpenCL driver mibenléte.
Mennyire lehet kiforrott a XeonPhi OpenCL meghajtója? Az a gyanúm, hogy még nagyon pre alpha fázisban lehet, ezért nem lehet igazán következtetést levonni a XeonPhi valós, végleges teljesítményéről. A driver kiforratlansága akér erősen akadályozhatja. Hogy mi lesz egy jobb driverrel azt meg nehéz megmondani, 2-3x vagy jobb gyorsulás is simán elképzelhető, de az is elképzelhető, hogy ennyire futja amit itt látunk.
-
LordX
veterán
Nem érted. Ha Celeronból tennének bele hatmilliárd darabot, akkor is brutális teljesítményű clustert lehet csinálni. Ettől még a Celeron nem lesz gyors.
Szóval nem csoda, hogy félkészen is nagyobb teljesítményű, ha félkészen is már 2,5x több darab van benne, mint K20X a Titanban.
-
drkbl
őstag
Chinese supercomputer destroys speed record and will get much faster
A Tianhe-2 kínai szuperszámítógép (32,000 Intel Ivy Bridge Xeon foglalat, 48,000 Xeon Phi kártya, összesen 3,120,000 mag) 90%-os készültségnél 30,65 petaflop teljesítményt ért el, 74%-al felülmúlva a jelenlegi csúcstartót (Titan, Opteron + K20x).
-
cer
tag
Hello Abu,
Közzé tennétek az alább felsorolt a paramétereket magyarul...
Azt mondom ha már magyar portál, akkor legyen magyarul.
Lehet nem sok köszönet lesz majd leírva, de egészen biztos vagyok benne, sokan megköszönik íratlanul.Én meg írásban, előre is köszönöm!
Physics: SPH Fluid Simulation
Graphics: Raytrace
Vision: Optical Flow
Image Filter: Sobel - Global memory usage
Image Filter: Sobel - Local memory usage
Image Filter: Sobel - Image usage
Image Filter: Separated Gaussian Blur - Global memory usage
Image Filter: Separated Gaussian Blur - Image usage
Image Filter: Median3x3 - Image usage
Programming Principles: Bucketing - Parallel Associative Local
Programming Principles: Reduction - Parallel Commutative case with Local memory usage
Programming Principles: Scanning - Parallel Associative case with Local memory usage
Programming Principles: Scanning - Sequential Associative case
Programming Principles: Sum - Global atomic add
Programming Principles: Sum - Local atomic add
Programming Principles: Bitonic Merge Sort
Programming Principles: Tree search -
petXYZW
tag
Pontosan ezt a választ vártam.
Ez esetben a tesztnek, a "kód-divergencia", "random memory-access pattern" vagy hasonló nevet kellet volna adni, nem pedig, hogy "tree search".
Ugyanis így már teljesen világos a GPU lemaradása.
A "tree search" tehát azért nem szerencsés elnevezés, mert a gráfkeresőket lehet a GPU számára emészthetővé tenni olyan módon, hogy a divergenciából eredő lassulás ne jelentkezzen és a memória elérés minták ne legyenek olyan "ordasak". Ráadásul olyan előnyi is lesznek a megközelítésnek ami kifejezetten kedvez a GPU-nak.
-
con_di_B
tag
A "Tree search" egy teljesen szintetikus teszt (értsd, nem az a lényeg, hogy mit old meg, hanem az, hogy mit terhel) ami kifejezetten arra készült, hogy extrém divergens kódvégrehajtást eredményezzen. Elméletben ez persze nem fair a masszívan SIMD hardverekkel szemben, de a gyakorlat azt mutatja, hogy ezek között is lényegi különbség van a divergencia kezelése terén, amit érdemes mérni.
A "bemegyünk a gráfba és jól eltévedünk" jellegű problémáknál ezen kívül az is szempont, hogy ennél a fajta divergenciánál nem csupán a vezérlés nehéz, hanem a memória-elérés mintája is a lehető legrosszabb.
Éppen ezért ebben a tesztben azok a hardverek tudnak jó eredményt elérni, amelyek 1) nem annyira érzékenyek a divergens vezérlésre 2) jól kezelik (gyorsítótárazzák) a legordasabb memória-eléréseket is.
Ezeket a problémákat hagyományosan nem szeretik GPU-ra átültetni, de az OpenCL messze nem csak a GPU-król szól.
Folyamatpárhuzamosságról ebben az esetben nincs szó.
-
petXYZW
tag
"flow control hardver kell hozzá."
Én nem hiszem, hogy ez az oka! Úgy gondolom, hogy egyszerűen feladat-párhuzamos a kód és ez fekszik a Xeon Phi-nek, míg a másik kettőnek kevésbé. Nekem ez a véleményem, de pont ezért írtam, hogy ez esetben jó lenne látni, milyen a konkrét kereső algoritmus és milyen problématérben keres. Ha egyáltalán ezt takarja a "tree search" a CLBenchmark fejlesztőinél...
-
#31
Mr Bond 007
őstag
Mr Bond 007
őstag
Ha annyira tré akkor ez hogy?
KATT -
Abu85
HÁZIGAZDA
Nagyon jó flow control hardver kell hozzá. Ezzel jól kezelhető a branch-divergency.
Közben kiderült a Xeon Phi-ről, hogy nem is olyan megosztott az az L2 cache. Konkrétan minden maghoz saját tartozik, és a másik maghoz tartozó L2 tárat se írni se olvasni nem tudják. Az Intel ezt nem pont így ígérte, de mindegy. Ez is ad némi magyarázatot az eredményekre.
-
#28
petXYZW
tag
Meteorhead
#26
petXYZW
tag
válasz
Meteorhead
#26
üzenetére
Most erre mit mondjak...minden szavaddal egyet tudok érteni és megértem.
Az tény, ha bármit szeretnél létrehozni ami GPU-n fut, és nem két vektort ad össze, ahhoz tényleg "akarni kell" és egy adag szop@s garantált, amitől elmehet az ember kedve.
-
#26
Meteorhead
aktív tag
petXYZW
#22
Meteorhead
aktív tag
A programozóknak az OpenCL-lel nem az a bajok, hogy programozni kell benne (bár igen, sajnos létezik az a 70%-os programozói réteg, aki egy mezei host oldali párhuzamos kóddal sem bánik el, sem task, sem data parallel esetben), hanem az a baja, hogy isszonyatosan verbose és macera az interface-e.
Egy olyan egyszerű problémát megoldani, hogy egy GPU képes-e double-ben számolni, vagy csak floatot lehet használni kernelben olyan trágya módon lehet megoldani, hogy az ember csinál egy #define REAL float/double sort a kernel kódba, amit runtime kell a kódba beleírni, mert akkor derül ki, hogy az adott hardver amin fut képes-e rá. Igen, C++-an léteznek template-k. Ilyenekre találták ki őket. (Igen, AMD-nek van már static C++ OpenCL compilere, de az a kód nem lesz hordozható)
OpenCL-ben nincs dinamikus memóriaallokáció (ami állatira megnehezíti a legegyszerűbb hatékony reduction kódok írását, mert egy csomó méretet host oldalról kell beleinjektálni a kódba, hogy compile-time konstans legyen.
Tisztában vagyok vele, hogy a rengeteg feature amit korábban felsoroltam az egy magasabb szintű absztarkciót szolgál, de el nem tudom mondani, hogy mennyivel egyszerűbb lenne az életem, ha STL tárolókat használhatnék egészen az utolsó függvényig, ami feldogolgozza az adatokat, és nem kéne közbeékelnem egy cl:
uffert, és a köré épített egész masinériát. Fejlesztési idő ÓRIÁSI mértékben lerövidülne.Egyébként értem amit mondasz, hogy van egy fajta programozói lustaság, (bár nekem azért van munkám, mert kevesen értenek ehhez) de tényleg macera. Olyan programot írni, ami minden user gépén fut állati macera írni, és OpenCL C99 kernel nyelve ehhez csak hozzárak. Csak a template-ek már megváltásként hatnának.
-
#22
petXYZW
tag
Meteorhead
#16
petXYZW
tag
válasz
Meteorhead
#16
üzenetére
"Azt, hogy virtuális függvényeket , függvénypointereket, polymorphizmust orrvérzésig használhat az ember számokban nem kifejezhető, és a GPUk azt nagyon soká fogják csak tudni. A HW hiába tudná már, nincs API amin keresztül rendesen ki is lehetne használni (portable módon meg aztán végképp)."
Szerintem ezek a dolgok nem arra valók, hogy valamilyen dedikált "computational task"-ban szerepeljenek, hanem alapvetően absztrakciót, programozást elősegítő eszközök, módszerek, valóban összetett problémák megoldásához.
A "programozóknak" az nem tetszik, hogy az OpenCL-ben programozni kell...
-
#20
haxiboy
veterán
stargazerhu
#19
haxiboy
veterán
válasz
stargazerhu
#19
üzenetére
Ilyenből 3 az maga az álom
-
#16
Meteorhead
aktív tag
Meteorhead
aktív tag
Az Intel már előre megmondta, hogy nem a GPU-kkal akarnak versenyezni, mert nyers erőben meg sem közelíti azokat. Intel célja egy olyan masszívan párhuzamos platform építése volt, aminek a belépési költsége 0.
A GPUk állati erősek, de még mindig nem váltották meg a világot. Egyszerűen túl nehéz programozni őket (én is ebből élek, úgyhogy tudom). Ezt meg az ember bedugja a gépbe, és MPI-al eléri mint egy új node-ot a clusterben.
Amit pedig elfelejtenek az emberek, hogy bár OpenCL-t tud futtatni, és nem is kellene ennyire véresen gynegének lennie, a legnagyobb előnye, hogy ezen bármilyen C++ kódot le lehet fordítani, mivel C++ feature complete (x86 lévén). Azt, hogy virtuális függvényeket , függvénypointereket, polymorphizmust orrvérzésig használhat az ember számokban nem kifejezhető, és a GPUk azt nagyon soká fogják csak tudni. A HW hiába tudná már, nincs API amin keresztül rendesen ki is lehetne használni (portable módon meg aztán végképp).
-
#14
lezso6
HÁZIGAZDA
stargazerhu
#12
válasz
stargazerhu
#12
üzenetére
Az elég szomorú, mert alig van valamivel előrébb a Phi, még ha a levonom a tuningot, akkor is.
-
#13
LordX
veterán
ermisukrám
#9
LordX
veterán
válasz
ermisukrám
#9
üzenetére
Már rég megjelentek ezek a kártyák, boldogan szállít az Intel mindenkinek, aki véletlenül kérne belőle.
-
#12
stargazerhu
aktív tag
stargazerhu
aktív tag
Kíváncsi voltam mit tud egy 7950es VGA és vele szemben egy 3770K-s proci @4,6GHz-en
Hát ezt:[link] -
Ez nagyon kevés így, de kérdés, hogy vajon miért. Én adok neki annyi esélyt, hogy a későbbiekben ez radikálisan javulhat.
-
#9
ermisukrám
tag
ermisukrám
tag
hát ez eléggé gyér. inkább ne is jelentesse így meg az intel mint végtermék.
-
#8
Dragbajnok
tag
LordX
#6
Dragbajnok
tag
-
LordX
veterán
AMD FirePro W9000: 274 W
Intel Xeon Phi 5110P: 225 W
Az nV érdekes módon nem specifikálja a teljesítményt.
uffert, és a köré épített egész masinériát. Fejlesztési idő ÓRIÁSI mértékben lerövidülne.
Új hozzászólás Aktív témák
Hirdetés
ph A szerverekbe szánt eszközről egyelőre kevés gyakorlati információ van, de végre befutott pár CLBenchmark eredmény.
- Kamionok, fuvarozás, logisztika topik
- Kerékpárosok, bringások ide!
- Milyen autót vegyek?
- Linksys WRT54G/GL/GS router
- Androidos tablet topic
- PlayStation 5
- 14 GB/s-mal olvasó, DRAM-os SSD az ADATA palettájáról
- Luck Dragon: Asszociációs játék. :)
- Házimozi belépő szinten
- Ingatlanos topic!
- További aktív témák...
- ÁRGARANCIA! Beszámítás, 27% áfa, 5db Sapphire Nitro+ RX 9070XT 16GB készletről BOMBA ÁRON!
- Hibás/Kis hibás/Hiányos,Működő/ Teszteletlen Hardverek és egyéb 500ft-tól.
- RTX 2060 6GB DDR6/ garancia/ ingyen foxpost
- Gigabyte GeForce GTX 1060 3GB Mini ITX OC GPU
- DOBOZOS!! ASUS GTX 1660S Phoenix (6GB GDDR6 192bit) -- tesztelt :: BESZÁMÍTÁS!
- Eredeti Lenovo USB-C 65W töltő
- Dell Latitude 5495 Full HD IPS Ryzen 5 pro 2500u Radeon Vega Mobile Gfx i5-8350u verő Bp MPL Foxpost
- ÁRGARANCIA!Épített KomPhone i5 14600KF 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Xiaomi Redmi Note 8 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- HP szerverek áron alul
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest