A noteszgépeknél is jönnek a négymagos Intel chipek

Hát nem is egyedi utasításokat kell szétosztani, hanem kisebb rutinokat.

(A Cell is tud így mûködni (de teljesen önállóan is mehetnek a vektormagok), igaz, ott a kiosztott feladatok nagyrészt vektormûveletek.)

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.

Félreértettél. Nem a procira mondtam, hogy 1-2 év, hanem a hõtermelést visszafogó technológiára.

nincs más mód, ez a kulcs 😞

É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.

"egyszerüen home szegmensben egy laptopon nincs ilyen igényû program"

Még nincs. De lesz.

"olvastad a register cikkét a 0.65ös xeonokrol? na, ennyit a megoldott hõtermelésrõl"

A technológia vadiúj, még biztosan nem került bele egy prociba se. Majd 1-2 év múlva leghamarabb, szeritnem.

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 😄

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.

Ma menyit fogyaszt manapság egy mag? kb 100W-ot.

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?

nosztalgia gépek rulz

Miért ne?

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...😊