41
-
BiroAndras #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). -
bvalek2 #40 (Részben) visszaadtad a hitemet az informatika fejlődésében :) -
dez #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. -
bvalek2 #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. -
bvalek2 #37 nem chache, hanem cache... 
-
bvalek2 #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 
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). -
dez #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. -
fade2black #34 most van oprendszer vagy nincs? -
bvalek2 #33 "beljesében" (C) bvalek2, a Nyelvujító 
-
bvalek2 #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. -
dez #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. :) -
bvalek2 #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.
[HUN]FaTaL:
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 -
dez #29 Ja, nem, az még P3 volt, szal akkor s.423. -
dez #28 s.462-be nehezen, mert az AMD-s foglalat volt. :)
Te a s.370-ről beszélsz. -
JTBM #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. ;-))) -
maxspeed2107 #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. -
dez #25 Nem a procira mondtam, hanem az IPC-jére, szal hogy a magas órajel ellenére lassú. -
maxspeed2107 #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
-
![[HUN]FaTaL](https://media.sg.hu/forum/avatars/10557508481320070594.gif "[HUN]FaTaL")
#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ó. -
#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... -
dez #21 Talán nem egy Celeronon kéne próbálni lemérni, mennyit haladt a procifejlesztés az utóbbi pár évben! Ugyanis köztudottan(?) hiperrossz az IPC-je.
-
dez #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. -
dez #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 FSB) 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. -
bvalek2 #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 :P
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. -
#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 :D -
A1274815 #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?
-
A1274815 #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. -
A1274815 #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é. -
#12
A lenyeg,hogy a Ps2 emulator rendesen profitaljon ebbol:)
Szal kell az a gyorsulas! -
#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. -
oneman #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...
-
sylverangel #9 Assembly progi emulálva? :) Mégpedig? Okok? -
#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... -
#7
Miért is fut egy assembly program emulálva? -
CyrSyS #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 :D -
maxspeed2107 #5 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! -
bvalek2 #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. -
#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 