Az AMD és az Intel is ősszel gyorsít
Jelentkezz be a hozzászóláshoz.
#41
Szerintem is valami ilyesmik lehetnek az okok:
1. A P4 celeron rettenetesen lassú. Ilyenen láttam akadozni divx lejátszást is (nem HD), ami azért már elég durva.
2. A P2 korszakban a cache-optimalizáció nem sokat számított, ma viszont az egyik legfontosabb dolog. Óriási sebesség különbséget jelenthet csak az, hogy hogyan és milyen sorrendben olvasod az adatokat a memóriából.
3. Valami gond van a mérésse.
4. Valami, amire nem gondoltunk.
Amit tehetsz:
1. Nézd meg a progit egy Core2-n, vagy X2-n. Mindkettõ szanaszét alázza a P2-ket minden szempontból. Én nemrég pár régi P1-P2 korszakban írt progimat néztem meg csak egy vacak A64 3000+-on, és azok az emlékeimhez képest embertelen gyorsuláson mentek át. Pl. az egyik a régen 10-20 másodpercig tartó számolást valós idõben produkálta.
2. Nézd át a kódot, és igazítsd a mai igényekhez. Fõként a memória elérést érdemes átnézni. A legfontosabb, hogy legalább 32-bites egységekben olvass, és 32-bites regiszterekkel számolj, a tömb elemeket növekvõ sorrendben olvasd, és akkora adatblokkokkal dolgozz egyszerre, amik bõven elférnek a cache-ben.
3. A mérésre inkább használj RDTSC-t, az sokkal pontosabb és megbízhatóbb, mint a rendszeróra (de kétmagos prociknál vigyázni kell vele).
1. A P4 celeron rettenetesen lassú. Ilyenen láttam akadozni divx lejátszást is (nem HD), ami azért már elég durva.
2. A P2 korszakban a cache-optimalizáció nem sokat számított, ma viszont az egyik legfontosabb dolog. Óriási sebesség különbséget jelenthet csak az, hogy hogyan és milyen sorrendben olvasod az adatokat a memóriából.
3. Valami gond van a mérésse.
4. Valami, amire nem gondoltunk.
Amit tehetsz:
1. Nézd meg a progit egy Core2-n, vagy X2-n. Mindkettõ szanaszét alázza a P2-ket minden szempontból. Én nemrég pár régi P1-P2 korszakban írt progimat néztem meg csak egy vacak A64 3000+-on, és azok az emlékeimhez képest embertelen gyorsuláson mentek át. Pl. az egyik a régen 10-20 másodpercig tartó számolást valós idõben produkálta.
2. Nézd át a kódot, és igazítsd a mai igényekhez. Fõként a memória elérést érdemes átnézni. A legfontosabb, hogy legalább 32-bites egységekben olvass, és 32-bites regiszterekkel számolj, a tömb elemeket növekvõ sorrendben olvasd, és akkora adatblokkokkal dolgozz egyszerre, amik bõven elférnek a cache-ben.
3. A mérésre inkább használj RDTSC-t, az sokkal pontosabb és megbízhatóbb, mint a rendszeróra (de kétmagos prociknál vigyázni kell vele).
#40
(Részben) visszaadtad a hitemet az informatika fejlõdésében 😊
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#39
A P4 viszonylag lassú FSB-s memóriaelérésének nagy késleltetése miatt erõsen rászorul a nagy L2 cache-ekre. A Celeronban meg pont ez a nagyon kevés (meg talán még a L1 is kevesebb, ha jól emlékszem, meg talán más belsõbb dolog is le van butítva), így "ki van herélve" szegény.
#38
Nincs 😊 Eredetileg oprendszert akartam írni assemblyben, aztán amikor könnyûnek találtattam a feladathoz, akkor legyártottam belõle a tesztprogramot, hogy ne vesszen kárba az addigi munkám.
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#37
nem chache, hanem cache... <#email>
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#36
Tényleg, a mikrokód (bocsi, én nem figyeltem). Jó lenne valami mikrokód upgrade, amivel Alpha procit lehetne varázsolni a Pentiumból <#vigyor2>
Ugrásbecslés, chache meghülyülés, ezekben lehet valami. Kézzel írt assembly az egész, és hát én természetesen nem igazítottam chache-line határra a subrutinokat, meg az adatokat...
A Celeronom egyébként következetesen P4 generációnak mutatkozik be, csak sokkal kisebb chache-sel. Van valami alverzió, amibõl tudni lehet hogy csak Celeron, de állítólag HyperThreadingot is tud, csak le van tiltva benne (CPUID utasításkor a visszaadott HT flag aktív).
Ugrásbecslés, chache meghülyülés, ezekben lehet valami. Kézzel írt assembly az egész, és hát én természetesen nem igazítottam chache-line határra a subrutinokat, meg az adatokat...
A Celeronom egyébként következetesen P4 generációnak mutatkozik be, csak sokkal kisebb chache-sel. Van valami alverzió, amibõl tudni lehet hogy csak Celeron, de állítólag HyperThreadingot is tud, csak le van tiltva benne (CPUID utasításkor a visszaadott HT flag aktív).
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#35
Figyeltem, nem OS alatti fullos emulációra gondoltam, hanem arra, hogy esetleg maga a proci pl. már natívan nem létezõ (mármint a belsõ RISC kódra fordítós/bontós változatban sem) utasításokat emulálja (némi BIOS segítséggel mondjuk). De ilyesmi inkább csak floating-point kóddal fogdulhatna elõ. (Pl. a 68040 így emulálgatta a 68881/2 kódot, ha nem saját FPU-s kódot futtattak, meg azokat az utasításokat, amiket eleve nem támogatott natívan.)
Az is lehet, hogy a kódod meghülyíti az ugrásbecslést, vagy a cache-kezelést, vagy más efféle.
Egyébként a P4 Celeront nem kellene P4-nek mondani, mert igencsak nagy a különbség a kettõ között.
Az is lehet, hogy a kódod meghülyíti az ugrásbecslést, vagy a cache-kezelést, vagy más efféle.
Egyébként a P4 Celeront nem kellene P4-nek mondani, mert igencsak nagy a különbség a kettõ között.
#34
most van oprendszer vagy nincs?
#33
"beljesében" (C) bvalek2, a Nyelvujító <#banplz>
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#32
Jól van, te sem figyelsz 😊
nincs emulálva semmi! nincs operációs rendszer! a csupasz vason fut a program! floppyról bootol a programom. átkapcsol védett módba (a Windows XP is ebben a módban fut). Normál, 32 bites, általános integer és memóriacímzõ utasításokat használok, amik már 386-os óta megvannak. ezeket használják a programok az esetek 80%-ában (a P4-en is). Az igazi hardverórát olvasom, azt, amit IO regisztermûveletekkel lehet elérni.
ugyanaz a módosítatlan kód picit lassabb P4-en, mint P2-õn. azt tudom, hogy mindkettõ beljesében egy RISC dolgozik, de ennyire nehéz lenne P4-en értelmezni ugyanazt a kódot? én is nagyot néztem, sok tesztet csináltam után, hogy biztos lehessek benne.
Direkt kikapcsolom a megszakításokat a futásidõre, nehogy az APIC okozzon bajokat. Még a lapozást is kikapcsoltam, nehogy az MMU miatt legyen eltérés. Sõt, legmagasabb processzorprivilégiummal fut a program, tehát még jogosultságokat sem ellenõriz (hogy pl. van-e jogom IO mûvelethez, vagy sem). Annyira tudok még gondolni, hogy talán valami extra cache utasítással be kellett volna olvastatnom talán a memóriaterületet a cache-be? Ezt lehet hogy egy oprendszer elvégzi automatikusan... de ez csak tipp, megpróbáltam már utánanézni, hogy van-e ilyen, de nem találtam rá utalást az inteles dokumentációban.
nincs emulálva semmi! nincs operációs rendszer! a csupasz vason fut a program! floppyról bootol a programom. átkapcsol védett módba (a Windows XP is ebben a módban fut). Normál, 32 bites, általános integer és memóriacímzõ utasításokat használok, amik már 386-os óta megvannak. ezeket használják a programok az esetek 80%-ában (a P4-en is). Az igazi hardverórát olvasom, azt, amit IO regisztermûveletekkel lehet elérni.
ugyanaz a módosítatlan kód picit lassabb P4-en, mint P2-õn. azt tudom, hogy mindkettõ beljesében egy RISC dolgozik, de ennyire nehéz lenne P4-en értelmezni ugyanazt a kódot? én is nagyot néztem, sok tesztet csináltam után, hogy biztos lehessek benne.
Direkt kikapcsolom a megszakításokat a futásidõre, nehogy az APIC okozzon bajokat. Még a lapozást is kikapcsoltam, nehogy az MMU miatt legyen eltérés. Sõt, legmagasabb processzorprivilégiummal fut a program, tehát még jogosultságokat sem ellenõriz (hogy pl. van-e jogom IO mûvelethez, vagy sem). Annyira tudok még gondolni, hogy talán valami extra cache utasítással be kellett volna olvastatnom talán a memóriaterületet a cache-be? Ezt lehet hogy egy oprendszer elvégzi automatikusan... de ez csak tipp, megpróbáltam már utánanézni, hogy van-e ilyen, de nem találtam rá utalást az inteles dokumentációban.
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#31
A P4 Celeronok híresen lassúak sima int és fp kódban (SSE-vel javul a helyzet valamelyest), de hogy ennyire semmit sem gyorsultak volna, ez elég hihetetlen, de legalábbis megdöbbentõ lenne. Nem ismerem ennyire közelrõl a P4 arch. mélyebb dolgait, de nem lehet, hogy pl. a régi fp utasítások (ha jól értem, azokat használod) emulációban futnak? (Volt már ilyen a történelemben.) Valami rémlik, hogy a P4-nek fejlettebb fp egységei lettek, vagy valami ilyesmi. Vagy egy "idétlenebb" ötlet: nem lehet esetleg, hogy ott DOS-ban csak bootkor olvassa be a valódi hw órát, utána már csak megszakításból frissíti az "idõt", és a programod ezt akadályozza, az újabb gépen (jobban)? Volt ilyen "anomália" is már a történelemben, bár elég régen. 😊
#30
Effendi:
Elismerem, hogy vannak új utasítások, amik gyorsak, én általános utasításokat használtam. Azok lassúak maradtak.
dez, maxspeed2107:
Ennyire rossz lenne a P4-es Celeronom IPC-je? hát, csodálkozom, hogy két generációnyi váltás nem hozott semmilyen gyorsulást az általános utasításkészlet végrehajtásában. Ti biztos többet tudtok nálam az Intel processzorainak fejlõdésérõl, és csak tapasztaltam egy tényt, semmi több.
rád gondoltam, amikor arra kértelek, hogy aki nem érti a szavakat a hozzászólásomban, az inkább ne szóljon hozzá, de te mégis megtetted. Talán elõbb tudni kéne, hogy mirõl van szó, mielõtt belekotyogsz:
- A 633Mhz-s processzorom P2-es generációként azonosítja magát
- nem elavult utasításokat használtam, hanem általánosakat, minek részletezzem? már leírtam egyszer, ha akkor nem tudtad hogy mirõl van szó, akkor most sem fogod tudni
Elismerem, hogy vannak új utasítások, amik gyorsak, én általános utasításokat használtam. Azok lassúak maradtak.
dez, maxspeed2107:
Ennyire rossz lenne a P4-es Celeronom IPC-je? hát, csodálkozom, hogy két generációnyi váltás nem hozott semmilyen gyorsulást az általános utasításkészlet végrehajtásában. Ti biztos többet tudtok nálam az Intel processzorainak fejlõdésérõl, és csak tapasztaltam egy tényt, semmi több.
rád gondoltam, amikor arra kértelek, hogy aki nem érti a szavakat a hozzászólásomban, az inkább ne szóljon hozzá, de te mégis megtetted. Talán elõbb tudni kéne, hogy mirõl van szó, mielõtt belekotyogsz:
- A 633Mhz-s processzorom P2-es generációként azonosítja magát
- nem elavult utasításokat használtam, hanem általánosakat, minek részletezzem? már leírtam egyszer, ha akkor nem tudtad hogy mirõl van szó, akkor most sem fogod tudni
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#29
Ja, nem, az még P3 volt, szal akkor s.423.
#28
s.462-be nehezen, mert az AMD-s foglalat volt. 😊
Te a s.370-rõl beszélsz.
Te a s.370-rõl beszélsz.
#27
Remélem tényleg lesz 40% gyorsulás, mert akkor tudnék játszani a Supreme Commanderrel.
Aki úgy gondolja, hogy egy PIII 600-as gyorsabb, mint egy Core2 Duo, az próbálja már ki a Supreme Commandert egy PIII 600-as gépen. ;-)))
Olyan programot én is tudok írni, amelyik lassabban végez a PIII 600-on, mint a Core2 Duo-n, de ez csak annyit jelent, hogy vagy direkt írtam ilyennek, vagy pancser programozó vagyok. ;-)))
Aki úgy gondolja, hogy egy PIII 600-as gyorsabb, mint egy Core2 Duo, az próbálja már ki a Supreme Commandert egy PIII 600-as gépen. ;-)))
Olyan programot én is tudok írni, amelyik lassabban végez a PIII 600-on, mint a Core2 Duo-n, de ez csak annyit jelent, hogy vagy direkt írtam ilyennek, vagy pancser programozó vagyok. ;-)))
#26
Van azért példa arra, hogy az újabb lassabb. Annak idején, mikor az elsõ P4 1.4 v. 1.6 GHz-en kijött s462 foglalattal, még SD-RAM-mal lassabb volt, mint az elõd P3 Tualatin modell 1200 Mhz-en. Az Intelnél is voltak azért melléfogások. De sztem tanultak már belõle azóta.
A P2 idején a Celeron meg a rendes P2 ugyaolyan gyors volt. A P2 dupla L2 cache mérete csak néhány alkalmazásnál volt elõny. A cerkát meg jobban lehetett húzni, igy a több cache-sel mégsem volt gyorsabb. Aztán az Intelnél ebbõl is tanultak.
A P3 óta a cerka egyértelmûen a "budget" kategória.
Amúgy a leggyorsabb P2 cerka 533MHz-es volt, korának legyorsabb, olcsó x86-os asztali procija és durván húzható állat. Simá verte az elsõ P3-kat is.
A P2 idején a Celeron meg a rendes P2 ugyaolyan gyors volt. A P2 dupla L2 cache mérete csak néhány alkalmazásnál volt elõny. A cerkát meg jobban lehetett húzni, igy a több cache-sel mégsem volt gyorsabb. Aztán az Intelnél ebbõl is tanultak.
A P3 óta a cerka egyértelmûen a "budget" kategória.
Amúgy a leggyorsabb P2 cerka 533MHz-es volt, korának legyorsabb, olcsó x86-os asztali procija és durván húzható állat. Simá verte az elsõ P3-kat is.
#25
Nem a procira mondtam, hanem az IPC-jére, szal hogy a magas órajel ellenére lassú.
#24
Már maga a gondolat is hihetetelen, hogy egy P2 és egy P4 (v. Pentry) egyforma gyors lenne. Ha igy volna, soha senki se cserélt volna a sebesség miatt gépet. A mai szuper-(hiper)skalár cisc processzorok meg minden eddiginél elõdnél gyorsabbak, és ez azért tény. pl.
1. sokkal kisebb csíkszélesség, de
2. sokkal nagyobb Wattos fogyasztás, ezért
3. egyszerûen nem lehet lassabb. (kb. fordítottan arányos elvileg)
Ami miatt akár még lassúnak is tûnhetnek:
1. Optimalizáció hiánya: a végrehajtási optimalizáció a procin belül baromira lassíthat, ha nincs optimalizálva rá progi (stack, cache, queue opt. Olyan dolgokat számolnak ki a procik elõre, amik valószínûség alapján majd késõbb szükségesek lehetnek, addig meg elférnek a cache-ben). Tehát aki qrva gyors prg-ot akar írni, annak feltétlenül olyat kell, ami kihasználja az új utasításokat, amiket pl. egy órajel alatt végrehajt a CPU, és nem szöszmötöl sok régebbi utasításból összerakni azt amit az új CPU mondjuk ut. szinten tud. Emiatt egy régebbi utasítás végrehatási ideje akár hosszabb is lehet, mint anno.
2. Régen a 8 meg 16 bites adatokon, ma már 32 és 64 bites adatokon is tudnak pl. 1 órajel alatt számolásokat végrehajtani. Ez azért nem kis (teljesítmény)különbség. Amelyik progi ezt nem használja ki, az télleg ugyanolyan gyors a 32 meg a 64 bites rendszeren is. Az órajelnek azért kellene számítania ezeknél is. De ugye mostanában a GHz hajkurászás azért alább hagyott a technológiai korlátok miatt.
3. Sokkal inkább a párhuzamosítás a tendencia. Amelyik progi ezt sem használja ki, na az sem lesz gyorsabb, vagy max. annyival, amit az oprendszer nem vesz el elõle prociidõt, mert azt párhuzamosan megoldja pl. egy másik maggal.
szerintem
1. sokkal kisebb csíkszélesség, de
2. sokkal nagyobb Wattos fogyasztás, ezért
3. egyszerûen nem lehet lassabb. (kb. fordítottan arányos elvileg)
Ami miatt akár még lassúnak is tûnhetnek:
1. Optimalizáció hiánya: a végrehajtási optimalizáció a procin belül baromira lassíthat, ha nincs optimalizálva rá progi (stack, cache, queue opt. Olyan dolgokat számolnak ki a procik elõre, amik valószínûség alapján majd késõbb szükségesek lehetnek, addig meg elférnek a cache-ben). Tehát aki qrva gyors prg-ot akar írni, annak feltétlenül olyat kell, ami kihasználja az új utasításokat, amiket pl. egy órajel alatt végrehajt a CPU, és nem szöszmötöl sok régebbi utasításból összerakni azt amit az új CPU mondjuk ut. szinten tud. Emiatt egy régebbi utasítás végrehatási ideje akár hosszabb is lehet, mint anno.
2. Régen a 8 meg 16 bites adatokon, ma már 32 és 64 bites adatokon is tudnak pl. 1 órajel alatt számolásokat végrehajtani. Ez azért nem kis (teljesítmény)különbség. Amelyik progi ezt nem használja ki, az télleg ugyanolyan gyors a 32 meg a 64 bites rendszeren is. Az órajelnek azért kellene számítania ezeknél is. De ugye mostanában a GHz hajkurászás azért alább hagyott a technológiai korlátok miatt.
3. Sokkal inkább a párhuzamosítás a tendencia. Amelyik progi ezt sem használja ki, na az sem lesz gyorsabb, vagy max. annyival, amit az oprendszer nem vesz el elõle prociidõt, mert azt párhuzamosan megoldja pl. egy másik maggal.
szerintem
![[HUN]FaTaL](https://media.sg.hu/forum/avatars/10557508481320070594.gif)
#23
Hát ez meg relatív! Szar? Mire? Játékra, videora, 3dre, arra igen. Hogy miért? Hát mert nem arra lett kitalálva. Irodai munkára lett kitalálva és wordozni meg excelezni tökéletesen jó.
http://goo.gl/gd6Zi5
#22
1. P2bõl nem volt 600mhz, 400nál vége volt 450 már P3 volt..
2. tán nem a celeronhoz kéne hasonlítani, fõleg a régi utasításkészlettel íródott asm progit...
2. tán nem a celeronhoz kéne hasonlítani, fõleg a régi utasításkészlettel íródott asm progit...
http://goo.gl/gd6Zi5
#21
Talán nem egy Celeronon kéne próbálni lemérni, mennyit haladt a procifejlesztés az utóbbi pár évben! <#vigyor2> Ugyanis köztudottan(?) hiperrossz az IPC-je.
#20
Te meg mirõl beszélsz? Szerinted mi a különbség egy ASM-bõl fordított EXE és egy C-bõl fordított EXE között? Annyi, hogy az elõbbi pl. jó esetben kézzel optimizált lehet.
#19
Nyahh, a cikk forrása kicsit hiányos. Itt egy másik cikk ugyanerrõl, szó szerinti idézésekkel: LINK
"the new Penryn processors will have the same basic design as current ones, but the circuitry will be 30 percent thinner"
Tehát, akkor az órajel emelkedhet, illetve majd próbálják jobban nyomni a 4-magos példányokat (amik Intelnél továbbra is 2x 2 mag egy tokban).
"In high-performance computing and bandwidth intensive applications ... there will be up to a whopping 45 percent performance increase"
Na persze, mint tudjuk, az FSB-s megoldás (4 magra 1 FS😎 pont jó erre...
"In a prototype Penryn chip with four processing cores, that translated into 40 percent faster performance in computer games and video processing, while more mundane tasks such as image processing ran about 15 percent faster, Gelsinger said."
Ez egy kicsit zavaros... Ha pl. a videofeldolgozás 40%-kal gyorsabb, akkor a képfeldolgozás miért csak 15%-kal? Nos, úgy tûnik ebbõl, nem az órajel emelkedik 40%-ot (különben e kettõ kb. egyformán gyorsulna ugyebár), hanem a 2-mag vs. 4-mag is be van itt kalkulálva... Vagy mi...
"the new Penryn processors will have the same basic design as current ones, but the circuitry will be 30 percent thinner"
Tehát, akkor az órajel emelkedhet, illetve majd próbálják jobban nyomni a 4-magos példányokat (amik Intelnél továbbra is 2x 2 mag egy tokban).
"In high-performance computing and bandwidth intensive applications ... there will be up to a whopping 45 percent performance increase"
Na persze, mint tudjuk, az FSB-s megoldás (4 magra 1 FS😎 pont jó erre...
"In a prototype Penryn chip with four processing cores, that translated into 40 percent faster performance in computer games and video processing, while more mundane tasks such as image processing ran about 15 percent faster, Gelsinger said."
Ez egy kicsit zavaros... Ha pl. a videofeldolgozás 40%-kal gyorsabb, akkor a képfeldolgozás miért csak 15%-kal? Nos, úgy tûnik ebbõl, nem az órajel emelkedik 40%-ot (különben e kettõ kb. egyformán gyorsulna ugyebár), hanem a 2-mag vs. 4-mag is be van itt kalkulálva... Vagy mi...
#18
Nem vagyok nagy programozó, sem nagy informatikus, de azt tudom, ha például lerenderelek a studio max-ba egy scene-t mondjuk 600 Mhz-es gépen, és ugyanazt egy 2 Ghz-es gépen akkor a renderidõ ég és föld, tehát valamit csak gyorsabban futtatnak. Ehhez nem kell semmiféle assembly humbug.
http://bf1942.gametrack.org/sig_3210436_omaha1_times.png
#17
Látom a kevés megadott információ miatt jó nagy kavarodást okoztam 😊
A programom boot szektorból tölt be, védett módba kapcsol, és egy kis parancsor az egész, assembly-ben írtam. Kiegészítettem egy prímkeresõvel, hogy tesztelni tudjam a régi, és az új gépem processzora közötti különbséget. Elmenti a hardverórából, hogy mikor kezdte, és amikor végzett kiírja, meg a pontos idõt is. A kettõ különbsége az eltelt idõ. Ez rendre a P2-esen kevesebb (600-MHz), mint a P4-en (2GHz). Csak rendszerutasításokat használok, ami már a 386-os óta benne vannak.
Ehhez varrjatok gombot 😛
U.I.: akinek nincs fogalma róla, hogy mit jelentekek a szavak a felsõ bekezdésben, kérem hogy ne is próbáljon válaszolni... köszönöm.
A programom boot szektorból tölt be, védett módba kapcsol, és egy kis parancsor az egész, assembly-ben írtam. Kiegészítettem egy prímkeresõvel, hogy tesztelni tudjam a régi, és az új gépem processzora közötti különbséget. Elmenti a hardverórából, hogy mikor kezdte, és amikor végzett kiírja, meg a pontos idõt is. A kettõ különbsége az eltelt idõ. Ez rendre a P2-esen kevesebb (600-MHz), mint a P4-en (2GHz). Csak rendszerutasításokat használok, ami már a 386-os óta benne vannak.
Ehhez varrjatok gombot 😛
U.I.: akinek nincs fogalma róla, hogy mit jelentekek a szavak a felsõ bekezdésben, kérem hogy ne is próbáljon válaszolni... köszönöm.
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#16
Hát ha egy cpu mag beszállna a shaderek futtatásába, az kb semmit nem érne, mert egy gpu többszázszor gyorsabban végzi ezeket a feladatokat -> cpu segítsége nem oszt nem szoroz. Szal max azt szeretnék hogy gyorsítson 😄
Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)
#15
"A processzorgyártó eközben a Penry legfontosabb elõnyét ismertette, amely állításuk szerint a játékoknál 40, a munkaállomásoknál 45 százalékos gyorsulást eredményez majd a jelenlegi leggyorsabb négymagoshoz, vagyis a Core 2 Extreme QX6800-hoz képest."
Mi van! Ha nem multi threades a játok, akkor hogy fog gyorsítani a 4 mag, vagy talán beszálnak a GPU shadereinek a futtatásába? <#vigyor>
Mi van! Ha nem multi threades a játok, akkor hogy fog gyorsítani a 4 mag, vagy talán beszálnak a GPU shadereinek a futtatásába? <#vigyor>
#14
Ezért nem képesek 64 bites Windows-ok 16 bites progikat futtatni, mert már elhasználták a hardweres 8086 virtualizáció a Win32-es progikra.
#13
"attól függ, hol futtatja, ha windóz-ból, akkor hót tuti, hogy virtuális gépen fut, nehogy felboruljon minden..."
NTVDM nem normális virtuális gép, csak kihasználja a i386 és ujabb procik 8086 virtualizációját, így minden memória címet sokkal magasabb értékre tol el, továbbá az in, out és int utasításokat programozott kivétellel elkap és Win32-õn hagyja végre ha lehet.
x64-es Windows-ok ugyan ezt a módszert használják 32 bites Windows-os progik futtatásához, csak azokban, nincs in, out és int helyettük függvényhívások vannak és a hívások végén csak azokat kell átvinni a 64bitten mûködõ kernel komponensek felé.
NTVDM nem normális virtuális gép, csak kihasználja a i386 és ujabb procik 8086 virtualizációját, így minden memória címet sokkal magasabb értékre tol el, továbbá az in, out és int utasításokat programozott kivétellel elkap és Win32-õn hagyja végre ha lehet.
x64-es Windows-ok ugyan ezt a módszert használják 32 bites Windows-os progik futtatásához, csak azokban, nincs in, out és int helyettük függvényhívások vannak és a hívások végén csak azokat kell átvinni a 64bitten mûködõ kernel komponensek felé.
#12
A lenyeg,hogy a Ps2 emulator rendesen profitaljon ebbol😊
Szal kell az a gyorsulas!
Szal kell az a gyorsulas!
Bérbe vehet? reklámfelület...
#11
Hiába próbálkozik a pc akkor sem fognak jobban jönni a pc játékok, akkor sem fogják többen nyomni pcn.
A
#10
attól függ, hol futtatja, ha windóz-ból, akkor hót tuti, hogy virtuális gépen fut, nehogy felboruljon minden...
---
plussz ezek a procik leginkább abban fejlõdtek, hogy kibõvítették sok más utasítással õket, és valószínûleg te nem optimalizáltad a programod az újabb utasításkészletre...
---
plussz ezek a procik leginkább abban fejlõdtek, hogy kibõvítették sok más utasítással õket, és valószínûleg te nem optimalizáltad a programod az újabb utasításkészletre...
Assembly progi emulálva? 😊 Mégpedig? Okok?
Will your Soul live for Ever?
#8
"Az Intel 40 százalékos ugrást emleget, mégpedig a játékoknál és a munkaállomásoknál."
Erre mondják az öregek, hogy megeszem a kalapom, ha ennek csak a fele is igaz... Lesz itt max. 10-15%-os emelkedés nagyon jó esetben...
Erre mondják az öregek, hogy megeszem a kalapom, ha ennek csak a fele is igaz... Lesz itt max. 10-15%-os emelkedés nagyon jó esetben...
#7
Miért is fut egy assembly program emulálva?
Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)
#6
Szia! Igazad van csakhogy nem vetted számításba hogy az assembly program emulálva fut. Így ha most 3ghz-es CPU-n írok egy assembly programot akkor az ugyanugy fut mintha azt 233mhz MMX-en írnám 😄
Asus P5QL PRO motherboard | Core 2 Duo E8400 3Ghz | Kingmax 4*1 GB DDR2 1066Mhz |Asus EN7950GT 512MB | Sound Blaster Audigy 2 Value 64bit | 2*250GB Samsung Sata2 HDD
Azért nekem van néhány programom, ami gyorsabban lefut a mostani AthlonXP-men, mint a régi P200MMX-en... Ja és csak a CPU számol, nem eszik RAM-ot, és nem darálja le a merevlemezt sem.
#4
1 kis hozzanemertesrol tettel tanubizonysagot... a 2 proci kozt nem csak a frekvencia volt a kulonbseg!
\"Holló, Hologram, Honolulu, Holokauszt, Hazugság\"
#3
40%? Haha! Nagy a szájuk, hogy így meg úgy gyorsulnak, de a 32-bites assembly prímkeresõ programom ugyanolyan gyors volt 600 MHz-s Pentium 2-õn, és 2 GHz-s Celeronon is! Nagy humbug az egész, a procik szarok, a memóriák, és a vinyók lettek gyorsabbak, és kész.
Fizikakönyvem: http://valek.webs.com/ \"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e.\" /Petőfi Sándor/
#2
én is rohanok a "change money"-ba egy ezerdollárosért ...õõõõ meg egy új alaplapért 200$ ... meg 4GB kurvadrága RAM-ért 300$ ...csába ehhez a rendszerhez már kevés a 8800gtx akkor ha már itt vagyok veszek egy 8950-et , akkor még egy 1000$-ost kérek szépen <#idiota>
schrank[HUN] \"kiakirály\" \"jobb ha az okos hülyéskedik mint ha a ....\"
Az Intel 40 százalékos ugrást emleget, mégpedig a játékoknál és a munkaállomásoknál.
Ennek nagyon örülnék.
Ennek nagyon örülnék.
A buta embert gondolatai irányítják, a bölcs irányítja gondolatait.