50
-
DontKillMe #1 "a többmagos processzorok hátrányt jelentenek bizonyos folyamatokban. "A szoftverfejlesztés egyre inkább problémás területté válik. Ennek oka, hogy bár ma már szinte mindegyik CPU többmagos, a szoftverek jelentős része még mindig nem képes kihasználni ezt" - szögezte le a szakember. "
"SZAKEMBER"
-Akkor nézegesse csak a homokórát. Ekkora ökörséget. -
#2
Érthető a probléma, fenn is áll, de egy valamit nem értek. Miért most kell tanulmányozni a többmagos processzorokra való adatfeldolgozást, programozást? Nem látom a hátterét a dolognak, mivel nem vagyok részese, de így úgy tűnik, hogy az Intel nem lépett időben annak érdekében, hogy minden fejlesztő és programozó tanulmányozhassa, mielőtt kiadnák az első ilyet. Ennek már sok éve. -
Szefmester #3 "a többmagos processzorok hátrányt jelentenek bizonyos folyamatokban. "A szoftverfejlesztés egyre inkább problémás területté válik. Ennek oka, hogy bár ma már szinte mindegyik CPU többmagos, a szoftverek jelentős része még mindig nem képes kihasználni ezt" - szögezte le a szakember. "
Inkább a játékok jelentős része... a képfeldolgozás, videoszerkesztés, modellezés, fizikai szimulációk egy ideje már (majdnem)mind kihasználják. -
feri79 #4 Hát azért nem ennyire fekete/fehér a dolog. Valóban sok program nem használja ki a lehetőségeket, de azok amelyeknél számít a nagy számítási teljesítmény azokat igenis fejlesztik ebbe az irányba.
A probléma szerintem az, hogy egy mai számítógép teljesítményét az egyszerű felhasználók közel sem tudják kihasználni, így nincs szükség évente új vas vételére, ez viszont rossz a gyártóknak. Az meg, hogy homokórázik a gép, nagy valószínűséggel nem a CPU hibája, nagyobb az esély arra, hogy a háttértár a lassú és nem bírja kiszolgálni, tessék SSD venni. -
Ahoy #5 Szerintem ez megint egy sokmillába kerülő idióta tanulmány lehet, aminek semmi értelme. Manapság rendszerszinten SSD-vel lehet gyorsítani a PC-t, mert az a szűk keresztmetszet. Egyszerűen a proci már nem gyorsít annyit, akárhány magos is de multitaskingban jól jön Rendszerszinten amúgy is jól lehet párhuzamosítani. Tehát itt megbukott az elmélet.
Játékok egyre jobban húzódnak a többmagos procik irányába, de itt inkább a VGA szokott limites lenni. Itt is megbukott az elmélet.
A filmrenderelés, szerverek, tudományos kutatás stb... meg már régóta könnyen párhuzamosítható, tehát itt abszolút megbukott az elmélet...
Komolyan más területen mire kell nagyobb teljesítmény? MSN-re? Word-re? Egyszerűen nem értem...
Ahol kell a kakaó, ott párhuzamosítható is a dolog. Ahol meg nem kell, ott 1 magon és 4 magon is ugyan olyan gyors. -
gopher #6 Azért bírom, hogy a kommentelők mennyire le bírnak fikázni egy néhány publikációval rendelkező professzort, akinek a fő területe a párhuzamosított rendszerek kutatása... -
kvp #7 Mar a xerox alto is 8 szalu vegrehajtasra volt kepes 1973-ban es ez volt az elso pc-nek hasznalt gep. A tobbmagu feladatvegrehajtas problemajara rengeteg elmelet es megvalositas szuletett elotte es azota is.
Parhuzamositas szerint a feladatokat ketfele kategoriaba lehet szetosztani, a linaris logikat igenyloek es a parhuzamosithatoak. Az egyetlen komolyabb feladat jelenleg a linearis logika parhuzamositasa a benne levo parhuzamosithato reszek felismeresevel. Ez a tenchologia adta az intel piaci folenyet a pentium sorozat ota, mivel buta programozok, buta forditoprogramok is kepesek olyan kodot generalni ami utanna gyorsan fog futni. Ennek a hatarat kezdik elerni, mivel elobb-utobb mar a programnyelvekbe is bele kell nyulni, hogy tovabb gyorsithato legyen jopar program.
A jelenlegi parhuzamos megoldasok joreszt atvagtak a csomot es a programozonak kell kitalalnia, hogy hogyan es mikent legyen parhuzamositva a feladat, erre viszont nagyon keves hozzaerto szakember kepes, tehat itt az emberi eroforrasok jelentik a szuk keresztmetszetet.
A kutatok jelen esetben egyebkent nem szamitaselmeleti hanem termikus limitbe utkoztek. Ha egy 2 Ghz-es processzor X mennyisegu hot termel, akkor ugyanekkora helyen, ugyanekkora hutesi kapacitassal 10 mag csak kb. 10-ed akkora sebesseggel mehet, hogy ne susse meg magat. Az intel erre nem tudott hasznalhato megoldast nyujtani. Ugyanakkor a sok mag meg lassit is, mert a magok kozti kommunikaciora ido megy el.
A tenyleges megoldas az optikai processzorok bevezetese lenne, amik nagyobb orajelen, kevesebb energiaigennyel kepesek akar egymagos mukodesben is verni a mostani sokmagos integralt rendszereket. Ez a hosszutavu megoldas. A rovidtavu pedig a cpu es a ram integralasa es gyorsabb memoria cellak hasznalata lenne. (tehat a teljes szamitogep hagyomanyos memoria helyett csak cache memoriat tartalmazna) Ezen rovidtavu cel elereseben csak az aramkorok ara jelenti az akadalyt, ezert keresnek mas alternativakat. -
Lowosan #8 Igaz, a játékok tényleg nehezen hasznosítják a többmagos procikat.
-
avman #9 az a baj, h ebből a kijelentésből "a többmagos processzorok hátrányt jelentenek bizonyos folyamatokban."
ez lett:
"Egyelőre csak hátrányt jelentenek a többmagos processzorok"
azt már megszoktuk, h filmes vonalon mi van, de ez így nagyon gáz.
szerencsétlen egyszeri olvasó meg azt hülyézi, akinek a szájába adták az ostobaságot- pedig nem is. -
#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. -
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). -
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:-) -
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. -
#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. -
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. -
#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. -
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. -
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. -
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 #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 #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. -
#23
Kérdés melyik programot használja. Szerintem az újabbak mind támogatják a több magot. -
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. -
Mcsiv #25 ez valóban így van, de most nem:\
Sajnos valóban szar a helyzet a párhuzamosítás terén -
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ő. -
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 #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. -
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. -
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. -
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. -
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. -
#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? -
#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!! -
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. -
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. -
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 -
sanyicks #38 konkrétan köze nincs egymáshoz a magszámnak és annak hogy hány bites az os-vagy a program... -
sanyicks #39 mind a 4 magot -
Rotyoka #40 Ok feladom. Aki tudja miért írtam az tudja, aki nem az nem. -
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