Intel: akár 1000 magos processzorok is jöhetnek Én: akár piros hó is eshet
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.
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.
É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.
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 :).)
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 ...
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.
"- 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ú."
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.
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.
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.
milenne ha a számitási teljesitményen dolgoznának minthogy a marketingen???
"É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?
"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.
"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.
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.
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ó.
É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...
"á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.
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.
"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
ha a videokártyákat nézzük , már létezik valami ilyesmi
Informatika és tudomány
