50
-
J3Surno #50
ja
Tipikus trágya, patt helyzet, bár számomra is igen izgalmasak ezek így elméletben, pl. a varázslatos, vagy jövőbe mutató technikák stb (nem is azzal van a baj)
Csak nem tudom mikor jutnak el a szegény átlagfelhasználókig (lehet, hogy
ezek nem arra vannak, de az arány akkor is siralmas) amikor így is néha 2-8 éves lemaradás van csak a pc világában sok vkinél, nemhogy ezek a szinte már katonai cuccok mikor érnek oda...
Ráadásul kihasználva?
Addig beköszönt egy újabb dinó-kor, vagy jön vmi meteorit (majdnem kipusztul az ember) vagy ilyesmi :)
-
Sir Ny #49 Minek a 8 mag, a két magot sem használja ki semmi! -
Komolytalan #48 Minél távolabbi dolgokról beszélünk, annál helytállóbb. 2 mag tök jól el tudja csinálgatni egymás mellett az add-ot, meg a sub-ot, mul-t, meg hasonló dolgokat. Ott kezdődnek a gondok, hogy push/pop, meg mov. Főleg ha kiderül hogy azonos program szálait futtatják, és kezelni kéne közös memóriaterületet.
Nem véletlen pl javaban - aminek a virtuális masinája verem orientált - hogy thread-hez - vagyis amit külön magok futtathatnak - van saját verem, és amíg ki nem "kacsingat" az ember a "globális" változók felé, addig van esély arra, hogy a 2 mag nem túr bele egymás memóriaterületébe.
Egy kép/video feldolgozás meg azért másabb téma, mert ott bazi nagy memóriaterületekről beszélünk, és mondjuk 50 megában nehezebb egymásra "rálógnia" 2 mag cacheének, mint 800 byteban. Így a nagy számok törvénye alapján is "elkerülik" egymást a különböző magok cache-ei, amíg nincs "túl sok" mag. -
Deus Ex #47 No, ez az egész valóban jelentős csúsztatásnak tűnik. Az odáig rendben van, hogy az alkalmazásokat a valódi skálázódáshoz több magra kell optimalizálni - megjegyzem, ennek hatékonysága is feladatfüggő, nem minden folyamat többmagúsítása térül meg érdemi teljesítménynövekedésként - de a mai korszerű operációs rendszerek többfeladatúak, azaz sok, háttérben futó alkalmazást működtetnek, ha úgy tetszik, daemont vagy szervizt, ezzel párhuzamosan pedig számos interaktív vagy félinteraktív programot is. Ha az oprendszer ésszel csinálja a feladatütemezést, akkor ezeknél nettó előnyt jelent a többmagúság. Többmagos gépen külön optimalizálás nélkül is jöhet elő teljesítménynövekedés, tekintve, hogy a programnak több időszelet jut, mivel a rengeteg egyébként is futó szerviz szétoszlik a többi magon.
A processzormaghoz rendelés XP óta elérhető lehetőség, Feladatkezelő/Folyamatok jobbklatty a folyamaton, Affinitás. -
haveromjeno #46 Sziasztok!
Akkor egy nagyon alap tévedés elhárítása, amit eddig senki nem tett meg. Pedig számítottam rá, hogy valaki megjegyzi.
"Kihasználja a képszerkesztőm, a videószerkesztőm, a játékom a több magot" című mondatok.
Az, hogy a program több SZÁLON dolgozik. S párhuzamosan több feladatot hajt végre. (Lásd korábbi példák, hogy játékoknál egyik szálon-magon hangot, a másikon képet számol.) Az nem ugyanaz, mintha valóban kihasználna egy többmagos rendszert. Ahol is nem a feladatokat, hanem a MŰVELETEKET osztod szét magok között. Ilyen megoldások jelenleg leginkább csak a szuperszámítógépek speciális architektúráján, illetve az azokra írt speciális programokon vannak.
Megpróbálkozom egy példával, lehet nem lesz a legjobb:
Ha egymás mellett pörög 20x20 homokóra, akkor az 400 szálon, 400 folyamat. Ez az a "kihasználja a több magomat évek óta" című mondat. A homokórák egymástól függetlenül pörögnek, egymásra nincsenek hatással. A folyamat jól párhuzamosítható. S persze, ha van egy 8 magos HT-es inteled, akkor ez máris csak 400/8 = 50 egymás után következő művelet, magonként. Természetesen hamarabb végez, mint 1 magon 400 művelet, egymás után.
Ha egymással összekapcsolva, töltögetik egymásba a homokórák a homokot. Akkor az 400 egymással kommunikáló mag. (A jelenlegi többmagos rendszereken ez úgy néz ki, hogy van egy központi vezérlés - általában a memória egy bizonyos része - amin keresztül öntögetik egymásba a homokot. Erre mondták azt bizonyos hozzászólok, hogy 1000-szer (Jelen példában 400x gyorsabb) memória kéne, hogy ne egymásra várjanak. Persze a valóságban az overhead miatt, még így sem lenne tökéletes, de ez más téma.
A valódi többmagos működés, hogy közvetlen egymással beszélgetnek a magok, és nincs egy központi tár, ami lassítaná az egészet. Mindenki a saját memória darabkájával dolgozik. S annak tartalmát, csak követlen szomszédai befolyásolják.
Utóbbi esetben ténylegesen 400x300Mhz -> kb 120 000 MHz (120GHz) dolgozna. NINCS EGYENLŐSÉG JEL! Nem is lehet. Mert a feladat maga párhuzamos, s nem lehetne ilyen módon, egy darab 120 GHz-es processzoron lefuttatni.
A professzor által említett 300MHz es példában, a videó/kép szerkesztő, ténylegesen csak 300MHz-en dolgozna.
Míg egy tényleges többmagos videó/képszerkesztő, pedig messze kenterbe verne, bármilyen tuningolt 4-5 GHz-es csodát.
Köszönöm a figyelmet. Elnézést a hosszú bejegyzésért. -
#45
Nézd meg az előző hozzászólásomat. -
#44
Tmpgenc Xpresst használok tömörítésre ez gond nélkül használja mind a négy magot 86-96% kihasználtsággal. Ha nem csinálsz semmit mellette akkor ezt igy végig is nyomja, ha igen akkor valamelyik magot lentebb húzza. -
MrImy #43 És ha az egyik mag a logika/vezérlés, a másik mag pedig a renderelés, akkor helytálló a leírásom? -
Komolytalan #42 Már WindowsNT is kihasználta a több mag adta lehetőségeket, szóval ennek köze nincs a 32/64/akárhány bites memória címzéshez. -
sanyicks #41 szerintem ezt rajtad kívül senki sem tudja, mert kb olyan mintha azt mondanám:
én szuahéli vagyok ezért a fű zöld -
Rotyoka #40 Ok feladom. Aki tudja miért írtam az tudja, aki nem az nem. -
sanyicks #39 mind a 4 magot -
sanyicks #38 konkrétan köze nincs egymáshoz a magszámnak és annak hogy hány bites az os-vagy a program... -
sanyicks #37 aha tehát akkor kéne berakni minden szálra még pár végtelen ciklust, hogy ha már másra nem kell akkor mind a 1 magot 100%-ra terhelje mert olcsóbb mint a gázfűtés? :D -
Rotyoka #36 Arról nem is beszélve, hogy aki 32 bites rendszert használ annak minek akár egy 2 magos proci is? Konkrétan semmi értelme sincs. -
Rotyoka #35 Emberek itt sokan el vannak tévedve... Az hogy ilyen szaros 5-20% van használja a 4 magos prociból egy progi a 2-3-4 magot az nem azt jelenti hogy ki is használja... Akkor használná ki ha 60% körül lenne ez az érték minden magon. -
#34
Deszar az mac már évekkel ezelőt óta kitugya használni a sok magot, mert annak 128 bites processzorja van merrt minösségi!! -
#33
Akkor lényegében a 4 magos proci ugyanazzal a sebességgel tömörít, mint a 2 magos ugyanazon az órajelen? Vagy rossz a logikám? -
Komolytalan #32 Ennél a példánál a következő gond van. Egy aknakeresőnél van 2 logikai tömb: van-e akna, illetve fel van-e fedve. Mondjuk 20x20 mindkettő, azaz 2x400 byte a memóriában, szépen egymás után. Az egyik tömb fix (hol vannak az aknák), a másik viszont a felfedés során folyamatosan módosul. Éppen ezért a magok dedikált cache-ébe ez a memória terület nem kerülhet be, vagy ha bekerül akkor folyamatosan borítani kell azt (módosul az érték, egy másik mag meg szintén módosítana 2 bytetal arrébb lévő értéket). Marad a közös cache, ami mondjuk legyen ugyanolyan gyors, mint a proci, mittomén 2Ghz. Itt jön az, hogy 2 memória művelet között hány ütemciklus van. Mert ha mondjuk 8, akkor 8 proci utána 9. már semmit se gyorsít, mert a memória sebesség limitált. És a cikkben 48 meg 1000 procikról esett szó. Nagyon ritka az a program, ahol ennyi "memória mentes művelet" lenne jellemző egymás után. Sokkal jellemzőbb az, hogy a műveletek majdnem fele memória művelet (ugye push/pop is az).
Ezzel szemben egy "okos" memória szervezéssel mondjuk a van-e akna tömb bekerülhetne egy "fixált" memória területre, amely feloldásig kb úgy viselkedik, mint a ROM. Amit meg bátran cachelhet minden mag külön-külön, hiszen sosem kell majd borítani, mert lehetetlen módosítani. Csak ehhez az kellene, hogy a program meg tudja jelölni a memória területeket úgy, hogy a memória (cache) vezérlő ezt értelmezni tudja. Ez pl fejlesztés lenne, +40 mag egy 8 magos mellé meg fingköszörülés. Valami ilyesmiről beszél a prof. -
duke #31 Tul sok programmal nem talakoztam ami tobb procit hasznalna. A winar, meg a divx tomoritot szoktam futatni, de azok is csak 2 processzort hasznalnak ki. Pedig az ilyen tipusu programoknal kezenfekvonek tunik, hogy akarhany proceszoron fusson, de biztos nem olyan egyszeru a dolgot megoldani. -
MrImy #30 Arra is gondolj, hogyha előbb elvégez egy számítási feladatot a CPU akkor kevesebb ideig lesz szüksége nagy energiafelvételre.
Ez pedig GW-os megtakarítást is jelenthetne globálisan. -
MrImy #29 Igazad van itt fórumon sok a suckember!
Megpróbálom megértetni az átlagfelhasználóval a jelenséget:
Van az aknakereső program, amikor mezőt fedsz fel az új többmagos processzorokon lassabb esemény, mint a régi egymagosokon, mert felfedés folyamata ugyanazon a processzormagon fut.
De ha a felfedést az aknakereső program már egy másik processzormagra bízná, akkor gyorsabb lenne, mert mialatt a másik mag felfedést végzi, az idő alatt fogadhatja az újabb felfedési kéréseket is.
Azért meg, hogy nem vagy elég gyors, hogy a fenti jelenséget érzékeld, ne engem hibáztass. -
Komolytalan #28 De azt se felejtsd el, hogy egy program futtatásához nem csak processzor kell. Akkor minek az a sok izé, ami rá van aggatva? A program futtatásához memória kell, amiből van a processzor számára dedikált? Igen, úgy hívják hogy cache. Nade az pont akkora, mint a program memória igénye? Hát nem. Nem lehet, hogy a cache nem tudja, hogy a program pontosan mennyi memóriát fog használni, és az hol helyezkedik el a központi memóriában? Hát de, erről a cache-nek fogalma sincs. Nem lehet hogy minél több mag, annál több "fölösleges" cache borítás/töltés lesz? Hát de.
Szóval itt vérzik el a 48 meg 1000 mag, hogy a számítógép, mint rendszer egy részét - ráadásul a leggyorsabbat - sokszorozzuk, attól az egész rendszer teljesítménye egy idő után nem fog szignifikánsan változni. A többi alkotóelemet is párhuzamosítani kellene, első körben a memóriát kellene átgondolni. -
Thrawn #27 2006 óta használom a Rawshooter nevű programot fotófeldolgozásra. Tehát nem mai darab, a többmagos procik épphogy kezdtek akkoriban terjedni. A progi mégis remekül kihasználja a magokat. 2006 óta futott Athlon64 3200, Athlon64 5200 procin, futtattam összehasonlító teszteket, remekül kihasználja a két magot és ezt nem a feledatkezelő diagrammjából, hanem a futási idő csökkenéséből állapítottam meg, figyelembe véve az eltérő órajelet is. Most egy I7860-on használom, ezen szintén hozza a fejlettebb architektúrától és a 4 magtól várható gyorsulást. A HT mondjuk nem sokat segít.
Azoknál az alkalmazásoknál pedig, amelyek bármilyen oknál fogva nem használják a több magot, kiválóan működik Az Intel turbo boost, úgy tudom, az AMD Bulldozer is hasonlóképpen gyorsít, ha nincs kihasználva minden mag. -
Komolytalan #26 Igazat írsz, de én is. Amiről te beszélsz az az, hogy a konkrét 2,4,6 magos megéri-e. De itt 48, meg 1000 magokról beszélnek, amikor már 6-8 mag is eléggé véleményes mint teljesítmény növelő. -
Mcsiv #25 ez valóban így van, de most nem:\
Sajnos valóban szar a helyzet a párhuzamosítás terén -
feri79 #24 A lényeg, hogy a laboratóriumi környezetben történő megállapítások, nem feltétlenül tükrözik a való világban tapasztaltakat. Persze nem azt mondom, hogy nincs mit fejleszteni. -
#23
Kérdés melyik programot használja. Szerintem az újabbak mind támogatják a több magot. -
Mcsiv #22 jó esetben igen, de azért ennél sokkal árnyaltabb a helyzet.
Felesleges magokra széttrancsírozni a rendszert. A futó folyamatoknál lévő szálakat ("threadeket") próbálja meg az oprendszer ütemezője szétosztani a magok között. -
gemihu #21 Gyakorlatilag akkor úgy is mondhatjuk,hogy a többmagos processzorok inkább több program futtatásánál jelentenek igazi előnyt. Pl lehetne 1 mag az oprendszer folyamatainak 1 mag skype stb háttéralkalmazásoknak és 1 mag az előtérben futónak.Lehet inkább az kéne,hogy a programok tudják,hogy melyik magba kell kerülniük. Vagy ez így is van? Nem tudom..
-
Mcsiv #20 nem mindent lehet párhuzamosítani. A játékok is azért használják szarul mert pl a render nem bontható le két nagy részre, amik párhuzamosan futhatnának. Ilyen esetben szokták a különböző részfolyamatokat (render, ai, fizika, hang, stb.) külön szálakra lehúzni, majd a szálakat a különböző processzorokhoz rendelni.
Ez már azért jelentősen összetettebb feladat, mert bizonyos helyeken lockolni kell az erőforrásokat, a scene-t, így addig az adott részfeladat vár, míg a másik be nem fejezi. Ha sikerül is, általában ez szokta azt eredményezni, hogy 1 proci 100%-on, a többi meg 75,50,25 százalékon pörög.
Ha ne adj isten sikerül is, de valahol megcsúszik, akkor jön az hogy megy a sírás, mert szaggat ez az istenverte játék a hiperszuper gépemen. -
gemihu #19 Egyik ismerősöm építész. Ő megjárta ezt a többmagos bizniszt,mert a tervező progi csak egy magot használ és kisebb az órajel. -
Ahoy #18 Lehet van neki 20 publikációja, de a valós PC használatban nagyon kevés programot tudna felhozni, ahol a több mag hátrányt jelent. Jelenleg mi sem tudunk nagyon. Ahol kraft kell, ott lehet is párhuzamosítani. Ahol nem kell, ott viszont egy magon is simán elfut perfekt teljesítményen.
Emellett még mindig ittvan a speciális feladatra legyártott proci, vagy a GPU programozása... Ami igencsak új és érdekes terület. -
#16
Tapasztalatom szerint windóz vonalon a Win7 volt az első, ami ezt normálisan kezdte megvalósítani. Bár a magam részéről rásegítettem még egy kis prioritás managementtel.
Játékok terén meg érdemes a PS3 példáját megnézni. Kb 5 évbe telt, amíg a fejlesztők igazán normálisan kezdték kihasználni a több magos architektúra előnyeit. Olyan platformoknál, ahol a fejlesztő nincs rákényszerítve, ott soxor rátolnak mindent a GPU-ra, ha az kifogyott a szuszból, akkor vegyél másik videokarit. De mondjuk az se garancia, hogy adott progi sokkal jobban fog futni, a CPU meg ott erölködik kihasználatlanul a gépben, pláne a több magos.
A PS3 tapasztalata volt, hogy meglepően kicsi programrészeket lehet, és ott sajna kell is párhuzamosan futtatni, a rendszer optimális kihasználásához. A cell egyes kis magjainak csak 256 KB saját kis memóriájuk van, abba kell mindent bepakolni, amivel adott pillanatban dolgozni akarnak, ha nem akarják az egymásra várakozással megállítani a rendszert.
Másrészt az volt még egy érdekes tapasztalat egyes fejlesztők részéről, hogy minekután szétbontották a kódot, nem kell ürtechnológia szintű csodakód az egyes szálak összehangolásához. -
feri79 #15 Amit még nem szabad elfelejteni, hogy nem feltétlenül kell egyetlen programra lebontani a dolgot, hiszen jellemzően nem egy alkalmazás, fut. Mire az OS készen áll, legalább 3-4 program biztosan fut (vírusirtó, valamilyen chat progi, ...), plusz az OS szolgáltatások. A legegyszerűbb párhuzamosítás, ha az egyes programokat külön dedikált mag futtatja, ezt az OS legtöbbször meg is teszi és ehhez egyetlen bitet nem kell átírni. -
#14
Szerintem nem jó a példád. Itt azt kell nézni, hogy mondjuk 2x1,5 az gyorsabb e mint 1x2Ghz. A gyártásnál számolódik. Lehet hogy legyártani 4x1,5Ghz-et olcsóbb mint 1x3Ghz-et, és már meg is érte. Egyébként amiket én használok szoftvereket és számítás igényesek azok szerintem mind használják a több magot. Összességében biztos több olyan szoftver van a világon ami nem használja ki, de nem is biztos, hogy mindnek használnia kell. -
Komolytalan #13 Nem az a kérdés hogy mit mutat a task manager, hanem hogy mondjuk 6x2Ghz hányszoros sebességre képes mint 1x2Ghz. Mert ha mondjuk csak 4-5x gyorsabb, akkor nemigen éri meg 48 meg 1000 magokban gondolkozni.
A processzor párhuzamosítása a memórián vérzik el, merthogy az egy van, és egy is kell hogy legyen. Persze van cache, de az vagy maghoz dedikált, és ha egyik magon változik, akkor másik magon borítani kell, vagy közös, akkor meg szimplán csak egy gyorsabb memória. 1000 maghoz 1000x gyorsabb memória dukálna, ha meg ez nem megy - márpedig nem megy - akkor nincs értelme processzor mag számot növelni, hanem memória architektúrát kell fejleszteni. Talán figyelembe lehetne venni a hardware fejlesztésekor azt, hogy az 50-es évek óta mit fejlődtek a programozási nyelvek. Pl azóta elég durván megváltozott az adat:kód arány, meg lehetne még sorolni. -
Komolytalan #12 Azért párhuzamosításban nem volt ám akkora ász a Pentium. Anno volt 1 Pair nevű program, amivel lehetett optimalizálni Pentium párhuzamos futtatásra. Alapban egy C fordító kb 10-20%-ig használta a V csövet (U ugye 100% alapból). Ha mondjuk ASMben írtad meg ugyanazt a feladatot tán összejött a 30% is élből (ugye C vermelt ha kell ha nem). Ha elszórakozott az ember azon, hogy mit lehet felcserélni, akkor esetleg kézzel feltornászhatta 70%-ra a kihasználtságot. Mondjuk egy 30 soros assembly programon, fél óra alatt. Nagyon megérte:-) -
feri79 #11 Szép meg jó, hogy mindenki hangoztatja, hogy a programozóknak párhuzamosítani kellene a programokat, de ilyenkor milyen programokra gondolnak, ezekre nem nagyon hallok példát.
Vannak esetek amikor nem lehet vagy nem éri meg a párhuzamosítás, pl azt hogy 1+1 mennyi nem igazán lehet párhuzamosítani (kisarkított példa). -
#10
Photoshop, After Effects, Premiere, Sonar, Cubase, Pro Tools, 3D Max, Maya mind kihasználják. Vagyis mindenfajta álló és mozgóképgyártásra, zenekészítésre használt programok igen. Ezekhez kell a nagy számítási teljesítmény. No, és persze valószínűleg a játékokhoz is, de itt bele kell tolni a vasat is (nem mintha a fent említett műveletek végzéséhez nem kéne).
Ha a játék nem használja ki a sok magot, az a játék nem korszerű. Ennyi az egész. Mert többmagos procik nem tavaly óta vannak. A játékfejlesztőknek már régen át kellett volna kollektíve állni a fejlesztésre.