No, beüzemeltem az X2-t. Csináltam egy kis tesztprogit, ami 2 számolós szálat indít. Semmi mást nem kellett tennem, mint fellõni a két szálat ahhoz, hogy mindkét magot kihasználjam. Sõt, 1 szál sem 1 magon fut, hanem ugrál a két mag közt a terhelés függvényében.
"Te mondtad, hogy minden thread-hez child process is kell, hogy mentse a regisztereket (ez esetben ugye adott az 1-1 hozzárendelés)."
Ezen a ponton én is tévedtem, nem kell mindig. Csak fork()-nál (l. #118). Úgy gondoltam, egy új szálhoz kell egy egész process-struktúra, hogy ott tárolódhassanak bizonyos dolgok (stack, program counter mentés, stb.). De nem feltétlenül kell egy egész, csak egy része (amit az alább általad felhozott AxnBeginThread hoz létre). Ilyenkor nem lesz egy valódi új process, csak egy "lightweight process". :)
"Nem a regiszterek mentésérnek konkrét folyamatáról beszéltem, hanem arról, hogy ha mindenképp kell child process a threadhez, akkor azt is az OS intézi, nem kézzel kell létrehozni."
Ja, értem. (Igazából jól írtad le, csak már álmos voltam. :))
"Ez így garantáltan nem igaz. Különben 1 lefagyó progi magával rántraná az egész rendszert."
Hát igen, így frissebb fejjel átgondolva, valóban nehézkes lenne... :) Bár, esetleg elképzelhetõ, hogy ilyen eseteket érzékeljen a rendszer (megszakítások is vannak, lehet pl. egy megszakításban egy számlálót léptetni, stb. - bár ez elég vad dolog lenne :)), és kirúgja azt a processt. Néha elég érdekesen viselkedik a Windows, lehet, hogy valami ilyesmi miatt? :)
"Csak akkor lenne elég processenként menteni, ha annak esetleges több threadjét nem akarjuk (preemptív) multitaskban futtatni."
Teljesen félreértessz. Te mondtad, hogy minden thread-hez child process is kell, hogy mentse a regisztereket (ez esetben ugye adott az 1-1 hozzárendelés). Erre válaszoltam.
"Nyilvánvaló, hogy az OS intézi ezeket. Mit gondolsz, ha nem mentené/töltené a Windows (a szálhoz tartozó stackbe) a regiszereket taszkváltáskor, mi lenne velük? Az AfxBeginThread paraméterei között szerepel is a StackSize."
Nem a regiszterek mentésérnek konkrét folyamatáról beszéltem, hanem arról, hogy ha mindenképp kell child process a threadhez, akkor azt is az OS intézi, nem kézzel kell létrehozni.
"Microsoft introduced cooperative multitasking (which Microsoft refers to as process multitasking) in Windows 3.0. The newest versions of Windows (Windows NT and Windows 95) include preemptive multitasking (but only between the threads of a given process)."
Ez így garantáltan nem igaz. Különben 1 lefagyó progi magával rántraná az egész rendszert.
"Akkor meg kéne különböztetni a thread-et mint fogalma, és mint adatszerkezetet (process dettó)."
Oké, végülis igen. A processen belüli threadet talán szerencsésebb lett volna pl. subthreadnek nevezni. Vagy az egyiket konzekvensen kizárólag "thread of execution"-nak írni (pl. #118), a másikat meg simán threadnek. (De ilyen úgysem lehet elvárni.)
Kezdem azt hinni, hogy nálad nem jelenik meg minden hozzászólás... ;) Pl. #120.
"Persze, de ettõl még a probléma nem oldódik meg."
De az a megoldás kulcsa. És lássék: a #106-os alapján egy program két threadje is futhat más-más procin is akár. De persze lehetséges, hogy itt téved a Wikipedia. (De semmiképp sem biztos.)
"Akkor meg kéne különböztetni a thread-et mint fogalma, és mint adatszerkezetet (process dettó)."
Csak annyit kell tudni, amit a #115-ben leírtam, de adja is magát. Persze laikusoknak így kevésbé egyértelmû. Csakhogy, a programozási fogalmakat alapvetõen a programozóknak találták ki, nem a laikusoknak.
"Implementációs kérdés, hogy a regiszterek thread-enként vagy process-enként mentõdnek."
Tessék? Csak akkor lenne elég processenként menteni, ha annak esetleges több threadjét nem akarjuk (preemptív) multitaskban futtatni.
"Az elsõ esetben nem kell child process, a másodikban kell."
Ez igaz, de itt most a desktop OS-ekrõl beszélünk (azon belül Windowsról), nem valami egyszerûsített embedded rendszerrõl.
"Win-en elég egy új thread-et fellõni (AfxBeginThread), másra nincs szükség (vagy elintézi az OS magában)."
Nyilvánvaló, hogy az OS intézi ezeket. Mit gondolsz, ha nem mentené/töltené a Windows (a szálhoz tartozó stackbe) a regiszereket taszkváltáskor, mi lenne velük? Az AfxBeginThread paraméterei között szerepel is a StackSize.
Viszont... Kicsit jobban utána néztem én is a thread-témának, és azt találtam, hogy van (OS-tõl föggõen is), amikor általánosságban használják a kifejezést (lásd pl. #118), mint fogalom, és van, amikor konkrétan (egy processen belüli függvény threaddá avatása, saját stackkel, handle-lel, stb., és külön szálon futtatása, a la AfxBeginThread)... Ez persze okozhat némi félreértéseket. Rigidus is nyilván az utóbbira asszociált. (De azért 1-2 dologban tévedett.)
Találtam egy érdekes oldalt: http://osl.cpe.ku.ac.th/documentations/book/Netscape_plugin/ch13.htm Idézetek: "Threads are "lightweight processes." They behave like processes in that they support an additional path of execution, but they share the same address space as their parent. Because there is only one address space, there is little need to think about IPC. It also means that a programming error in one thread can ruin data in the other thread."
És ami fõleg érdekes: "Microsoft introduced cooperative multitasking (which Microsoft refers to as process multitasking) in Windows 3.0. The newest versions of Windows (Windows NT and Windows 95) include preemptive multitasking (but only between the threads of a given process)." Wow...
Na mindegy, szerintem tudhat futni egy process két threadje két külön procin is.
"Nem gondolod, hogy a "teljesen világos" egy kicsit túlzás, tekintve, hogy jópárszor ki kellett javítsalak?"
Hol javítottál ki? Nem látom.
"Ejj, nem gondolod, hogy amikor egy vita van a fogalmak nem pontos ismerete miatt, elõször azokat kell tisztázni?"
Persze, de ettõl még a probléma nem oldódik meg.
"Child-processt akkor is létre kell hoznia. Mivel kell, hogy valahol tárolódhassanak a taszkváltásokkor a regiszterek, stb."
Akkor meg kéne különböztetni a thread-et mint fogalma, és mint adatszerkezetet (process dettó). Implementációs kérdés, hogy a regiszterek thread-enként vagy process-enként mentõdnek. Az elsõ esetben nem kell child process, a másodikban kell. Win-en elég egy új thread-et fellõni (AfxBeginThread), másra nincs szükség (vagy elintézi az OS magában).
"Jaj, hát errõl is szó van, nagyon is, mivel errõl is vitáztok, közben egyikõtök számára sem volt igazán világos."
Nekem teljesen világos a dolog. De az alap kérdés nem ez volt, hanem az, hogy a multicore procik kihasználásához az illetõ szoftvernek elég több szálon futnia, vagy több process-t is létre kell hoznia.
"Tehát a kérdés az lehet, hogy egy child-process (azaz a parent-process egy új threadje) futhat-e más CPU-n/magon, mint a parentje."
Szerintem a child process és a thread nem ugyanaz.
Vagy, ha ezt úgy értetted, hogy "egy process új threadje(i) [child-processei] futhat(nak)-e másik CPU-n", akkor tekintsd tágytalannak a "Lehet" utáni részt.
Jaj, hát errõl is szó van, nagyon is, mivel errõl is vitáztok, közben egyikõtök számára sem volt igazán világos.
"a process-hez tartozó thread(ek) futhatnak-e másik CPU-n."
Lehet, hogy még mindig nem világos? Mivel a kérdés az "(ek)" nélkül értelmetlen. Egy process is egy thread önmagában! Nincs olyan, hogy (sima vagy child-)process nélküli thread. Hányszor kell még leírni?
Tehát a kérdés az lehet, hogy egy child-process (azaz a parent-process egy új threadje) futhat-e más CPU-n/magon, mint a parentje. Nos, futhat, miért ne futhatna. Mint ahogy egy procin is futhat SMT rendszerben.
Tehát mégegyszer, hogy világos legyen: minden process egyben egy thread (szál), de nem minden thread teljes értékû process (hanem child-process).
Ha esetleg elolvasnád te is, amiket írtam, te is megspórolhatnál néhány rossz választ... Pl. (Arról nem beszélve, hogy nem illik úgy leírni dolgokat, mintha elõször te írnád le, pedig elõtted már leírták.)
"Mondtam, ha a CPU-knak külön RAM-ja avn, akkor igazad van."
Nincs igaza, mert process instance nélkül nincs thread!
"Simán. Miért ne férnék hozzá?"
Helyett: process (ami lehet child-process is) nélkül megintcsak nincs thread sem.
Idézet a linkbõl: An advantage of a multi-threaded program is that it can operate faster on computer systems that have multiple CPUs
"Szalakat nem tudsz migralni egyik CPU-rol a masikra ha nincs legalabb egy process instance a target CPU-n."
Mondtam, ha a CPU-knak külön RAM-ja avn, akkor igazad van. Viszont ha bármely CPU hozzáfér minden erõforráshoz, akkor minden probléma nélkül át lehet helyezni egy thread-et. ÉS a multicore rendszerek, amelyekrõl itt szó van pontosan ilyenek.
"Ha igy volna akkor a processek nem lennenek kepesek adatcserere."
Az OS biztosít számukra kommunikációs csatornát. Egyébként nem férhetnek hozzá egymás erõforrásaihoz, már csak azért sem, mert (win-en legalábbis) külön címtartományt kapnak.
"Tehat szalat akarsz futtatni egy CPU-n process nelkul?? Hogyan fernel hozza az eroforrasokhoz?"
Simán. Miért ne férnék hozzá?
""Én eddig is arról beszéltem, hogy 2 threadet lõ fel a progi, és az OS szépen kiosztja õket 1-1 CPU-ra." Meg a turot oszt szet. Na eppen ez a baj, hogy errol beszelsz."
Hát pedig minden dokumentáció ezt írja. De haamrosan lesz X2-m, majd jól kipróbálom.
"Ha a parent process nem forkol legalabb egy child processt a target CPU-ra a szal migralasa elott, akkor az a "progi" nem fog semmit oda "felloni"."
Win-en nincs fork.
""Futtathatsz több CPU igényes progit egyszerre, ahhoz nem kell egyiknek se több szálon futni." 1. Tobb szal != tobb process. 2. Kivetel nelkul minden program "CPU-igenyes". 3. CPU-k kozotti elosztott szamitasrol volt szo nem pedig feladatok parhuzamos futtatasarol. 4. A srac hol beszelt szalakrol?"
1. A mondat szempontjából tökéletesen érdektelen. 2. Értelem szerûen arról beszélek, amikor a progi nem 0.01%-ot eszik, hanem minimum 10-20-at.
""Nem ez a gond, hanem az, hogy a ciklusmagban nem tudsz GUI frissítést hívni." Csodas. Itt maris szuletett egy ujabb gyongyszem, ahol az elotte allo ket mondatod meg eppen ezt cafolja: "Le lehet osztani a ciklust. Pl. minden 1000. iterációban frissítek.""
Fork(): "A fork, when applied to computing is when a process creates a copy of itself, which then acts as a "child" of the original process, now called the "parent". More generally, a fork in a multithreading environment means that a thread of execution is duplicated." http://en.wikipedia.org/wiki/Fork_%28computing%29
Ezt: "Ami igy is van, hiszen lehetseges AMP modban tobb processzorra elosztani SP-re megirt alkalmazasokat."
Nos, AMP rendszer - tudtommal, nem találok hirtelen infót róla - pl. egy CPU és egy GPU. (Vagy akár egy CPU és egy FPU, ha azok párhuzamosan futhatnak.) Nyilvánvaló, hogy ilyenkor nem lehet két egyforma ágra bontani a feladatot, csak SMP-ben, azaz amikor a két proci egyforma.
Figyu, Rigidus, úgy látom, nem vagy tisztában a "thread" jelentésével!!! Ez egy fogalom, nem valami konkrét dolog!!! Azt jelenti: "tread of execution"! Azaz, a végrehajtás két szála, amik (látszólag, vagy igazából) párhuzamosan futnak. Lehet az két külön process, és lehet egy processen belül két szál! Amikor a fork()-kal duplikálunk egy processt, és a másolat [ami az elsõ memóriáját használja] külön szálon fut! Olyan utasítás nincs, ami egy "thread"-et indít el csak úgy magában!!!
Továbbá a multithreading és a multiprocessing fogalmakat is! Multiprocessing: ez nem a több process párhuzamos futtatását jelenti, hanem több processor használatát!
Nézzük még1x, amit a #106-osban már idéztem: "A thread in computer science is short for a thread of execution. Threads are a way for a program to split itself into two or more simultaneously running tasks. (The name "thread" is by analogy with the way that a number of threads are interwoven to make a piece of fabric). Multiple threads can be executed in parallel on many computer systems. This multithreading generally occurs by time slicing (where a single processor switches between different threads) or by multiprocessing (where threads are executed on separate processors). Threads are similar to processes, but differ in the way that they share resources."
"1. Tobb szal != tobb process."
De! Ezt is jelentheti!
"2. Kivetel nelkul minden program "CPU-igenyes"."
Ez nem így van. Lehet írni olyan programot, ami csak akkor kapja meg a CPU-t egy rövid idõre, amikor a user hozzányúl a GUI-hoz, és egyébként "alszik".
"3. CPU-k kozotti elosztott szamitasrol volt szo nem pedig feladatok parhuzamos futtatasarol."
Adott esetben a kettõ ugyanaz.
"4. A srac hol beszelt szalakrol?"
Így már talán látod, hol.
" "Tehát a thread és a process közt az a különbség, hogy a thread-eknek lehetnek közös erõforrásaik (pl. memória), a process-eknek meg nem."
Pont ez az, hogy nem. Eleg nagy gaz lenne. Ha igy volna akkor a processek nem lennenek kepesek adatcserere."
Nono, ha olyan könnyen cserélgethetnék az adatokat, akkor nem lenne memóriavédelem! Minden processhez saját virtuális memória tartozik! Tehát egymás memóriaterületét még csak nem is látják. Lásd: "Memory protection is a system that prevents one process from corrupting the memory of another process running on the same computer at the same time. It usually employs hardware (i.e. a memory management unit) and system software to allocate distinct memory to different processes and to handle exceptions arising when a process tries to access memory outside its bounds. http://en.wikipedia.org/wiki/Memory_protection
ps. jók ezek a dõltbetûs idézetek, csak az a baj velük, hogy egy copy-paste után eltûnnek, és állandóan vissza kell nézni, hogy ki mit írt...
"Még mindíg nem magyaráztad el, hogy miért ne lehetne simán csak szálakat használni." Thread.
Ezert: "A thread is the "lightest" unit of kernel scheduling. At least one thread exists within each process."
Es ezert: Threads do not own resources except for a stack and a copy of the registers including the program counter.
Hogyan fer akkor hozza a memoriahoz? Hogyan fogja ertelmezni a kernel? Vizualisabban juzer szemmel: Mit fogsz latni a "task manageredbe"? Mesztelen szalat process helyett?? (egyebkent sem mutat szalakat)
Szalakat nem tudsz migralni egyik CPU-rol a masikra ha nincs legalabb egy process instance a target CPU-n.A szal nem tud eroforrasokat birtokolni anelkul, hogy lenne a se33e alatt legalabb egy process.
"Lehet, hogy valami fogalmi keveredés ven itten?"
Igen, az van.
"Tehát a thread és a process közt az a különbség, hogy a thread-eknek lehetnek közös erõforrásaik (pl. memória), a process-eknek meg nem.
Pont ez az, hogy nem. Eleg nagy gaz lenne. Ha igy volna akkor a processek nem lennenek kepesek adatcserere.
Tehát szó nincs arról, hogy az azonos process-hez tartozó thread-eknek ugyanazon a procin kéne futniuk."
Tehat szalat akarsz futtatni egy CPU-n process nelkul?? Hogyan fernel hozza az eroforrasokhoz?
"Hol jön be új dolog? Én eddig is arról beszéltem, hogy 2 threadet lõ fel a progi, és az OS szépen kiosztja õket 1-1 CPU-ra.
Meg a turot oszt szet. Na eppen ez a baj, hogy errol beszelsz.
Ha a parent process nem forkol legalabb egy child processt a target CPU-ra a szal migralasa elott, akkor az a "progi" nem fog semmit oda "felloni".
"Miért kéne a parent process-t belekeverni a dologba???
Hat eppen ezert.
""... ahhoz nem kell egyiknek se több szálon futni." Na itt vannak a bajok. Ez mar egy {Tema 3.}"
Nem értem mi a gond.
Az, hogy a mondatod elejevel egybeolvasva az egesz ertelmezhetetlen.
"A multithreaded programming es a multiprocessed programming ket kulonbozo dolog."
Jó, és?
A valaszom stilszeruen csak ennyi:
Futtathatsz több CPU igényes progit egyszerre, ahhoz nem kell egyiknek se több szálon futni.
1. Tobb szal != tobb process. 2. Kivetel nelkul minden program "CPU-igenyes". 3. CPU-k kozotti elosztott szamitasrol volt szo nem pedig feladatok parhuzamos futtatasarol. 4. A srac hol beszelt szalakrol?
"Nem ez a gond, hanem az, hogy a ciklusmagban nem tudsz GUI frissítést hívni."
Csodas. Itt maris szuletett egy ujabb gyongyszem, ahol az elotte allo ket mondatod meg eppen ezt cafolja:
"Le lehet osztani a ciklust. Pl. minden 1000. iterációban frissítek."
"SMP-t meg ott alkalmaznak ahol a hardver lehetove teszi egyetlen alkalmazas elosztott szamitasat tobb CPUn."
Na, én errõl beszélek. De nem értem, hogy mi a problémád. Ehhez nincs szükség külön process-re, elég csak külön thread"
NEM LEHET! Process nelkul nincs szal! Ennyi.
Az idezet meg nem errol szol. Az egy osszehasonlitas a processek es threadek termeszeteben.
"NEM TOBB SZALON, HANEM TOBB PROCESS-EN!"
Még mindíg nem magyaráztad el, hogy miért ne lehetne simán csak szálakat használni. Lehet, hogy valami fogalmi keveredés ven itten? Én a dez által idézett definíciókat használom. Tehát a thread és a process közt az a különbség, hogy a thread-eknek lehetnek közös erõforrásaik (pl. memória), a process-eknek meg nem. Tehát szó nincs arról, hogy az azonos process-hez tartozó thread-eknek ugyanazon a procin kéne futniuk.
"Most meg hoztal egy negyedik dolgot, ahol meg kombinaltan multithreadre es SMP-re megirt alkalmazast futtatnak, ahol arrol targyal, hogy teljesitmeny elosztas celjabol a tread migralhato masik parent processhez."
Hol jön be új dolog? Én eddig is arról beszéltem, hogy 2 threadet lõ fel a progi, és az OS szépen kiosztja õket 1-1 CPU-ra. Miért kéne a parent process-t belekeverni a dologba??? Valahol nagyon elbeszélünk egymás mellett.
""... ahhoz nem kell egyiknek se több szálon futni." Na itt vannak a bajok. Ez mar egy {Tema 3.}"
Nem értem mi a gond. Tübb szálon kell futnia egy proginak ahhoz, hogy egy többprocis rendszer EGYIK prociját használja??? Az egyik progi az egyik procin a másik a másokon fut és kész. Ez akár DOS progi is lehet, ami a thread fogalmát sem ismeri.
"A multithreaded programming es a multiprocessed programming ket kulonbozo dolog."
Jó, és?
"Tobbszalu programozas celja, hogy egy alkalmazason belul parhuzamos feladatokat szeparaltan tudjal futtatni."
Persze.
"Legyen itt egy konkret problema: van egy media encoder programod ahol kalkulaciot kell vegezni, ill. a kepernyon egy folyamatjelzo savot leptetni kell, hogy a kedves juzer lassa, hogy hol tart. A gond az, hogy itt a fociklusod masodpercenkent lefut n-szer (pl: n=1000000). Egy GUI frissites kb egy ezredmasodpercet vesz el a futasidobol. (t=0.001s) Ha a ket eltero feladatot egy szalon programozod le akkor a folyamatjelzot minden ciklus elejen/vegen frissitened kell. Kerdes: kell a gui-t masodpercenkent millioszor frissiteni? Szorozd ossze a ket szamot."
Le lehet osztani a ciklust. Pl. minden 1000. iterációban frissítek. Nem ez a gond, hanem az, hogy a ciklusmagban nem tudsz GUI frissítést hívni. Illetve fõképpen nem tudsz user input-ot feldolgozni (tehát pl. a user nem tudja megszakítani a folyamatot).
"SMP-t meg ott alkalmaznak ahol a hardver lehetove teszi egyetlen alkalmazas elosztott szamitasat tobb CPUn."
Na, én errõl beszélek. De nem értem, hogy mi a problémád. Ehhez nincs szükség külön process-re, elég csak külön thread (errõl szól az idézet). Persze ha a HW és az OS is támogatja. Nyílván, ha a prociknak fizikailag külön RAM van, akkor ez nem müxik.
"Ez már nem csak feltételezés, hanem egy ellenõrzött tény. Azzal a pontosítással, hogy nem egy bármilyen képrõl van szó (azt több tulajdonság alapján jegyezzük meg, ismerjük fel), hanem arcokról. Ha elpusztul az adott agysejt (fontosabb agysejtek nem pusztulnak el csak úgy), a tulajdonságai alapján is ismerõs lesz, de "nem ugrik majd be"."
Azért így mindjárt más. Meg gonyolom itt sem arról van szó, hogy a sejt kap egy bitmap-et, és azt ismeri fel, hanem a kép végigmegy egy nagy halom elõfeldolgozáson, és a sejtnek egy jellemzõ halmazt kell felismernie.
Mondjuk, ez, hogy "This multithreading generally occurs by time slicing (where a single processor switches between different threads) or by multiprocessing (where threads are executed on separate processors)." már egy kicsit elavult, lássátok #104. Szal ez lehet az említett multitasking mellett CMT (több mag), és SMT is.
Tehát: a "többszálú (végrehajtás)" többmindent is jelenthet, nem csak azt, hogy egy proccessen belül több szál.
És még valami: "A thread in computer science is short for a thread of execution. Threads are a way for a program to split itself into two or more simultaneously running tasks. (The name "thread" is by analogy with the way that a number of threads are interwoven to make a piece of fabric). Multiple threads can be executed in parallel on many computer systems. This multithreading generally occurs by time slicing (where a single processor switches between different threads) or by multiprocessing (where threads are executed on separate processors). Threads are similar to processes, but differ in the way that they share resources." http://en.wikipedia.org/wiki/Thread_%28computer_science%29
"A kissrac itt (SMP) Symmetric Multiprocessing-re gondolt es ez ugy jott le, mint egyetlen lehetseges mod a MP kihasznaltsagara."
Nem feltétlenül. Az SMP több processzor (egyenrangú) felhasználását jelenti (amik nem egy tokban vannak.) Lásd wikis linked. Tehát a fenti jelenthet - és most jelent is - CMP-t is. Sõt, akár SMT-t is! (Lásd #102.) A programnak mindegy, hogy két procin, két magon, vagy egy magon belüli megkettõzött egységeken fut párhuzamosan. Sõt, itt a programon van a lényeg (hogy úgy van-e megírva, hogy kihasználhassa ezt), nem azon, hol és hogy fut.
"Ami igy is van, hiszen lehetseges AMP modban tobb processzorra elosztani SP-re megirt alkalmazasokat."
Az AMP nem inkább az, amikor a több processzor(-mag, stb.) nem egyenrangú, azaz eltérõ funkciójú...?
Több szál/több process kérdéskör: szerintem a "több szál" kifejezést sokszor használják a több process esetére is (mármint szakemberek is). Lásd pl. #102.
Hm, azért van itt némi szõrszálhasogatás... :) Na jó, pontosítási igény.
De pl. ttt van pl. az SMT (szimultán multi-threading). Egyes procikban hw-esen implementálva van, és ha elég jól meg van csinálva, majdnem(!) olyan, mintha két mag lenne. Elnevezéstõl függetlenül tudja egyszerre futtatni egy process két threadjét, és két processt is.
Én arról beszélek, amikor a CPU igényes számolást futtatja több szálon.
NEM TOBB SZALON, HANEM TOBB PROCESS-EN!
Nem arról van szó, hogy több szálon fut a progi. Olyan persze millió van. Én arról beszélek, amikor a CPU igényes számolást futtatja több szálon. A játékok többsége ezt jelenleg nem teszi meg (lásd tesztek)."
"On multiprocessor machines, the scheduler can move individual threads to different processors to "balance" the CPU load."
Andras te valamit nagyon keversz.
Most meg hoztal egy negyedik dolgot, ahol meg kombinaltanmultithreadrees SMP-re megirt alkalmazast futtatnak, ahol arrol targyal, hogy teljesitmeny elosztas celjabol a tread migralhato masik parent processhez.
Na essunk neki megegyszer:
{Tema 1.} rolika irta: "Ahoz hogy kihasználd nem csak az oprendszernek kell tudni használni,hanem az a programozó aki a progit írja"
A kissrac itt (SMP) Symmetric Multiprocessing-re gondolt es ez ugy jott le, mint egyetlen lehetseges mod a MP kihasznaltsagara.
{Tema 2.}Te helyesbitettel neki: "Nem feltétlen. Futtathatsz több CPU igényes progit egyszerre..."
Ami igy is van, hiszen lehetseges AMP modban tobb processzorra elosztani SP-re megirt alkalmazasokat.
Majd vesszovel elvalasztva a masodik tomondatod: "... ahhoz nem kell egyiknek se több szálon futni." Na itt vannak a bajok. Ez mar egy {Tema 3.}
A multithreaded programming es a multiprocessed programming ket kulonbozo dolog. Az egyik hegesztopisztoly a masik meg mikieger. Az egy dolog, hogy hegesztes kozben lehet mikiegeret nezi, ettol meg a kettonek semmi koze nincs egymashoz.
Lecke: Tobbszalu programozas celja, hogy egy alkalmazason belul parhuzamos feladatokat szeparaltan tudjal futtatni.
Legyen itt egy konkret problema: van egy media encoder programod ahol kalkulaciot kell vegezni, ill. a kepernyon egy folyamatjelzo savot leptetni kell, hogy a kedves juzer lassa, hogy hol tart. A gond az, hogy itt a fociklusod masodpercenkent lefut n-szer (pl: n=1000000). Egy GUI frissites kb egy ezredmasodpercet vesz el a futasidobol. (t=0.001s) Ha a ket eltero feladatot egy szalon programozod le akkor a folyamatjelzot minden ciklus elejen/vegen frissitened kell. Kerdes: kell a gui-t masodpercenkent millioszor frissiteni? Szorozd ossze a ket szamot.
Na ilyenkor alkalmaznak tobb szalat. Az egyiken megy a kalkulacio, a masikon pedig egy keslelteto ciklus ami annyiszor fut csak le ahanyszor frissiteni kell a gui-t. (IMHO ebben az esetben 10s boven eleg) A frissites idejere a ket szalat szinkronizaljak, majd a szinkronizalaskor letrejott osztott memoriateruleten megtortenik az ertekcsere.
Ez egyetlen process-en belul zajlik.
A legegyszerubben ugy lehet ezt vizualisan szemleletetni, hogy van egy vasutallomas (CPU) es egy vegtelenitett vasuti vagany (thread) amelyen egy vonat (feladat) halad, korkoros uton. Van egy masik vagany+vonat is amely az elozo vagannyal parhuzamosan halad, szinten vegtelenitve. Az egyikuk sebessege 1000000 km/s a masikuk sebessege 10 km/s (csak a szamok miatt legyen, a termeszetben ez persze lehetetlen). Informaciot csak ugy tudnak cserelni, ha egymast bevarjak es fej-fej mellett haladnak az informaciocsere idejere. Ertelem szeruen minnel kevesebbszer kell lelassitani a gyorsabbik vonatot annal jobb.
Na, szerintem ezt tultargyaltuk.
SMP-t meg ott alkalmaznak ahol a hardver lehetove teszi egyetlen alkalmazas elosztott szamitasat tobb CPUn. Ahol kepzelj el egy harmadik vonatot+vaganyt, amely egy masik vasutallomashoz (cpu-hoz) tartozik. Az, hogy itt is lehetnek egymas mellett halado vaganyok es kombinalhato az elozo peldaval, az egy dolog. Na ez az amit te belinkeltel. Ez mar lehetne egy {Tema 4.}
Irtam neked egy kilometert es remelem ezuttal megerte.
"Azt ne felejtsd el, hogy az agysejt nem csupán számol, hanem egy egész élõ szervezet. Rengeteg dolga van a számoláson kívül is."
Valszeg az idegrendszer szempontjából sem csak "számol".
"Az információ feldolgozásban a szerepe anniy, hogy kap pár száz/ezer bemenõ impulzust, és ezek alapján vagy küld jelet, vagy nem."
Nem vagyok benne biztos, hogy azokból az egymás utána küldött jelekbõl nem áll egy össze egy "adatcsomag".
"Ezzel elvileg akár lehetne is képet felismerni, de ez nagyon komplex belsõ mûködést igényelne, ami nincs meg. Másrészt nagyon nem hatékony, mert így minden egyes képet külön kéne megtanulni, és ráadásul nem tudnánk, hogy mi van a képen, csupán felismerni tudnánk. És ha az 1db sejt véletlen elpusztul, akkor nem lennénk képesek felismerni a képet."
Ez már nem csak feltételezés, hanem egy ellenõrzött tény. Azzal a pontosítással, hogy nem egy bármilyen képrõl van szó (azt több tulajdonság alapján jegyezzük meg, ismerjük fel), hanem arcokról. Ha elpusztul az adott agysejt (fontosabb agysejtek nem pusztulnak el csak úgy), a tulajdonságai alapján is ismerõs lesz, de "nem ugrik majd be".
De, de tranzisztorból hányféle van? A +Ghz-s proci tényleg gyorsabb, de bonyolultabb is. Egy procit képesek vagyunk felépíteni, egy sejtet meg nem, legalábbis eddig.
"Egyetlen sejtet képzelj csak el rendesen, talán még az se menne részletesen, most néztem utána a bioszkönyvben, hogy milyen is egy szinapszis: kémiai anyagokkal kommunkikálnak az idegsejtek, mennyi adatot hordozhatnak azok a kémiai anyagok, megnézve, hogy pl. mennyi adat kell nekünk egyetlen fehérje leírására, a test egyetlen DNS molekulájában csak kb. 10-20% annak a sok fehérjének a leírása, ami a testünkben van."
Azt ne felejtsd el, hogy az agysejt nem csupán számol, hanem egy egész élõ szervezet. Rengeteg dolga van a számoláson kívül is. Az információ feldolgozásban a szerepe anniy, hogy kap pár száz/ezer bemenõ impulzust, és ezek alapján vagy küld jelet, vagy nem. Ezzel elvileg akár lehetne is képet felismerni, de ez nagyon komplex belsõ mûködést igényelne, ami nincs meg. Másrészt nagyon nem hatékony, mert így minden egyes képet külön kéne megtanulni, és ráadásul nem tudnánk, hogy mi van a képen, csupán felismerni tudnánk. És ha az 1db sejt véletlen elpusztul, akkor nem lennénk képesek felismerni a képet.
"A jel az idegrostban kb. 120m/s-os sebességgel is terjedhet, azaz kb. 60 jel mehet végig a testeden másodpercenként."
Egy 3GHz-es procin másodpercenként 3 milliárd jel megy végig.
"Egyetlen sejtünk komplexebb, szerintem, mint egy szuperszámítógép."
Mûködésben, vagy felépítésben? És biztos, hogy komplexebb? Egy mai átlag proci 300 millió tranzisztorból áll (és 1 tranzisztornak is van belsõ szerkezete), az nem elég komplex?
"Hemzsegnek meg a te gepeden is. Az osszes jatek ahol kep-hang parhuzamosan fut, medialejatszo programok, CD/DVD ripperek, multimedias encoderek/decoderek, CD-DVD iro alkalmazasok, multimedias szerkesztoprogramok, stb..."
Nem arról van szó, hogy több szálon fut a progi. Olyan persze millió van. Én arról beszélek, amikor a CPU igényes számolást futtatja több szálon. A játékok többsége ezt jelenleg nem teszi meg (lásd tesztek).
"Andras, egy alkalmazas futtatasa tobb CPUn es tobb szalon, az ket kulonbozo dolog"
Természetesen. Nem is állítottam mást. Arról volt szó, hogy ha az embernek van egy többmagos procija, akkor azt hogy leeht kihasználni. Erre az egyik megoldás, hogy 1 progi használ több magot, a másik meg hogy több progi fut egyszerre.
"Az, hogy hany szalon fut egy process, tokmindegy, mivel a szal ugy sem tud migralni masik CPUra."
Erre azt szokták válaszolni, hogy a modellezéshez nincs szükség minden funkció szimulálásáa. Viszont túl leegyszerûsítõk a modellek. (Egyébként a neurotranszmitterekkel kapcsolatban is kiderült az utóbbi években, hogy több információt hordoznak, mint korábban feltételezték.)
A 3D-s kép valójában 2 db 2D-s kép, amit a szemek rögzítenek, ezek a látóidegek találkozásánál keverednek, fele-fele arányban kb., aztán az agy hátsó részén két terület elemzi a két adatfolyamot, aztán a két terület összevetíti a képet egy harmadik agyterületen, mindezt másodpercenként többször. És baromi pontosan, vannak emberek, akik rágyúrtak a "szemmértékre", és jócskán pontosabbak, mint a vonalzó. Egyetlen agysejt meg ráadásul asszem akár több száz szinapszist is létesíthet, a neuronok meg alkotnak ezzel egy eléggé komplex hálót, ami ráadásul egyre bonyolultabb életünk folyamán.
Egyetlen sejtet képzelj csak el rendesen, talán még az se menne részletesen, most néztem utána a bioszkönyvben, hogy milyen is egy szinapszis: kémiai anyagokkal kommunkikálnak az idegsejtek, mennyi adatot hordozhatnak azok a kémiai anyagok, megnézve, hogy pl. mennyi adat kell nekünk egyetlen fehérje leírására, a test egyetlen DNS molekulájában csak kb. 10-20% annak a sok fehérjének a leírása, ami a testünkben van. A jel az idegrostban kb. 120m/s-os sebességgel is terjedhet, azaz kb. 60 jel mehet végig a testeden másodpercenként. Egyetlen sejtünk komplexebb, szerintem, mint egy szuperszámítógép. És még csak nem is ismerjük rendesen a mûködését.
"Az hogy miért nincs egy gépben 128nál több processzor az azért van mert a processzoroknak valahogy hozzá kell férniük a ramhoz.Na most ezt osztottan teszik,és állandóan frissiteniük kell a tartalmat bizonyos algoritmusok szerint hogy a többi proceszor is aktuális adatokkal tudjon dolgozni. Innentõl kezdve egyszerüen 128 proci felett annyira belassul a rendszer az állandó frissitgetések miatt hogy nincs értelme több procinak.Sõt legtöbb esetben 64 proci alatt maradnak mert onnantól kezdve mérhetõ a lassulás."
Nem tudom, ez milyen rendszerre vonatkozik - egy mai PC-s rendszerben 4 magot sem tud lassulás nélkül kiszolgálni a RAM...
"Viszont a multkor olvastam valahol hogy a kutatók azt vizsgálták hogy egy fénykép felismeréséhez hány agysejt kell,és arra jöttek rá hogy 1.Tehát az ember agyának egy sejtje ismer fel egy képet.Nekünk ehhez mennyi processzor kell?"
De egy-egy modul (kép, hang, stb.) egy szálú. Az lenne az igazi, ha azok is tudnának többszálon futni (méghozzá alkalmazkodva a rendelkezésre álló procik számához).
"aztne mond, hogy tudatalatt már rég megvan az eredménye :D csak tudatosan nem tudja :DD LOL"
Pedig pontosan így van... Legtöbben az ember tudatos képességeire gondolnak csak, amikor az agyról van szó, de az csak a jéghegy csúcsa. (Vagy inkább egy hegymászó. :D)
"a lépcsõmászást meg nagyban elõsegíti az emberi szem 3 dimenziós látása"
Ehh, és szerinted azt nem az agy számolja??? :D
"meg egyértelmû, hogy az ember elsõnek inkább magasabbra emeli a lábát, mert onnan tuti nem bukik meg a lépcsõben és csak utána teszi le, majd ezt érezve már kevésbé magasra teszi következõnek a lábát... ezt logikailag egyáltalán nem nehéz megmondani egy számítógépnek!"
Na de utána megjegyzi a magasságot (1mm-es pontossággal), és utána már ennek alapján irányítja a lépést az agy. Amúgy tutod te, hány izmot kell szimultán (+ oda-vissza hatásokat is figyelembe véve) irányítani? Mellesleg már elõre elég pontosan megbecsüljük a magasságot "szemmérték" alapján. (Próbáld ki, hogy úgy kezdesz neki egy lépcsõnek, hogy nem nézel oda.)
Kömlõdi Ferenc: : HAL gyermekei. Mesterséges elmék "A tudományos-fantasztikumból átvett kép – emberrel legalább egyenértékû, kommunikációra, logikus gondolkodásra képes gépi értelem, a Homo sapiens és a gép konvergenciája – bármily hatásos volt is a moziban, inkább ártott, mint használt a tényleges kutatásoknak."
"Arról volt szó, hogy ma még ritkák a valódi multithread progik."
Dehogy azok. Hemzsegnek meg a te gepeden is. Az osszes jatek ahol kep-hang parhuzamosan fut, medialejatszo programok, CD/DVD ripperek, multimedias encoderek/decoderek, CD-DVD iro alkalmazasok, multimedias szerkesztoprogramok, stb...
Felsorolni is lehetetlen.
Ami az OS-eket (pl. WinServer) illeti, nem kizárt, sõt biztosra vehetõ, hogy ha a processzorok többmagossak lesznek ezt ki fogják majd tudni használni, jelenleg teljessen felesleges, hogy a meglévõ OS-ek ezt támogassák, és mivel a többprocesszoros szerverek 99% a 2, 4 és 8 processzorosokba tartozik, a Windows skálázhatósága is ebbõl ered, ugyan vannak 16 meg 32 meg 64 processzoros szerverek is, de ezek tényleg elég ritkák. Különben már elfogadott dolog, hogy a skálázhatóságot a clustereken keresztül sokkal jobb ROI-val lehet megoldani, éppen ezért sokkal gyakoribbak a 2 vagy 4 processzoros szerverek clusterben mint a stant-alone 8-nál több processzoros gépek. Különben a párhuzamosítást álltalában a szerverek tudják kihasználni, de ha elterjed és a fejlesztõk tapasztalatot szereznek az egyébként nem egyszerû párhuzamos programozásban akkor a home és persze desktop üzleti alkalmazások is sokkal nagyobb teljesítményre lesznek képessek mint a jelenlegi szoftver. Persze ehhez idõ kell, meg ugye még valami a úgynevezett "user paradigm shift" vagyis a usereknek fel kell emelkedniük egy magasabb szintre, hogy ez mikor lesz azt nem tudnám megmondani, de idõvel fokozatossan be fog következni, mindenesetre jómagam nem tudom elképzelni, hogy a mai összetett magokból többszáz legyen egy prociban. Ami pedig a simple processzing unit párhuzamosítást illeti, az valószínüleg hamarossal megérkezik, de nem hiszem, hogy mint általános processzor a gépben, ugyanis az ilyen processzorok programozása teljessen másképpen türténik, és itt inkább egyfaljta önszervezõdésrõl beszélünk (pl, neurális hállózatok, cell automatták stb. - jó öreg Neumann János...) napról napra több potenciális alkalmazás ezeken az alapokon sokkal jobban mûködne mint a szekvenciális architektúrákon, és ezért a következõ 10 évben valószínüleg specializált párhuzamos processzorok zöme fog megjelenni, de ennek vajmi kevés közük lesz az x64-hez vagy a hasonló általános processzor architektúrákhoz. Különben a Sun Niagara is ezt az utat mutatja, 8 mag, de jóval egyszerübb mint az elõdjei, de az alkalmazásterülete is már inkább specializálodott mint webkiszolgáló, a jövõben csak hasonló specializálódott processzorokat várhatunk, de ez a generális, mindenhez megfelelõ persze megmarad, de mellé lesz majd rendelve egy csomó specializálodott co-processor. Különbözõ területekre meg akár speciális processzorokkal ellátott gépek is kerülnek, mert olcsobb lesz megoldani és persze minek a felesleges része. Egy webkiszolgálónak nincs szüksége GFlops FPU-ra, ennek helyében olyan architektúra foglalja el helyét amely a webkiszolgáláshoz optimizált. Mindenesetre a jövõben felbukkanó problémákat mindég nehezebb lesz brute-force metódussal megoldani (ez már látszik a GHz feltekerésének megállásával is, és a multicore is csak egy rövid ideig lesz megoldás), és inkább jön a speciális processzorok kora, persze nem kizárt, hogy több féle egymással együttmûködõ egyszerübb specializált magból akár többszáz is lesz majd egy chipen.
"de az sgi nem nodeterminlogiat hasznal mivel az sgi gepek nem klaszterek hanem SSI-k"
Tiszta sor. De klaszterbe foglalhatoak ahol egy gep egy node, egy geptag egy brick. (nezd meg mit irtam lent, brickenkent 1024, vagy node-onkent)
Innen --> "Futtathatsz több CPU igényes progit egyszerre, ahhoz nem kell egyiknek se több szálon futni."
Andras, egy alkalmazas futtatasa tobb CPUn es tobb szalon, az ket kulonbozo dolog, a kettonek semmi koze egymashoz, azonkivul, hogy elmeleti szinten mindketto parhuzamos programozast igenyel.
Ahhoz, hogy tobb CPUn futtassal egyetlen alkalmazast ahhoz SMP kompatibilis kodot kell irni, vagyis az alkalmazas tobb process-en fog futni. Ez lenne az SMP amirol a srac beszelt lentebb.
Amirol te beszeltel, az az AMP, ahol az egyes alkalmazasok az alacsonyabb load-dal rendelkezo CPU-ra migralnak, de mindegyikuk standalone-processt alkot. Te idekevertel egy harmadik fogalmat, a tobbszalu programozast, en csak erre vilagitottam ra.
Az, hogy hany szalon fut egy process, tokmindegy, mivel a szal ugy sem tud migralni masik CPUra. Ahhoz, hogy az egy alkalmazas tobb CPUn fusson, CPUnkenti - legalabb egy - parent process nelkul elkepzelhetetlen.
Egy adott alkalmazas feloszthato processekre, egy process feloszthato, szalakra. Az, hogy egy alkalmazast hogyan bontanak szet parhuzamos vegrehajtasra, az a celtol/hardvertol fugg.
"Te most az SMP-rol beszelsz, de akkor hogy jon a kepbe multithread?"
Arról beszélek? Honnan veszed? Arról volt szó, hogy ma még ritkák a valódi multithread progik. Err mondtam, hogy nem kell annak lennie, elég ha több fut egyszerre.
"A legtobb asztali alkalmazas multithread-re van irva legalabb tiz evre visszamenoleg. Beleertve a legtobb jatekot is."
Ez nem igaz. Csak azok multithread-esek, amikhez többprocis gépek kellettek régen, és nem nehéz õket így megírni (pl. videotömörítés). A játékok kifejezetten 1 szálra készültek. A tesztek is remekül mutatták, hogy néhány kivételtõl eltekintve a játékok alatt az egyik mag csutkán van terhelve a másik meg üresjáratban megy.
"Sokszor 1-1 agysejt lát el olyan funkciókat, amire nekünk egy egész számítógép kellene."
Erre írnál valami példát? Én nem hallottam még ilyenrõl. Meg elképzelni is nehéz, egy sejt szerintem max. egy nagyon egyszerû analóg áramkört helyettesíthet.
Juteszembe, a win2k03 datacenter edition az SMP / NUMA v vmi egesz mas modell szerint fer a ramhoz? azz irix amugy tudommal nem kezel nodeonkent 1024 procit, az SGI SSI (SingleSistemImage) gepein szuzi linux fut, specialis NUMA kernellel, a nodeok kozott pedig a craytol orokolt lowlatency supercomputer interconnect interface van...es ha mar ittartunk nemis nodenak hivja az sgi hanem bricknek :) van cpu brick, io brick, stb. (najo ez csak szorszalhasogatas) btw a hirek es pletykak szerint keszul a win2k03 hpc verzioja :) ra is fer meg a win eleg szarul skalazodik 16 cpu felett (bar ez inkabb a pc architektura korlatja mint a wine)
"Nem feltétlen. Futtathatsz több CPU igényes progit egyszerre, ahhoz nem kell egyiknek se több szálon futni."<- Na mibe fogadunk? :-)) Írtam 1 álomfejtõ progit, ha 100 progit indítasz belõle vagy 1000-t a másik magot meg sem fogja hatni! XP alatt azt még hozzátenném."
Honnan tudod, hogy nem fogja meghajtani a másik magot? Netán próbáltad? És akiknek most is van kétprocis, vagyx kétmagos, vagy csak simán HT-s procijuk, azoknak miért megy mindkettõ rendesen? Volt régebben olyan teszt is, ami direkt azt nézte, hogy ha játék közben elindítunk egy tömörítést, akkor mi lesz. Nos az lett, hogy a dualcore procikon a játék ugyanúgy futott tovább, mintha nem is menne más közben.
"A 64 bites 2K3 datacenter server pl. 64 procit képes kezelni."
Irix meg node-onkent 1024-et.
"Nem feltétlen. Futtathatsz több CPU igényes progit egyszerre, ahhoz nem kell egyiknek se több szálon futni.
Te most az SMP-rol beszelsz, de akkor hogy jon a kepbe multithread? A legtobb asztali alkalmazas multithread-re van irva legalabb tiz evre visszamenoleg. Beleertve a legtobb jatekot is.
lehet 100 mag, lehet 10ghz is, de az nem a ma ismert x86 cpu-ra értendõ ... ld. power6, ott is erõsen butitanak a magokon, lehet ez a jövõ: több, de butább mag.
viszont, arról meg vagyok gyõzõdve, hogy ez a faszi a mostani magokról képzeli, h 100 db lesz egyben :) mit neki hûtés, még ha csak 5W-ot is enne egy db ...
Meg persze, ki tudná ezt megvenni otthonra? Black Rose jól irta, otthonra ez elég életképtelen elképzelés ... az viszont valószínû, h más ötletük jelenleg nincs, mint a magok soxorozása :))) Látszik ahogy kapálózik mind2 gyártó ... :(
Az hogy miért nincs egy gépben 128nál több processzor az azért van mert a processzoroknak valahogy hozzá kell férniük a ramhoz.Na most ezt osztottan teszik,és állandóan frissiteniük kell a tartalmat bizonyos algoritmusok szerint hogy a többi proceszor is aktuális adatokkal tudjon dolgozni. Innentõl kezdve egyszerüen 128 proci felett annyira belassul a rendszer az állandó frissitgetések miatt hogy nincs értelme több procinak.Sõt legtöbb esetben 64 proci alatt maradnak mert onnantól kezdve mérhetõ a lassulás.
Akuma:Nem nehéz, csak rettentõ sok számolást igényel hogy egyensulyban maradjon és ne essen el a robot.Arról nem beszélve hogy mi vaa ha mozog az a lépcsõ... És egyszerüen hiába használsz szuperszámitógépeket amik mpként többszázmilliárd müveletet tudnak végrehajtani, igy is túl lassú lesz az egész,túl sok számolást igényel.Ezért lépeget egy robot olyan tetülassan. Viszont a multkor olvastam valahol hogy a kutatók azt vizsgálták hogy egy fénykép felismeréséhez hány agysejt kell,és arra jöttek rá hogy 1.Tehát az ember agyának egy sejtje ismer fel egy képet.Nekünk ehhez mennyi processzor kell?Szóval az MI még nagyon nagyon messze van.
aztne mond, hogy tudatalatt már rég megvan az eredménye :D csak tudatosan nem tudja :DD LOL a lépcsõmászást meg nagyban elõsegíti az emberi szem 3 dimenziós látása meg egyértelmû, hogy az ember elsõnek inkább magasabbra emeli a lábát, mert onnan tuti nem bukik meg a lépcsõben és csak utána teszi le, majd ezt érezve már kevésbé magasra teszi következõnek a lábát... ezt logikailag egyáltalán nem nehéz megmondani egy számítógépnek!
Lásd #44-es hozzászólásom. Attól még,hogy tudatosan lassan számol az ember, tudatalatt elég furi dolgokat mûvel, mit gondolsz miért volt nagy dolog, hogy egy robot képes volt lépcsõt mászni? Az ember kb. 1 mm-es pontossággal kiszámolja (fejben) a lépcsõfokok magasságát és 3 lépcsõfok után beáll erre az értékre, ha megbuksz a lépcsõn, ott van, akár csak 1-2 mm-nyi eltérés.
álmodozzon még mindenki nyugodtan, én is nemrég keltem, de ideje lenne már felébredni :-) a jelenlegi kétmagos rendszerek sincsenek kihasználva, akkor meg nemtudom miért kell több száz magról beszélni... most az Intel is kampányol vagy mi??? õk 4 magot mondanak, AMD meg 8-at fog mondani, ilyen egyszerû... és akkor mi van??? elárulom nektek, hogy a komplex összeadásokat egyéb matematikai mûveleteket a régi 486-os is gyorsabban kiszámolja, mint ti bármelyikõtök fejben vagy papíron... ennyit az agyatok komplexitásáról az hogy bonyolult az agy, nem jelenti azt, hogy 100%-ban hasznos is
Végülis 10 év alatt sokminden történhet. Sõt, tuti, hogy ki fog derülni, hogy pl. 100db, egymástól függetlenül mûködõ x86-os procinak nincs sok értelme, és valami egészen új kialakítás jelenik meg. Szal ez megint olyan szöveg, mint a híres 10GHz-es P4. Inkább csak üres markering.
jövõre magos AMD, M2 foglalatban... áááááááá á hhhhhhh :)
jövõre az AGP-s 6600Gt kártyám mellé berakok egy XXXX PCI-E-t és egy M2-es foglalatos 4 magos pocit??? Na akkor mégis csak Jézus az isten, és Mohamed az õ prófétája (református muzulmán vagyok) nekem emg brutális gépem lesz. Ass rock hehehe
Informatika és tudomány
Na akkor mégis csak Jézus az isten, és Mohamed az õ prófétája (református muzulmán vagyok) 
nekem emg brutális gépem lesz.