Egyelõre csak hátrányt jelentenek a többmagos processzorok

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 :)

Minek a 8 mag, a két magot sem használja ki semmi!

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.

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.

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.

Nézd meg az elõzõ hozzászólásomat.

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.

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

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.

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

Ok feladom. Aki tudja miért írtam az tudja, aki nem az nem.

mind a 4 magot

konkrétan köze nincs egymáshoz a magszámnak és annak hogy hány bites az os-vagy a program...

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

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.

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.

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!!

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?

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.

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.

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.

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.

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.

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.

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

ez valóban így van, de most nem:\
Sajnos valóban szar a helyzet a párhuzamosítás terén

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.

Kérdés melyik programot használja. Szerintem az újabbak mind támogatják a több magot.

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.

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

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.

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.

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.

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.

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.

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.

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.

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:-)

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

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.

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.

Igaz, a játékok tényleg nehezen hasznosítják a többmagos procikat.

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.

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

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.

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.

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

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

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