Intel, IBM - áttörés a tranzisztoroknál

Nem az otthoni fos pécébõl kell kiindulni a vinyó használatát tekintve. Egyébként meg van sok olyan program ami futhat többszálon anélkül, hogy a vinyóhoz nyúlna.

A HW SMT-s procik nagyon is külön kezelik a szálakat.
És nem minden mai proci sem ilyen CISC/RISC rendszerû.

Ez nagyon szép és jó - amíg csak az egyik program használja intenzívebben a vinyót...

Szerver fronton már nagyon régóta vannak 64bites, és több processzoros kialakítások.
Nem a nagy megmentõt várjuk a több magtól, csupán élvezzük a technológia nyújtott elõnyöket 😊

miért alakul minden topik "mi használja ki a többmagot", "a gagyi programozók miért nem térnek át a többszálú programok írására" és hasonló flame-vé?

Azért mert egy nõnek 9 hónapig tart kihordani egy gyereket, nem jelenti, hogy 9 nõnek 1 hónap alatt is sikerül.
Van amit lehet egymástól idõben elkülönülõ részfolyamatok halmazaként kezelni, és ekkor, hogy a magok egyenlõen legyenek kihasználva valóban a programozók feladata.
Van viszont amit nem lehet szétváligatni és ezért sosem nem is fog elõnyt jelenteni a több processzor használata. (elméletben, ha csak az az egy program fut és tényleg semmilyen része nem választható le a "fõszálról")

Ugyanolyan parasztvakítás az egész mint a 64bit. Mekkora sláger volt pár éve, hogy 64bit. az majd kétszer olyan gyors lesz.... na persze. gyakorlatilag annyi elõnye van, hogy 4gigánál nagyobb memóriánál sem okoz gondot a memória címzése. persze meg lehet oldani a címzést 32biten is, de az azonkívûl, hogy gányolás, még lassú is.
tehát aki per pill 4gigánál több ramot használ, annak érdemes 64bites procit vennie (amennyiben egy alkalmazás 4gigánál több memóriát fogyaszt, annak is 64bitre írodottnak kell lennie)
és aki többszálon futtatható progikat használ, vagy egyszerre sok programot futtat az meg vegyen több magosat (való igaz, már magában a windóz is "sok programot" futtat)

ne várjatok a programozóktól csodákat, van amit egyszerûen nem lehet megoldani.
elhitették veletek hogy ez a csapásirány a jövõ, pedig csak egy próbálkozás, hogy amíg nem sikerül új architektúrával kijönni és/vagy órajelet emelni, addig is lehessen eladni procikat.
máskülönben az alfa már ha jól emlékszem '98ban, de lehet '99ben, 64bites volt, 8 maggal. csak errõl ugye nem szokás beszélni...

amit leírtam az csak az elsõ lépése egy optimalizációs folyamatnak, mint amikor pl egy adatbáziskezelõnél az adatbázisban turkálást új thread-be pakolod, hogy közben maga a fõprogram ne fagyjon rá a képernyõre és amig tart az adatbázis frissítése, addig ne egy kifehéredett címsort láss. lentebb kérdezték mit lehet csinálni, én megpróbáltam összeszedni dióhéjban. 😊 feltételezem akik komolyan nyomják az ipart, nálamnál jobban körbejárják a dolgot😊

Mármint maximum 100 hz-es sebességgel. Akinek lassabb gépe van az dögöljön meg.

Megjegyezném hogy a játékban amit épp csinálok a haverral az elsõ dolgunk az volt hogy két thread-re szedtük a játékot: egy thread a fizikának, egy thread a videónak. Bár nem azért csináltuk ezt hogy többprocesszoros rendszereken is fusson, hanem hogy a fizika állandó 100 Hz-es sebességgel, a videó meg tetszõleges sebességgel fusson. És valószínûleg nem mi vagyunk az egyetlenek akik így gondolkoznak.

