132
-
BiroAndras #132 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. -
dez #131 "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? :) -
BiroAndras #130 "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. -
dez #129 "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.) -
dez #128 "Hol javítottál ki? Nem látom."
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:
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. -
BiroAndras #127 "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). -
dez #126 "Nekem teljesen világos a dolog."
Nem gondolod, hogy a "teljesen világos" egy kicsit túlzás, tekintve, hogy jópárszor ki kellett javítsalak? Sőt...
"De az alap kérdés nem ez volt"
Ejj, nem gondolod, hogy amikor egy vita van a fogalmak nem pontos ismerete miatt, először azokat kell tisztázni?
"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."
Child-processt akkor is létre kell hoznia. Mivel kell, hogy valahol tárolódhassanak a taszkváltásokkor a regiszterek, stb.
"Szerintem a child process és a thread nem ugyanaz."
Ehh, olvass már légyszives! #115-118, #121. -
BiroAndras #125 "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. -
dez #124 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. -
dez #123 "De nem erről volt szó szerintem"
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. -
BiroAndras #122 "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)."
De nem erről volt szó szerintem, hanem arról, hogy a process-hez tartozó thread(ek) futhatnak-e másik CPU-n. -
dez #121 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). -
dez #120 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. -
BiroAndras #119 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.""
Nem tudom mi mit cáfol itt.
"NEM LEHET! Process nelkul nincs szal! Ennyi."
És a process nem lehet másik CPU-n? -
dez #118 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." -
dez #117 "De igen. En mimast irtam?"
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. -
dez #116 Felülre: mármint a végrehajtás 1-1 szála, amik párhuzamosan futhatnak. (És persze "tHread of"..) -
dez #115 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.
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... -
#114
"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ú...?
De igen. En mimast irtam?
Az, hogy milyen feladatkorokre (szerepkorokre) osztod szet oket az mar egy meroben mas kerdes. -
#113
"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.
-
BiroAndras #112 "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. -
BiroAndras #111 "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. -
dez #110 Persze.
ps. ja, majd ugye nem akarod még1x leírni, amit én alább leírtam. ;) -
BiroAndras #109 "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. -
dez #108 >CMP -
dez #107 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. -
dez #106 É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." -
dez #105 upsz, mégiscsak szimultán, jól emlékeztem. -
dez #104 Továbbá, ha már pontosítás:
"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. -
dez #103 bocs, szimultán -> symmetric -
dez #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. -
#101
É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! -
#100
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)."
Ezt en hol vitattam? -
#99
"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 kombinaltan multithreadre es 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.
-
Tiberius B #98 Javaslom mindenkinek agy-témában a National Geographic egyik számát, ami pont aaz agyról szól. -
Tiberius B #97 Ja, max. -
dez #96 "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". -
Tiberius B #95 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. -
BiroAndras #94 "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? -
BiroAndras #93 "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).