86
-
dez #46 Mármint a Windows fejlett memóriakezelésének velejárója. :D -
dez #45 Egyesek erre azt mondják, hogy ez a fejlett memóriakezelés következménye. :) -
#44
És azt is hozzátenném, hogy ezt a windózos programot, amiből kilépésnél jó ideig elrecseg a vinyó vindóz alatt, linuxon wine-vel futtatva, !ntfs! particióról, alig töltögetett induláskor de kilépéskor meg egyáltalán nem. -
#43
Hát ez bizony durván így van. Vindóz még a semminél is swappol. És azt sem értem hogy bizonyos uninstaller programok hogy működnek. Pl uninstallra nyomok, aztán 10 percig ilyen "okokból" töltöget hogy "validating install" "konfigurálja az uninstallert", stb, és ez nem túlzás tényleg 10 percig képes recsegtetni a vinyót. Ezután eljut addig, hogy a registryből kitörli a dolgokat, aztán végre elkezdi törölni a fájlokat. Jó lenne tudni hogy az első 10percben mit csinál.
És hát memóriaigényesebb programokból kilépés után, van olyan hogy 1 percig szinte semmit sem lehet csinálni, mert fullosan leterheli a vinyót, pedig elvileg a program már rég nem is fut. A vicc pedig az, hogy a program futása közben is 1 giga ramból 400 mega szabad. -
nedudu #42 Hálisten nem kell használnom wint itthon ezért a swappelés nem érint 
-
dez #41 Ja, meg ugye a Windows akkor is swappolgat, amikor amúgy van még bőven szabad ram (hacsak le nem tiltják teljesen), amire megint csak kihat a vinyós dolog, jól belassítva, megakasztva az egész rendszert. Reméljük, egyszer majd ezekkel a dolgokkal is foglalkoznak majd. Az NCQ valamennyit számít, de nem sokat. -
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. -
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 #38 A második mondat nyilvánvaló, de az elsőnél mire utalsz? SCSI+/RAID? -
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. -
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.
-
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ű. -
dez #34 Ez nagyon szép és jó - amíg csak az egyik program használja intenzívebben a vinyót... -
#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 :) -
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... -
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:) -
AranyKéz #30 Mármint maximum 100 hz-es sebességgel. Akinek lassabb gépe van az dögöljön meg.
-
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. -
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:) -
#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.
-
#26
Bővebb infó itt, hogy miért is fontos, és jelentős ez az Intel szabadalom. -
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. -
Su0my #24 és te ugyanezt teszed a másik oldal nevében;) sötét.. -
#23
??? -
#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. -
AranyKéz #21 Minden többszálas progi kihasználja, csak kérdés milyen mértékben. -
#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 :) -
#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.. -
#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... -
#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. -
M0RN1NGST4R #16 köszi. -
#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.
-
#14
Microsoft 4eva! :) -
neoG #13 De majd a K8L 
-
M0RN1NGST4R #12 már várom, hogy vki beirja, hogy "De majd a K8L"... -
#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 -
#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.
-
juzosch #9 Jópár szabadalmuk terjedt el, csak sokszor nem is tudod, hogy ők találták ki. -
#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. :) -
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.