CPU szinten nincs olyan hogy szál. ott task-ok, feladatok vannak. a mai processzorok magja az ALU és az FPU általában RISC architektúrára épül, azaz sok egyszerû utasítást bõdületes sebességgel elvégezni. ez aztán hogy kompatibilis maradjon ezért alkalmaznak egy CISC interpretert (magasabb szintû utasításokat értelmezõ egység) amivel különbözõ optimalizációkhoz jutnak - SSE, MMX, 3Dnow. ezek olyan utasításokat tartalmaznak amit egy RISC mag sosem értene meg, mert 50 utasításból áll az egész tudástára. a köré épített CISC struktúrát használva a magasabb szintû utasítások (több száz összetett parancs) gyorsan fordíthatók kicsi gyorsan végrehajthatókká. ezen a szinten pedig megszûnnek létezni a programok, itt csak olyan van pl, hogy memóriacímet add össze memóriacímmel. tehát a CPU szintjén már régóta cincálják apró darabokra a programokat/szálakat.
a gond az egyszálas algoritmusokban keresendõ. példának itt egy egyszerû játék elvi váza:

repeat - ismételd míg ESC parancsot nem kapsz.
if (keyPressed) - ha megszakítás volt a bemeneten
read (key) - karaktert beolvasó függvény a bemenetrõl
else
animate() - animáló függvény
render() - renderelõ függyvény
until(ESC) - ha jön az ESC kilép, de addig a ciklus folytatódik

azaz a ciklus fut a végtelenségig, ha jön egy billentyûlenyomás az inputról, akkor azt tudomásul veszi, különben a játékmotor újraszámolja a karakterek elmozdulását, azt hogy mit fogsz kb látni, majd lerendereli a képet és kiküldi a kimenetre. a gond ott kezdõdik, hogy az animálás elé még szúrd be a
fizikaiSzámolás()
mesterségesInteligenciaSzámolás() -t. sajnos ezek olyan dolgok, amik egymástól függenek, tehát elég nehéz megoldani, hogy a játék gyors legyen és még a fizika is jól mûködjön, meg minden klappoljon és még gyors is legyen. ha úgy írnák meg, hogy nem sorban számolja ki a program ezeket hanem mondjuk elindítunk 4 szálat a programon belül:
1 szál:

repeat
if (keyPressed)
read (key)
else
környezetiVáltozókBeállítása()
animate()
until(ESC)

a 2. 3. 4. szál külön ciklus lenne, de egybe írom / jelekkel. szerintem egyértelmû azért így is.

repeat
fizikai / mestInteligencia / render -ParaméterekBeállítása
fizikaSzámolás() / M.I.számolás() / renderelés()
fizikai / M.I.paraméterek visszaírásaKörnyezetiVáltozókba()
until(amig az elsõ szál él)

ekkor a 4 szál függetlenül fut egymástól, nagy lesz a játék FPS aránya, mert nem függ a renderelés a pl. fizika számításától, hanem ha renderel, akkor lerendereli azt amit épp a környezeti változókban talál. elõfordulhat, hogy az elõzõ képkocka van még ott.. ez ilyen struktúra már több magot is kihasznál, hátránya hogy környezeti változókat kell írkálni, meg átadnia a szálaknak.

más.
tömörítéskor is hasonló nehézségek lépnek fel. le kell ellenõrizni az adott adathalmazt gyakorta ismétlõdõ elemek után. pl ha letömörítesz 130 képet és mind jpg, akkor az elsõ 500byte mindig nagyon hasonló. ezeket egybe lehet tömöríteni, lehet gyártani hozzá egy egyszerû mintát. de! a winchester pl elég lassú, tehát arra várni kell, plusz lehet hogy egy szálon végigtoltam egy mintakeresést, addig mit csináljon a másik szál? csak úgy a semmibe nem kezdhet bele, erõsen függ a másik szál eredményétõl.
viszont mondjuk egy 3Dstudio-s, Maya-s animáció renderelésekor el kell mondjuk készíteni 200 képkockát. a legtöbb képkockát alapjaiból újra kell számolni. maga az animáció sematikus (mondjuk drótvázas) elõnézete pillanatok alatt elkészül, tehát ez az alap -> a képkockák tartalma minden pillanatban elõre ismert. akkkor mi tart sokáig? pl egy egy képkockán van 4-5 fényforrás és sugárkövetéssel, gradiens árnyékolással szeretném megjeleníteni az animációmat. na az erõforrásigényes, ilyenkor ha van 4 magja a gépnek akkor nekifeszítem õket egyszerre 4 képkockának, ha van egy 30 gépes renderparkom akkor rászabadítok arra a 30 gépre egyszerre 30 képkockát. tehát masszívan párhuzamosítható a feladatoknál nagyon jól jön a sok mag. és ugye akkor minél többen dolgoznak rajta, annyival gyorsabban leszek készen. na jól elszálltam, respect annak aki végigolvasta😊

