Elsõre is értettem, hogy mit találtál ki. Az a baj vele, hogy az 1 procira írt kódban az egymás utáni mûveletek gyakran függenek egymástól, így nem hajthatók végre párhuzamosan. Amennyire lehet a mai procik is próbálkoznak, futószalagon dolgozzák fel az utasításokat, hogy a különbözõ alegységek kihasználtsága maximális legyen. És ha két olyan mûvelet jön egymás után, ami különbözõ részeket használ, akkor megpróbálják párhuzamosan végrehajtani (ha jól tudom). A másik gond, hogy a procik közti kommunikáció lassú a procin belülihez képest, tehát nagyon nem hatékony az utasításoka egyenként szétosztani. Mondjuk közös cache esetén még megoldható lenne. Alapvetõen sokkal egyszerûbb a szoftvert eleve többszálúra írni.
Érdekes dolog hogy a Voodoo3-ban már mikor elkezdték nyomni a többprocesszoros megoldásokat..... Ehelyett az NVidia az utóbbi idõben félévenként/évenként dupla akkora teljesítményt hoz ki egy magon. Nincs más módja a teljesítménynövelésnek ? Tartok tõle hogy a marketing okokból nem keresnek más megoldást. Lásd: Egyik gyártó elkezdte hangoztatni hogy többmagos procija lesz, erre a riválisnak is muszály olyannal elõrukkolnia
Lehet hogy rosszul látom ?
el vagy maradva, már szállitják a procikat a "nagy" gyártoknak :)
úgylátom nem egészen sikerült átadnom a gondolatomat :) megpróbálom jobban hangsúlyozni tehát minden (nem feladat) legapróbb egységnyi mûveletet a vezérlõ mag kiosztana a feldolgozó magok között, ami peródikusan ismétlõdik úgy hogy, a feldolgozó magok különbözõ periódusidõben válaszolnak a vezérlõmag felé és nem hinném, hogy túl lenne terhelve 1 vezérlõmag, de biztosan lenne egy állandó 80%-os kihasználása mondjuk 8 feldolgozó mellett :) és amit felhozotatok, hogy ugyanazt a programot nem nyithatja meg több proci, hát épp ez a lényege amit mondok... csak a vezérlõ proci nyit programot és szorja szét apró morzsákban a többi mag között...
Igeny meg lenne is ra, mert pl. kiugorva egy notebookkal az ugyfelhez megcsinalsz egy filmvagast, es nem kellene sokat varnod a renderelessel.
2 magra még csak-csak el lehet osztani a feladatokat, némi plusz meloval, s a sebesség nõhet valóban ... de négy magra ezt hiába is tesszük meg, a sebességnövekedés minimális lesz: egyszerüen home szegmensben egy laptopon nincs ilyen igényû program... ennek csak szerver környezetben lenne értelme.
BiroAndras: olvastad a register cikkét a 0.65ös xeonokrol? na, ennyit a megoldott hõtermelésrõl :D
Ez sem ilyen egyszerû. Bármenniyre is támogatja a fordító a többprocis körnezetet, a programozó segítsége nélkül semmire se megy. Meg kell adni, hogy a program mely részei futhatnak párhuzamosan, és gondoskodni kell a közösen használt erõforrások védelmérõl. Persze mindkettõben sokat segíthet a fordító. Az alacsonyszintû utasításonkénti párhuzamosítás csak korlátozottan leehtséges, mert az utasítások gyakran függenek egymástól. És csak egy magon belül van értelme, különben a késleltetés iszonyatosan nagy.
Nem az a probléma, hogy mikor melyik procira tegyük a feladatokat, hanem az, hogy hogyan vágjuk szét a programunkat párhuzamosan végrehajtható részekre, és fõleg, hogy hogyan szinkronizáljuk õket. A legfõbb gondot a közösen használt erõforrások jelentik, mert ha két szál egyszerre nyúl hozzájuk, akkor szépen lefagy a progi (vagy csak hibásan mûködik). Tonnányi szakirodalom foglalkozik ezekkel a kérdésekkel.
Szerintem már most is hasonló dolgokat csinálnak, akár egy magon pelül is lásd p4, csak ott a végrehajtó egységek közt osztja szét az ütemezõ. A probléma csak az, hogy ha a programot nem optimalizálták többszálú-magú futtatásra a szétosztás mûveletiidõ igénye a nagyon megnõne. Azaz még lassabb is lehet a teljes feladat végrehajtása mint széosztás nélkül. (Ráadásul "magon" belül még a késleltetések is kissebbek) Hidd el ezt a problémakört már sok ezren több évig tanulmányozták, igaz fõleg szerverekkel kapcsolatban. Ez csak Intel/Amd fronton újdonság. Tulajdonképpen inkább a fordítóprogramokat kell optimalizálni, fõleg wines környezetben, illetve fordításnál a megfelelõ kapcsolókat használni és ujratesztelni a már készenlévõ programhegyeket.... Az oprendszerek egész jól kezelik a többmagos rendszereket, inkább a rajtuk futó egyéb alkalmazásokkal van baj, de ez is inkább win alatt gond. Unix-linux alatt nem gond az átállás, ha egyáltalán kell, mert már zömében most is támogatott.
ami a legfontosabb, hogy így nem kellene többszállra programozni, mert a többszálasítást maga a processzor elvégzi saját maga számára
szerintem ezt a programozási válságot úgy lehetne megoldani, hogy nem páros számú processzormagokkal látnák el a processzorokat, hanem pl 2n+1 mag lenne benne, ahol a plusz 1 magnak csak annyi feladata van, hogy minden egyes feladatot x+1-edik processzorhoz oszt ki, majd ezt megjegyezve tudja is hogy honnan kell visszaolvasnia és milyen sorrendben, így cikluskéséssel mûködhetne minden mag, mint az autok esetében a 4 ütem ugyebár, a menet kiegyensúlyozott eloszlásáért, max teljesítményért
copyright c :)
" mert a hagyományos magasabb órajel/kisebb csíkszélesség technológiai fejlesztés elérte a határait."
Nem érte el? Hamarosan itt a 65nm... Órajel mindig emelkedni fog. Csak nem ez lesz az elsõdleges és nem csak ez számít.(erre más most is van példa)
Mobilokba most sem 100W magokat raknak. LÉteznek 25W-os vagy még az alatti elfogadható teljesítményû magok is. Ilyenekbõl is lehet többmagos procit gyártani. És az biztos, hogy X összteljesítmény kisebb fogyasztás árán érhetõ el, ha több magot használunk. Egyébként könnyen lehet, hogy megoldják a hõtermelési problémákat Nemrég volt itt egy cikk, hogy az Intel kifejlesztett egy elég ütõs technológiát erre.
A több mag egyébként nem csak a hõtermelés ellen jó. Az egyre kisebb csíkszélesség egyre komplexebb procikat tesz lehetõvé, és most elértük azt a pontot, ahol a komplexitás növelése már nem jelent plusz teljesítményt. Így fennmarad egy halom tranzisztor, amivel valami mást kell kezdeni. Az egyik megoldás a brutális cache, a másik a magok számának növelése. Ráadásul ez nem is egyszerûen kényszermegoldás, hanem nagyonis jó, és logikus lépés. A számítástechnika kezdete óta nyílvánvaló, hogy a párhuzamosítás nagyon jó dolog, de emellett arra is rájöttek, hogy programozás szempontjából egy rémálom. Ezért nem terjedt el az asztali gépekben, amíg más módon is lehetett a teljesítményt növelni. Szerencsére ma már elég fejlett technikák segítik a programozást.
Mibõl gondolják hogy a jövõben a 4 db mag majd olyan jó keveset fogyaszt hogy mobilba lehet rakni, amikor a többmagos technológiát is pont azért kel bevezetni, mert a hagyományos magasabb órajel/kisebb csíkszélesség technológiai fejlesztés elérte a határait. Ördögi kör.
a teljesítmény növelésének per pillanat egyetlen optimálisan kivitelezhetõ módja a többszálasítás. lehetne tovább tornászni a mhz-ket, de csak iszonytos hõtermelés árán.. ha egy-egy mag lesz legalább 1800-2000mhz-es, akkor miért ne legyen benne 4 mag, vagy akármennyi?
ezek teljesen az asztali PC leváltására hajtanak. reméljük a legjobbakat :) mivel csak tervezgetik ez nem mostanában lesz és addig még sokminden változhat, valszeg a 2 magosak addigra teljesen általánosnak fognak számítani (nem valószínû, h kihagynának egy lépcsõfokot).
noteszbe négy mag? ekkora baromságot ...
Kivancsi vagyok hogy fogjak optimalizalni a programokat ezekre a sokmagos processzorokra...:)
Informatika és tudomány
