86
-
HUmanEmber41st #1 Jó ez a sokmagos proci, már írhatnának rá valami progit is, ami kihasználja... -
#2
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. -
BCs design #3 a 3d progik kihasználják maya max stb -
waterman #4 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. -
waterman #5 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. -
#6
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. -
Akuma #7 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. -
#8
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. :) -
juzosch #9 Jópár szabadalmuk terjedt el, csak sokszor nem is tudod, hogy ők találták ki. -
#10
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.
-
#11
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)
Na meg ugye djdano, és biroandras is tudna mesélni mennyire "szeretem az m$" :DDDD
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 -
M0RN1NGST4R #12 már várom, hogy vki beirja, hogy "De majd a K8L"... -
neoG #13 De majd a K8L 
-
#14
Microsoft 4eva! :) -
#15
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.
-
M0RN1NGST4R #16 köszi. -
#17
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. -
#18
"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... -
#19
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.. -
#20
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 :) -
AranyKéz #21 Minden többszálas progi kihasználja, csak kérdés milyen mértékben. -
#22
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. -
#23
??? -
Su0my #24 és te ugyanezt teszed a másik oldal nevében;) sötét.. -
Anotino #25 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. -
#26
Bővebb infó itt, hogy miért is fontos, és jelentős ez az Intel szabadalom. -
#27
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.
-
waterman #28 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:) -
AranyKéz #29 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. -
AranyKéz #30 Mármint maximum 100 hz-es sebességgel. Akinek lassabb gépe van az dögöljön meg.
-
waterman #31 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:) -
mcganyol #32 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... -
#33
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 :) -
dez #34 Ez nagyon szép és jó - amíg csak az egyik program használja intenzívebben a vinyót... -
dez #35 A HW SMT-s procik nagyon is külön kezelik a szálakat.
És nem minden mai proci sem ilyen CISC/RISC rendszerű. -
nedudu #36 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.
-
waterman #37 igen, pontosabban is fogalmazhattam volna. a mai AMD/Intel procik ilyen vegyesfelvágottak, de egy SPARC vagy CELL az csak simán RISC architektúrát használ. -
dez #38 A második mondat nyilvánvaló, de az elsőnél mire utalsz? SCSI+/RAID? -
nedudu #39 Például egy valódi hardveres RAID rendszer messze jobban teljesít mint a mostani szoftos megoldások. Ha ez még SCSI is akkor az már maga a királyság.
-
dez #40 Na ja, csak ugye mint te is írtad, átlagos otthoni pc-kben nem pont ez van. Tehát egyszerre csak egy a vinyót jobban használó prgramot lehet futtatni. Elég hozzá pl. két másololást, vagy 1 másolást és egy kitömörítést, stb. elindítani egyszerre, nem fele olyan gyorsan lesznek kész, hanem negyed, vagy még lassabban. Függetlenül attól, 1 mag van vagy 2.