Az olyan kerdesek, hogy "mikor fogjak mar a programokat tobb processzorra optimalizalni" pont arra utalnak, hogy meg ti is "egyszaluan" gondolkoztok.
A dual core processzorokat ma legegyszerubben ugy lehet kihasznalni, ha tobb programot futtattok egyszerre, vagyis pl amig neteztek vagy videot neztek, a hatterbe mennek mas alkalmazasok, pl letoltes, tomorites, stb... Az ilyen esetekben drasztikusan gyorsabb egy dual gep, mint egy egyprocesszoros.
Nekem egy Core 2 Duo notebookom van es minden szaguld rajta. Gyakorlatilag ez az elso gepem, amire szinte egyaltalan nem kell varni, mert mindig azonnal reagal.... Persze ez lehet, hogy inkabb az OS X-nek koszonheto. <#vigyor3>

Bõvebb infó itt, hogy miért is fontos, és jelentõs ez az Intel szabadalom.

Amig 10% a tobbmagos procik aranya a desktopokon, addig egyik fejleszto ceg sem fog ebbe nagy penzeket invesztalni. A fejlesztesi es a tesztelesi koltsegek akar meg is sokszorozodhatnak, es <+10% eladasert ez nem eri meg. Aki nem hiszi, irjon nehany tobbszalu algoritmust, aztan meglatja milyen problemak jonnek elo.

és te ugyanezt teszed a másik oldal nevében😉 sötét..

???

Többszálas programozás technikáját már régóta használják. De amíg ez nem hozott jelentõs pluszt, addig nem optimalizálták erre a feladatokat.
Vedd például azt, hogy egy lineáris folyamatot, alapvetõen mi értelme van több részegységre felosztani, ha azokat úgyis végre kell hajtani sorrendtõl függetlenül egymás után.

Minden többszálas progi kihasználja, csak kérdés milyen mértékben.

A folyamatok száma != szálakkal. Nekem pl most 30 folyamat fut, de ez 361 szálat jelent, szal nagyon jóval 30 fölött 😊

Mégis, minden procin futtatnál külön msn-t ?😊
Amelyik program többszálasra van megírva, az ki tudja használni a több magból adódó elõnyöket. De nézd csak meg a feladatkezelõben, hogy alapból az Xp is hány szálat futtat, anélkül hogy bármit is elindítottál volna / oszlopok kiválasztása, szálak száma /. Jóval 30 fölötti a számuk.
Persze üresjárásban nem terheli túlzottan a procit..

"Jó ez a sokmagos proci, már írhatnának rá valami progit is, ami kihasználja..."
Mint nem IT-s embernek, magyarázza már el nekem valaki, hogy CPU vagy kernel szintjén miért nem lehet általánosan megoldani egy processz párhuzamosan több CPU-ra való felosztását? Durva, hogy szoftver szintjén kell ugyanezt megoldani...ha fejlesztõ lennék és írnék egy szoftvert, ne nekem kelljen már azzal szenvednem, hogy x db magra optimalizáljak egy programot, de közbe azt is figyelembe vegyem, hogy 1 magon se haljon be...

Hát az elmélet ebben az esetben nem igazán ér semmit. Egyébként a legtöbb nagy elméleti felfedezésüket nem igazán láttam megvalósítva, szal inkább gyártják a szabadalmakat, de ennyi.

köszi.

az jó, hogy felsoroljátok, hogy hány szoftver használ több magot,
de : az egy évben megjelenõ többtizezer darab mellett - ez az egy kettõ
lássuk be - nem túl sok.

Microsoft 4eva! 😊

De majd a K8L<#hehe>

már várom, hogy vki beirja, hogy "De majd a K8L"...

