Amugy egy érdekesség még mindig megmaradt - Miért ment jobban a game win95-ös kompatibilitási módban, mint dosbox-al, bár lehet hogy egyszerüen még van mit fejleszteni a progin, és ennyi az egész
Ezt irják a readme-ben is mondjuk :
"NOTE: While we are hoping that one day, DOSBox will run all programs ever made for the PC, we are not there yet. At present, DOSBox running on a high-end machine will roughly be the equivalent of a 486 PC...."
Uhh, most jöttem rá, hogy kissé kevertem a régi W98-as Dosboxot (még az is lehet, hogy ott nem is úgy hívták :) ) azzal a nyílt forrású újabb emulátorral, amirõl te beszélsz, és ugyanaz(?) a neve. :D Na jó, akkor hagyjuk. Ez tényleg emulál mindent.
"Egy kicsit más vindóz gui-t megjeleniteni, mint akár egy régi game grafikáját" Éppen ezért írtam, hogy csak fullscreenben megy a dolog. Pl. sok régebbi demo is csak fullscreenben megy, de akkor jól. (Vagy ez még a Win98 alatt volt? :D)
"valami miatt nem lehet mégse driver-esen megoldani, ha lehetne, nem kellene emulálni :)" Miért ne tudná egy driver bekapcsolni a régi vga módot? Itt valami titok lappang... :D (Ezért érdekel ez a "kérdés". :) )
"compatibilis hardweróra emulációval" Hmm, ez nem vga-emulációval kapcsolatos dolognak tûnik...
Egy kicsit más vindóz gui-t megjeleniteni, mint akár egy régi game grafikáját, valami miatt nem lehet mégse driver-esen megoldani, ha lehetne, nem kellene emulálni :)
PS: fullscreenben próbáltam, csak 1x néztem meg ablakosan, és adagoltam neki a cpu-idõt is, viszont csak hang emulálás nélkül ment viszonylag folyamatosan, bár ez még nem olyan régi játék, win95-öt már támogat, igy sima windózos emulálással még mindig jobban ment, bár egy kicsit speedy volt, de igy is csak hang nélkül valamiért, compatibilis hardweróra emulációval meg megint nagyon belassult, nade mind1 már nagyon eloffolódtunk az eredeti témától...
Tudhatnád, hogy tudják a régebbi üzemmódokat: pl. bootoláskor, vagy amikor Winben még nincs feltelepítve semmilyen videokártyadriver, akkor standard vga módban van. A dosboxnál asszem két különbõzõ mód van: egészképernyõs módban mûködhet a videokártya valamilyen régi módban, de ez az ablakos módban nem megy, mert az egész képernyõ egyszerre csak egy módban lehet. Eszembe sem jutott, hogy ablakos módban futtatsz játékokat. :) Próbáld ki, mennyit eszik egészképernyõs módban, és az a "proci-sebesség"-állítást is. (Ha ennyire érdekel. :) )
"pl. c64 emulátorokra gondolsz?" -- Nem, az egész más. Ott emulálva van maga a proci is, és olyan sebességgel emulálják, amilyennel akarják. Én a sima DOS-os, x86-os programokról beszélek.
"VGA emulation is the most demanding part of DOSBox in terms of actual CPU usage" - ha valóban tudnák a mostani driverek&/videokártyák, akkor miért kell emulálni?
"Egyébként már régen is így ment, még a DOS korszakban, hogy egy proci-terhelõ programmal lett lefoglalva a proci" - pl. c64 emulátorokra gondolsz?
Már úgy értem, (úgy látszik) most is így megy a dosboxon belül. Ezt kipróbálhatod úgy, hogy feljebb-lejjebb veszed a sebességet, és közben figyeled, változik-e a prociterhelés. A VGA módhoz meg nem kell külön emuláció, máig tudják a videokártyák. (Hacsak nem CGA módról van szó.)
Az, hogy eszem ágában sincs. :D Azért ilyen favágó módszerrel megy, mert ez volt a legegyszerûbb, és nyilván nem látták túl sok értelmét több energiát fektetni bele. Egyébként már régen is így ment, még a DOS korszakban, hogy egy proci-terhelõ programmal lett lefoglalva a proci (megszakításból persze, mert ugye a DOS nem multitaskos).
Hát, ha annyival egyszerübben is megoldható lenne, biztos nem ilyen "favágó" módszerrel menne, igazából, ha a video driver is tudna emulálni, sokkal régebbi tipusokat, és grafikát, biztos nem kéne ennyit szenvedni ilyen old gamékkal.
Ez tulajdonképpen a Windows task-schedulerjének köszönhetõ, aminél nincs olyan, hogy akkor is csak az idõ x százalékában kapja meg a vezérlést valami, ha más nem is fogja a procit. Bár nem tudom, máshol van-e ilyen. Viszont megoldhatták volna kerülõ úton is.
Huh, valószínû éppen a lassító rutin fogta meg ennyire a procit. Ahelyett, hogy az idõ x százalékában kapott volna prociidõt az emulátor. :D Hát ez az, itt sokminden ilyen favágó módszerrel van megoldva.
"Kicsit nevetséges, hogy van alatta pl. egy 3GHz-es proci, erre olyan a Windows, mintha valami pár MHz-es proci lenne ott."
Pár hete letöltöttem a death rally (96-os apogee játék (elfogott a nosztalgia na :D, meg a kiváncsiság, dosbox-ot is jobban megismertem)) freeware változatát, és dosbox-al próbáltam müködésre birni, van benne egy olyan opció, hogy lehet gombnyomásra csökkenteni, vagy növelni a cpu-idõzitést, amit a progi használ hogy emulálja a régi hardwaret a régi játékoknak. Elég vicces volt hogy alig tudtam kihozni, azt hogy folyamatosan mennyen a game miközben közel 100%ra hajtotta a procit. Tette mindezt egy 10éves játék (jó annyiból azért riszpekt, hogy egy ilyen alig 12megás játékkal egyedül elboldugul egy modern proci, ugy hogy mindent az számol, grafika, zene, hangok, fizika (már ha volt ilyen :D), és azért ez már igencsak a 486-os idõkben jelent meg, talán már p2 is volt valahol egy messzi-messzi kontinensen :) )
"A prioritások megfelelõ beállításával lehet elérni, hogy a GUI mindíg reagáljon, ehhez viszont nem elég a win scheduler, kell a procit leterhelõ szoftverek segítsége is."
És mivel olyan segítség nem nagyon van, nem is nagyon lehet ezt elérni. Egyébként a GUI-mûveletek itt általában lemezmûveletekkel párosulnak, és utóbbiak prioritását nem lehet állítani az XP-ben, valójában sehogy sem lehet elérni. (Tudtommal a Vistában ez már jobb lesz, legalábbis elméletileg.) Mellesleg még csak 100%-os terheltség sem kell hozzá, hogy eléggé akadozó legyen. Kicsit nevetséges, hogy van alatta pl. egy 3GHz-es proci, erre olyan a Windows, mintha valami pár MHz-es proci lenne ott.
"Egyébként van a win-ben egy olyan fícsör, hogy ha csutkára van terhelve a proci, akkor is garantál valamennyi idõt minden szálnak (kivéve az idle-t)."
"Ha ket 100%-os program fut, akkor meg elkelne egy par mag, vagy egy intelligens (valosideju) kernel scheduler (a macos-ben van ilyen, az egymagoson sem fagy be), ami visszavenne a 100%-os terhelest 80%-ra, hogy valaszkepes maradjon a rendszer."
Nem biztos, hogy örülnél, ha a fontos számításaid fixen 20%-kal lassabban futnának. A prioritások megfelelõ beállításával lehet elérni, hogy a GUI mindíg reagáljon, ehhez viszont nem elég a win scheduler, kell a procit leterhelõ szoftverek segítsége is. Egyébként van a win-ben egy olyan fícsör, hogy ha csutkára van terhelve a proci, akkor is garantál valamennyi idõt minden szálnak (kivéve az idle-t).
"Amugy viszont ha afk vagyok egy idõ után vadul elkezd tölteni a vinyó, ilyenkor mi a fenét csinál?, ezt már rég óta szerettem volna tudni :D"
Automatikus defragmentacio es startup gyorsitas a diszk tartalmanak atrendezesevel. Kiloheto, ha az ember atnevezi azt a rendszerkomponenst ami ezt vegzi.
A toltogetest pedig a conservative swap usage opcio bekapcsolasaval es a disk cache limitalasaval lehet elerni. A fix meretu swap file mar win3.1-nel is kotelezo volt annak aki nem akart varni. (linux-ban es macos-ben is van dinamikus, de valamiert az emberek nem szoktak hasznalni) A windows fo swap file-jat a legjobban hasznalt meghajtora vagy a disk kozepen levo particiora erdemes telepiteni, fix merettel. Igy kell a fejnek legkevesebbet mozognia es igy lesz a leggyorsabb.
Ha jatek kozben nyitva van a bongeszo, akkor a bongeszo ram cache-enek a meretet is erdemes limitalni, igy nem nyomjak ki folyton egymast a rambol a jatekkal. Egyebkent hasznalok mind dual core-os, mind hagyomanyos egymagos gepeket, a dual core-os akkor jo ha az egyik magot 100%-ra terheljuk. Igy a masik meg mindig kezeli a gui-t, tehat nincs homokora. Ha ket 100%-os program fut, akkor meg elkelne egy par mag, vagy egy intelligens (valosideju) kernel scheduler (a macos-ben van ilyen, az egymagoson sem fagy be), ami visszavenne a 100%-os terhelest 80%-ra, hogy valaszkepes maradjon a rendszer. Igy csak egy picit tovabb tartana minden, de nem kellene homokorat nezni.
6 éve dual procis gépeim vannak. Abit BP6 két celeronnal, most pedig egy EP D3VA, 2db 933-as P3-mal. Az a baj, hogy a virtuális memóriát ki kell kapcsolni, ha az ember érezni akar valamit az elõnyökbõl, mert a vinyó lassítja az egészet, amikor bill gécc nagy találmánya állandóan ír/olvas róla.
Kicsit unalmas hogy mindig olyanok ugatnak be hülyeségeket, akik nem is láttak még 2 magost... De hát csak tesség, azért van a fórum nem?
Egyébként az órajel nem minden. A C2D processzor odaver minden P4-es procinak akármilyen EE jelölése is van. Olvasgass teszteket. Optimalizálni nem csak a programozók, hanem a procigyártók is tudnak
Uhh, talán egy 3GHz-es C2D egy magja is nem sokkal gyorsabb, mint akár egy 4GHz-en mûködõ P4?
Kissé kevered a dolgokat. A P4-nek nem a szivárgással volt baja, az az Intel 90nm->65nm átállásánál jött elõ. Azzal, hogy most jelentõsen csökkentették a szivárgást, a csíkszélesség további alapos csökkentése vált könnyebbé (de ehhez még más is kell). És a csíkszélesség csökkentése önmagában csak kisebb órajelnövelést enged.
Az órajel növelése viszont a fogyasztást emeli drasztikusan, és ezzel együtt a hõtermelést. A hír szerint ezt most 20-30%-kal sikerül csökkenteni, ami megint csak viszonylag kisebb órajelnövelést enged.
Ezért még nem érdemes visszatérni a NetBursthoz. Inkább a C2D-bõl fognak kihozni valamivel magasabb órajelûeket, illetve ezt fogják majd még tovább fejleszteni.
Hmmm, nekem erre az a frappáns megoldásom, hogy lefixáltam a lapozófájl méretét 4G-ra :), azóta csak akkor dolgozik a vinyó, ha adatot mozgatok rajta (többé-kevébé)
Amugy viszont ha afk vagyok egy idõ után vadul elkezd tölteni a vinyó, ilyenkor mi a fenét csinál?, ezt már rég óta szerettem volna tudni :D
Hát nemtudom, erõs fantáziád lehet, én ebben a cikkben sehol sem látok ilyen nyilatkozatot, az intel uj 45nm-es prociairól van szó, miszerint 20%nyi teljesitménynövelést, és 30%nyi fogyasztáscsökkenést tapasztalhatunk (hol láttad te, hogy mindezt magasabb mûködési frekvencián???)
"Mondogatom már én itt egy ideje, hogy jön a Pentium 5 5GHz körüli órajellel, de ti nem hittétek el."
- persze mondogathatod, ameddig be nem jön, csak nehogy elõbb megöregedj :)
Azt természetesen a "semmitõl swappolásra" írtam. 4GB mellett is csinálja, még ha a negyedét használod, akkor is. (Bár ennyi ramnál, ha sosem használjuk ki teljesen, már érdemes letiltani az egész lapozósdit.) Rendszer-gyorsítótárnak használja a szabad területet, és hogy minnél több szabad terület legyen erre, kilapoz, amit csak tud: pár perce nem használt programokat, sõt a rendszerhez tartozó dolgokból is sokat. Úgy tûnik, GUI-kezeléssel kacsolatos dolgokat is, amiket aztán állandóan töltögethet vissza, mindent jól lelassítva. Okos. :DDD
Pedig jobb lenne ha megtanulnának normálisan programozni. Nem kidobjuk az alpha játékot amit majd megint 1cd-nyi patchel lehet utána normálisan játszani.
Ebben a cikkben nem a többmagos cuccokon van a hangsúly. Hanem a korábbi problémák megszûnésérõl, amik akadályozták, hogy a NetBurst architektúrájú procik kedvezõen magas órajelen járjanak.
Mondogatom már én itt egy ideje, hogy jön a Pentium 5 5GHz körüli órajellel, de ti nem hittétek el. Hát de nekem lett igazam.
Ha még mindig nem esett volna le: ez a cikk arról szól, hogy leküzdötték a 4GHz+ órajeleket akadályozó problémákat.
Jönnek az új magas órajelû Intel procik, amiket minden progi ki fog használni, és nem kell a programozóknak annyit szenvedniük a párhuzamos programozással. (Tudom, hogy többmagosak lesznek ezek is, de párhuzamos optimalizálás nélkül is gyorsak lesznek rajtuk a programok)
Végre megkapják a programozók, amit szeretnének: magasabb órajelû procikat
Erre az uninstall dologra én is kiváncsi lennék, volt egy 1 vagy 2 cd-s gamém, aminél több percig tartott az uninstall, a 8gigás óriás gamékat meg levakarta pár másodperc alatt, fura
É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.
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.
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.
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.
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.
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.
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:)
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.
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.
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.
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.
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
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)
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
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.
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.
Informatika és tudomány
