35
-
J3Surno #35
Az! Sajnos -
torzsvendeg #34 Intel: akár 1000 magos processzorok is jöhetnek
Én: akár piros hó is eshet
-
Komolytalan #33 Az F1 pilóták meg általában nagyon lusták, mert ha mondom nekik hogy szántsák már ki a kertet a 600 lóerős traktorukkal, akkor mind azt mondja, hogy ezzel nem is lehet szántani. Holott a lóerő megvan hozzá bőven, szóval biztos kamuznak. -
Komolytalan #32 Víruskeresés adatbázisban az jellemzően memória intenzív feladat. Kép szerkesztés memória intenzív (egy pixelhez kellenek a szomszédos pixelek is gyakran). Beszéd felismerés mivel adatbázis alapú, így szintén. Kódoló/dekódoló/tömörítés szintén, ráadásul ott az előző eredményekre nagyon sokszor szükség van. Neurális háló alapú rendszerek szintén rengeteg memória, egyszerű kód.
Sajnos az van, hogy a modern algoritmusok arra épülnek, hogy a memória gyors, és ez az alapvetés dől meg a sok magos rendszereknél. Eleve a fordítók is elég gyakran stack orientáltak - kevéssé használják ki a regisztereket. És ugye a stack az memória. -
Komolytalan #31 Értem én amit te írtál, meg te is érted amit én írtam - ne vitázzunk tovább:-) Szerintem azon kell elgondolkodni, hogy a memória (vagy közös használatú cache) hányszor lehet lassabb, mint az össz proci teljesítmény. Mert ez itt a kulcskérdés, hogy hány ütemciklusnyi nem memóriahasználó utasítás lehet egymás után egy gépi kódú programban. 1000? Biztos nem. 10? Inkább. Túl sok azért nem lehet, mert akkor már inkább táblázatot kellene használni - a modern programozás sok adat, kompakt kód -, ami meg megint csak memória hozzáférés...
Szerintem nem elég a több és gyorsabb memória. 100x nem lehet memóriát gyorsítani, mondjuk 1 év alatt. Inkább a memória Random Access tulajdonságát kellene felülbírálni. Kellenének Semi-ROM, vagy ritkán írható, konstans memóriák is a gépbe. Ha egy memória részt lehetne hosszabb ideig "konstansnak" definiálni, akkor abból megérné akár 1000 különböző mag számára is másolatot készíteni a saját dedikált cacheükbe, mert biztos lehetne benne a cache/memória vezérlő, hogy ritkán kell az 1000x lemásolást elvégeznie. De amíg 3 bytenyi memóriaterület változik miliszekundumonként, az utána következő 10K meg a program futása alatt végig statikus - mert a programban konstansnak vettük fel -, addig ezt nem lehet megcsinálni. Szóval szerintem a magok számának hatékony növeléséhez a jelenlegi memória felépítést alapvetően kell megváltoztatni. -
krk #30 Ezer mag? Annyi még a görögdinnyében sincs... -
philcsy #29 A programozók nagy része igenis lusta és inkább elintézi annyival hogy: "ezt nem lehet hatékonyan párhuzamosítani". -
philcsy #28 A párhuzamosítás nem azt jelenti hogy minden létező dolgot erőszakosan párhuzamosítani kell.
Nyugi, nem fognak kihalni az egymagos magas órajelű processzorok.
Viszont van egy rakás olyan feladat - lényegében a számításigényes feladatok nagy része ilyen - amely igen is jól párhuzamosítható. Azért mert az adat amin dolgozik nagyságrendekkel kissebb mint az elvégzendő utasítások száma. És nem csak a HPC-ben hanem hétköznapi használatban is.
Csak egy:
A vírusírtók azért terhelni szokták a rendszert.
Vírusellenőrzés egyik formája az adatbázisban lévő víruskód direkt keresése. (Tudom régi meg van más jobb is, és vannak erős korlátai is, mégis ez az egyik legálltalánosabb és folyamatos frissítéssel hatékony is.) Minden probléma nélkül lehet párhuzamosítani GPU-val. (Azt már nem fogom idírni hogy hogyan :).)
Képszerkesztő/képfeldolgozó rendszerek. Beszédfelismerő rendszerek. Kódoló/dekódoló eljárások. Tömörítési eljárások. Neurális háló alapú rendszerek. Soroljam még? -
philcsy #27 Ha az egyik szál megtalálja a megfelelő elemet akkor leáll és tudatja mindenkivel hogy hol találta. A többi szál pedig csak akkor áll le ha vagy túlmentek, vagy ők is találtak egyet. Ez már az elsőt fogja visszaadni és párhuzamos.
Nayon sokmindent lehet párhuzamosítani.
Viszont ha azt mondod hogy nagy adatmennyiségnél és egyszerű keresésnél (az elem vizsgálata egy vagy néhány lépésből megvan) a memóriahozzáférés lesz a szűk keresztmetszet akkor igazad van. Ez addig gyorsul amíg a memsávszélesség bírja. 1000 magnál pedig ... -
Komolytalan #26 Amit ha 1000 mag használ, akkor szerinted mennyire effektív? Mert ok, 2-3-4 magnál még _elmegy_. De 1000-hez már tetves lassú. És ezen nem segít a méret növelés se, mert nem a mérettel van baj, hanem azzal, hogy egy átlagos programkódban x soronként van memória hozzáférés (mittomén, x=10). Így ha a memória több mint 10x lassabb mint a magok "össz" sebessége, akkor onnan kezdve hiába programozol tökéletesen, hiába csinálod meg a legjobb cache architekturát, hiába csinálsz baszott nagy L3 cache-t - fogni fogja az egészet a memória hozzáférés. -
sanyicks #25 "- Memória. Ha magokhoz van a cache dedikálva, akkor akkor van baj, ha ugyanaz a terület kellene mindkettőnek. Mert akkor ha egyik beletúr, másiknak borítani kell a cache-t, és máris tetű lesz. Ha meg nincs magokhoz dedikálva, akkor meg globálisan lassú."
Erre találták ki az L3 cachet... -
Komolytalan #24 Persze, lehet találni ilyen feladatot, de én spec jobban örülnék ha én mondanám meg milyen feladatot akarok elvégezni, nem a processzor architektúrája. Pl szervereken is kiválóan lehetne párhuzamosítani az egyes kliensekhez rendelt szálakat. Mondjuk van 1 gáma, és minden kliensnek van 1 threadje, foglalkozzon vele külön processzor. Csak éppen a következő pontokon döglik meg a dolog:
- Memória. Ha magokhoz van a cache dedikálva, akkor akkor van baj, ha ugyanaz a terület kellene mindkettőnek. Mert akkor ha egyik beletúr, másiknak borítani kell a cache-t, és máris tetű lesz. Ha meg nincs magokhoz dedikálva, akkor meg globálisan lassú.
- Asszimetrikus erőforrásigény a szálak között. Van 1 fő szál, amin kellene futnia annyi "kódsornak", mint 999 másikon együttvéve. Máris olyan lassú lesz az 1000 magos rendszer, mint egy sima 2 magos, mert 999 mag 0.01%-on teker, míg 1 meg 100%-on.
Szóval persze, van olyan dolog, amire jó, de általános célra a nagyon sok - és éppen ezért egyesével relatíve lassú mag - ritkán ér többet egy kalap szarnál. -
xyl #23 Amúgy pedig rengeteg olyan feladatot lehet találni, ahol simán lehet párhuzamosítani: Inverz feladatok. Tudom azt, hogy valamilyen válasz függ több paramétertől, nem tudom, hogy mik a paraméterek és nekiállok kikeresni. 2 paraméter esetén pl. 10000 maggal kapok egy 100x100-as térképet. Persze, tudom, hogy vannak hatékonyabb módszerek annál, hogy az ember csak úgy nyers erővel nekiálljon, de ez feladatfüggő. Vagy mittudomén, egy egész diagramsereget le akarok gyárani. Hogy miért? Csak. Mert kell. stb. -
Komolytalan #22 Első megfelelő elemet. Ha meg párhuzamosítasz, akkor megtalálja valamelyiket (amelyik szál éppen a leggyorsabb). A feladat meg keresésnél nem ez. -
FoodLFG #21 Versenyhelyzet van! 
-
DeviloftheHell #20 milenne ha a számitási teljesitményen dolgoznának minthogy a marketingen??? -
philcsy #19 "És most ez hogy jön ide?"
Egy egyszerű példa a párhuzamosításra? És vannak bőven helyek ahol ilyen egyszerű formában is használni lehetne.
"Nagyon nincs köze az OpenMP-nek az átlag programok párhuzamosításához..."
Mért nincs? Mert a programozók nagy része azt sem tudja mi az. Nem pedig azért mert nem lenne használható (nem csak ez az egy utasítás van). De valahogyan a windows-os több szálindítást sem nagyon akarják használni. Lehet hogy arról sem hallottak még? -
philcsy #18 "egy sima keresés, ahol az első elemet kell megtalálnia"
Te az első elemet keresni szoktad? Nekem ott az elején.:)
Egy sima keresés ebben az esetben nem nagyon trükkös, csak kell egy plusz változó ami jelzi ha valamelyik szál megtalálta a keresett elemet, hogy a többi is leálljon. -
Komolytalan #17 "Trükkös" ciklus egy sima keresés, ahol az első elemet kell megtalálnia, és kilépnia:-D Gyakorlatilag ez a párhuzamosítás kb arra jó, hogy töltsünk fel egy tömböt 0-val. Amihez ASM-ben eleve nem kell for, hanem ott a jó öreg stos* is. -
Komolytalan #16 Azon bukik a dolog, hogy nincsen minden procihoz saját dedikált memória modul. Mert amíg az 1000 mag csak néhány memóriamodult tud elérni, addig a memória erősen korlátoz. Igazándiból a 6-8 mag után nem processzort kellene fejleszteni, hanem memóriát. -
Komolytalan #15 Nem az alkalmazások nem tudják kihasználni a lehetőséget, hanem az átlagos algoritmusok nem párhuzamosíthatóak ilyen szinten, ha megfeszül a programozó, akkor sem. Egy
A=B+C
B=A+C
C=A+B
1000 magon is ugyanolyan gyors lesz mint 1 magon, mert minden utasításnak szüksége van bemenetként az előző utasítás kimenetére. És egy átlagos algoritmusra - ha nem is ilyen szinten - ez általánosságban jellemző.
Amit igazán párhuzamosítani lehet az ritka, mint a fehér holló. -
#14
pizzat? -
nenad #13 te majd notepadozol vele, mi meg majd rendelünk realtimeban. :D -
sanyicks #12 igeen? Na hol van az 5ghz-s 100 magos proci? Én nem találtam, pedig már vagy 5 éve bejelentették.
100ghz-s procit sem. Inteltől mindent szétalázó gpu szerűséget sem, stb stb. -
sirpalee #11 És most ez hogy jön ide? Nagyon nincs köze az OpenMP-nek az átlag programok párhuzamosításához... Szép lenne, ha ilyen egyszerű lenne a szoftverfejleszők élete... -
philcsy #10 Igen ez azért vicces mert egy for-ciklusok parallelizációja C-ben OpenMP-t használva:
#include <omp.h>
...
#pragma omp parallel for
for , amit parallelizálni akarsz
Persze ha valami trükkös ciklus van ami közös adatokat változtat arra figyelni kell és nem csak 2 sor az egész. -
moikboy #9 Oké, de így 1000 programot futtathatsz egyszerre :D -
Rotyoka #8 feldughatod az 1000 magot ha a mai programok 99%-a a 2 magot sem tudja kihasználni 20% felett.... -
#7
ezzel már tuti nem szaggatna maxon a crysis -
Sir Ny #6 Ez azért vicces, mert ez a két cég vezet a valós eredmények terén. -
Zoliz #5 "át lehet lépni a jelenlegi teljesítményhatárokat és le lehet küzdeni a fejlesztés során felmerülő nehézségeket" Jah rákkutatásnak álcázott atomfegyver szimulálására kell majd a mesh szörny, ne is tagadjátok. -
sanyicks #4 Ez semmi, az ibm már 5 éve is 500 magos magonként 5 ghz-s procikat csinált... annyira volt életképes mint ez... az intel és az ibm vezető a bullshittelésben, és az állítólagos egetrengető találmányok beharangozásában... kár hogy a valós gyártásban és valós eredményekben már nem annyira. -
dchard #3 "A cég szerint ugyanakkor az SCC esetében nem a teljesítmény a fontos, ehelyett inkább a jövőbeli asztali alkalmazások többmagos processzorokra optimalizálására helyezik a fő hangsúlyt."
Na itt a lényeg. Egészen addig, amíg az alkalmazások nem képesek a több processzormagban rejlő nagyobb számítási kapacitás hatékony kihasználására, addig vajmi kevés jelentőssége van a sokmagos processzoroknak. Ezért is volt jó döntés a 48magos procik átadása a kutatóknak, hogy legyen idejük olyan szoftvertechnológiai megoldásokat kidolgozni, amik képesek a többlet teljesítmény hasznosítására.
Dchard -
#2
ha a videokártyákat nézzük , már létezik valami ilyesmi -
MacropusRufus #1 wow