Neked üldözési mániád van, te mindenhol a gonosz xboxosokat látod, fõleg bennem, akinek soha nem volt egy m$ cucca sem, szoftverben sem(legalábbis eredeti nem), xbox se lesz egy hamar. Egyébként meg eszembe se jutott ps3 errõl a cikkrõl, már 2 éve is ezt írtam, amikor ase tudtam mi az a ps3.
Egyre több gonosz xboxos lesz a képzeletedben, sztem menj el orvoshoz, mert ha így folyatatod nem lesz valami jó (neked) <#ejnye1>

Na meg ugye djdano, és biroandras is tudna mesélni mennyire "szeretem az m$" 😄DDD

Gondolom ha azt mondanám hogy a tranzisztor az szar, akkor azt mondanád hogy azért mondom mert a ps3-ban is van... kicsit nagyon lol

Szvsz a világ leginnovatívabb informatikai cége az IBM.
Általában nagyobb presztizs ott dolgozni, mint a Microsoftnál.
Ez majdnem a cég megalakulásától így van, de hogy meddig.. ugye az kérdéses.

Jópár szabadalmuk terjedt el, csak sokszor nem is tudod, hogy õk találták ki.

Sanyix azért szidja az IBM-et, mert azok csinálták a PS3 processzorát harmadrészben és õk gyártják. És sanyix mint általában az x-boxos bill gates jugend tagok és igz-xektások, mindent szid, aminek köze van a PS3-hoz vagy a Sony-hoz. Überalles X360 stb.

Rossz szokás, majd kinövik. 😊

Az IBM adja be a legtöbb szabadalmat évente (valami 1500/év rémlik), így ha nem is mutatnak semmit, akkor is megéri nekik, ugyanis a szabadalmuk felhasználásáért jelentõs pénz összeget kapnak... Mondhatnám úgy is, hogy õk tulajdonképpen elsõsorban elméleti munkát végeznek, és csak másodsorban gyakorlatit.

Jaj már megint ígérget az ibm? elég szánalmas. Minden évben akár többször is óriási áttöréseket ígérgetnek, meg hogy de gyorsan elterjednek, de ezekbõl az áttörésekbõl szinte soha semmit nemlátunk, szépen feledésbe merül az egész.

egyébként akinek még nincs két vagy többmagos gépe, azt én csak bátorítani tudom a vásárlásra, mert ugyan nem használom ki a végletekig a gépet, nem is tuningoltam, de egyszerûen élvezem, hogy megszûnt a homokóra effektus. csak akkor lassú a gép, ha valami nagy adatmennyiséget kell a winyóról behúzni - ugye mivel a winyó lassú, különben mindig van szabad számítási kapacitás. tudok úgy töredezettségmentesíteni, hogy közben röcögés nélkül nézek filmet, vagy böngészhetek 20 lapon miközben a gép fél kapacitását megeszi a dscaler tv progi.

már írnak olyan programokat, csak elég keveset használunk belõlük. az egyszerûbb programok, mint pl a 7-zip is profitál a két magból, csak elég nehéz úgy szervezni azadatot, hogy meg is érje. pl ha sok kis file-t tömörítek, akkor a kétmagos procim 80%on dolgozik, mert a lemezkezelés lassú. a komolyabb, professzionális progik már jó ideje többszálúak (3D studia, photoshop) - ezek ahány plusz magot raksz alájuk majdnem annyival gyorsabban képesek dolgozni.
irodai munkánál nem hiszem, hogy annyira számítana a többszálas feladatvégzés, de ott is lehet úgy optimalizálni a progin, hogy pl az ablak ne fagyjon ki, míg maga a szövegszerkesztõ épp beemel egy 10 megás doksit.
szvsz a játékoknál kéne végre a motor fejlesztõknek felnõnie a feladathoz. új programozási stílusokat követelne, hogy a fizikát, Mi-t, animációt/renderelést tényleg szétválogassák külön szálakra és ne az legyen, hogy egymásra várnak a szálak. szerintem csak játék téren van komoly lemaradás.

a 3d progik kihasználják maya max stb

A hírben csak a lényeg nem volt benne, hogy hogyan érték el az áttörést. Bár a 20% ot nem érzem mérföldkõnek a technológiában.

Jó ez a sokmagos proci, már írhatnának rá valami progit is, ami kihasználja...