[hvuk]

Idézet: special - Dátum: 2004. szept. 2., csütörtök - 19:30

Hvuk, mibõl gondolod, hogy az IMC "urgent" tervezési cél lenne az x86-os vonalon? Szerintem az IMC elõnyét csak számítástechnikailag lehet feltétlenül igazolni (nagyon sok procis rendszerben ott sem mindig, lásd Sun). Ezzel szemben felhozhatók érvek az IMC ellen gyártási és gazdaságossági szempontból.

Nem mondtam, hogy az IMC "urgent" állapotban lenne. Nem ott van, mert annyi dolguk van, hogy a mérnökök teljesen el lehetnek havazva. Viszont "urgent"-nek kellene lennie. Az ok egyszerû: nyernének vele vagy 15-20% teljesítményt a processzoraik. És a teljesítmény növelése viszont "urgent" cél, mert jelenleg az AMD erõsen meglépett. Egy IMC-vel pedig utol lehetne érni. Éppen ezért teljesen logikus lépés lenne (lett volna) az Inteltõl az IMC mielõbbi megvalósítása. Mivel nem tették meg és e lépés megtétele ellen semmi semmi nem szól, mellette viszont igen, így feltehetõ, hogy nem tudták megtenni. Erre a legvalószínûbb magyarázat pedig, hogy nincs rá erõforrásuk.

E szép gondolatmenet ellenére persze elképzelhetõ, hogy egyéb okok miatt nem lépték (nem tudták meglépni) az IMC-t. Például azért, mert a P4 architektúrára nehéz ráapplikálni. Vagy azért, mert valami fejes úgy döntött irracionálisan módon, hogy nem lesz IMC. Vagy valami teljesen más általunk nem ismert dolog az oka.

Az Itaniummal tényleg más a tészta, ott nyilván lényegesen késõbb tudják csak meglépni. 2007-es dátumban nem hiszek, szerintem inkább 2008 lesz az, ha 2007-ben lesz Tukwilla, akkor megeszem a kalapom.

A Xeonok esetén viszont megint nem lenne semmi akadálya az IMC bevezetésének. És ott nagyon nagy teljesítményt lehetne nyerni. Persze az igaz, hogy több processzoros rendszerek miatt az IMC bevezetése nem egyszerû. Mellesleg lehet, hogy a desktopon is azért nem lépték meg a dolgot, mert többprocesszoros rendszerek esetén nagyon át kellett volna tervezni a processzort (és a chipsetet), és nem akartak az egyprocesszoros rendszereknél más buszrendszert, mint többprocesszoros rendszereknél. Ez viszont arra utal, hogy nem jól mérték fel a trendeket és a lehetõségeket. Most meg szívnak emiatt.

[special]

Szerintem a végén meg is válaszolod nagyjából a valószínûbb indokot, hogy miért nincs IMC: a Pentium 4 és Xeon egy szép nagy család, megbontani pedig nem éri meg, mert a +10-20-30 százalékkal nem nyernének annyi piacot, vagy inkább pontosabban, nem állítanák meg sokkal jobban az AMD-t. Azért azt ne felejtsük el, hogy a sorozatos technikai kudarcok után még mindig uralják a piacot.

A tukwillás kalapevés pedig elég kockázatos szerintem annyiban, hogy amennyire én tudom, arra a projektre teljesen különálló team van ráállítva, így a NetBursttel való bénázások nem zavarják õket, legfeljebb morálisan.

[Rive]

Idézet: hvuk - Dátum: 2004. szept. 3., péntek - 9:41

Nem mondtam, hogy az IMC "urgent" állapotban lenne. Nem ott van, mert annyi dolguk van, hogy a mérnökök teljesen el lehetnek havazva. Viszont "urgent"-nek kellene lennie. Az ok egyszerû: nyernének vele vagy 15-20% teljesítményt a processzoraik. És a teljesítmény növelése viszont "urgent" cél, mert jelenleg az AMD erõsen meglépett. Egy IMC-vel pedig utol lehetne érni. Éppen ezért teljesen logikus lépés lenne (lett volna) az Inteltõl az IMC mielõbbi megvalósítása. Mivel nem tették meg és e lépés megtétele ellen semmi semmi nem szól, mellette viszont igen, így feltehetõ, hogy nem tudták megtenni. Erre a legvalószínûbb magyarázat pedig, hogy nincs rá erõforrásuk.

Ismét, itt is magadat gyõzködöd arról, amit az elõzõ mondatban mint tényt állítottál. Emiatt hagytam itt az egész procitémát, és ezért nem is szándékozom folytatni.

Az IMC nem sürgõs az Intelnek. Ha odafigyeltél, akkor láthattad már, hogy a long pipe köszöni, nem profitál igazán a kisebb késleltetésû memóriából: az Intel-féle short pipe meg köszöni, anélkül is - meg egy csomó egyébb nélkül is - bõven sok területen alázza az Opteront. Akkor most miért kellene az IMC? Hogy ujra alaplapot lehessen cseréltetni a népekkel? Egy alig bevezetett memóriatípus és a hozzá tartozó, épp felfutó széles spektrumú chipset-biznic kellõs közepén? Vagy hogy megtörjék a bejáratott szerverpiaci renoméjukat egy elkapkodott döntéssel? Eh...

Idézet

Ráadásul az Opteron villámgyorsan terjeszkedik felfelé, év végére benyomul a 8 processzoros szerverek piacára, kb. másfél év múlva meg a 16-32 processzorosokéra. És így a teljes Xeon vonallal szemben lesz AMD alternatíva, mégpedig teljesítmény és ár szempontjából egy lényegesen jobb alternatíva, mint a Xeon vonal.

Vajon az akkori Xeonoknál is jobb alternatíva lehet majd? Mer' ugye... Meg ráadásul az AMD 'villámgyors felfele terjeszkedése' a piacon tespedten álldogál a négy procinál, meg a 8+ procis kísérletezésnél, és prímán látszik, hogy ebbõl leghamarabb akkorra várható 'áttörés' felfele, ha a quad procikkal tolhatják majd a quad short pipe 8M cache Xeonokkal szemben...

Szerkesztette: Rive 2004. 09. 03. 08:59 -kor

[hvuk]

Igen, szép lassan az együttgondolkodás hatására rájövünk a tényleges indok(ok)ra. Viszont továbbra is fenntartom, hogy az IMC-re nagy szüksége lenne az Intelnek, viszont annak kifejlesztése hatalmas feladat. Ha tudná megtenné, de nem tudja (legalábbis rövid távon nem tudja). Az a 15-20% teljesítmény nagyon is sokat számítana az Intelnek, ha 1 évvel ezelõtt a Xeonok ennyivel nagyobb teljesítményt tudtak volna, akkor nem lenne ilyen erõs az Opteron térhódítása. Az Opteronokat nem az AMD két szép szeméért veszik, hanem azért, mert egy halom alkalmazása alatt (gyakorlatilag a workstation alkalmazásokat leszámítva mindenben) messze felülmúlják teljesítményben a Xeonokat. Ha a két processzor pariban lett volna vagy csak minimális lett volna az Opteron elõnye, akkor az Opteron lényegesen kisebb siker lett volna.

Az Intel piacait pedig igenis veszélyezteti az AMD (elsõsorban az Opteronnal). A tendenciát kell ugyanis figyelni: egy év alatt 6%-os részesedést szerzett az X86 szerver piacon és év végére reálisnak tûnhet a 10%. Ami a processzorok piacán még nagyobb részesedést jelent (legalábbis a híradások szerint). Ez pedig azt jelenti, hogy az Intel X86 szerver piaci részesedése erõsen csökken.

A desktop piacon pedig az a problémája, hogy már nem egyedül és mindenhatóan diktálja az árakat. Nehéz ugyanis az árakat úgy diktálni, hogy nem a tiéd a leggyorsabb processzor. Persze hatalmas piaci súlyánál fogva még mindig hatékonyan befolyásolja az árak alakulását, de ha a régebbi ráhatását 95%-nak tekintjük, akkor ez most már csak valahol 70% körül mozog. További gondja, hogy ahogy az Opteron terjed a szerver paicon, úgy gyûrûzik le ennek hatása a desktopra: ha ugyanis az Opteron szerver gond nélkül üzemel egy cégnél, akkor õk könnyebben fognak Athlon 64 desktopokat vásárolni. Ami persze baromság ugyanúgy, mint baromság az (bár azért az nagyobb), hogy azért vesz valaki megint mondjuk Xeon szervert, mert a 2-3 éve vásárolt P3-as szervere gond nélkül mûködött. De ettõl persze még mûködik ez az effekt. A desktopon van még egy harmadik problémája: a leggyorsabb és ezért legnagyobb haszonnal eladható processzorokkal gyártási nehézségei vannak. Az AMD ASP-je szépen emelkedik, míg - legjobb tudomásom szerint - az Intelé csökken.

Ezzel persze nem temetni akarom az Intelt, csak annyit, hogy jelenleg a folyamatok nem a számukra kedvezõ irányban haladnak. És kötve hiszem, hogy ennek jelentõségét õk lebecsülnék. Éppen ennek köszöhetõ ez a nagy kapkodás. És ez a kapkodás és a jelenlegi gondok két alapvetõ tévedés miatt alakultak ki szerintem: az Itanium teljesítményének és elterjedésének felülbecslése és a NetBurst architektúra melletti döntés miatt. És persze amiatt, hogy az Opteron/A64 vonal sikerességét alábecsülték. Ez már 3.

[hvuk]

Idézet: Rive - Dátum: 2004. szept. 3., péntek - 9:57

Ismét, itt is magadat gyõzködöd arról, amit az elõzõ mondatban mint tényt állítottál. Emiatt hagytam itt az egész procitémát, és ezért nem is szándékozom folytatni.

Az elsõ mondatban arról beszéltem, hogy az Intelnek nem "urgent", a másodikban meg arról, hogy "urgent"-nek kellene, hogy legyen.

Idézet

Az IMC nem sürgõs az Intelnek. Ha odafigyeltél, akkor láthattad már, hogy a long pipe köszöni, nem profitál igazán a kisebb késleltetésû memóriából: az Intel-féle short pipe meg köszöni, anélkül is - meg egy csomó egyébb nélkül is - bõven sok területen alázza az Opteront. Akkor most miért kellene az IMC? Hogy ujra alaplapot lehessen cseréltetni a népekkel? Egy alig bevezetett memóriatípus és a hozzá tartozó, épp felfutó széles spektrumú chipset-biznic kellõs közepén? Vagy hogy megtörjék a bejáratott szerverpiaci renoméjukat egy elkapkodott döntéssel? Eh...

Akartam írni, hogy kérdéses, hogy vajon mennyit profitál a NetBurst az IMC-bõl. Õszintén szólva nem igazán láttam errõl teszteket (mármint arról, hogy miként viselkedik az alacsonyabb késleltetésû memóriával). Megpróbálok majd utánanézni. Az viszont, hogy a P4 szereti a nagyobb cachet arra utalhat, hogy gyorsulna tõle rendesen.

Miféle X86-os rövid pipe-ú Intel szerver proci van? Tudtommal csak P4 derivánsok vannak, amik nem éppen a rövid pipe-ról híresek. Jelenleg a Xeon kikap teljesítmény terén az Opterontól (legalábbis a legtöbb alkalmazásban). Az esetleges jövõbeli rövid futószalagos szerverprociknak pedig már nem az Opteronokkal, hanem a K9-el kell megküzdeniük. Ha már a teoretikus prociknál tartunk.

Idézet

Vajon az akkori Xeonoknál is jobb alternatíva lehet majd? Mer' ugye... Meg ráadásul az AMD 'villámgyors felfele terjeszkedése' a piacon tespedten álldogál a négy procinál, meg a 8+ procis kísérletezésnél, és prímán látszik, hogy ebbõl leghamarabb akkorra várható 'áttörés' felfele, ha a quad procikkal tolhatják majd a quad short pipe 8M cache Xeonokkal szemben...

Ez a terjeszkedési ütem lényegesen gyorsabb, mint amit anno az Intel tudott produkálni. Az Opteron egy év alatt eljutott az 1-2 processzoros rendszerektõl a 4 processzorosokig. Ezt én villámgyorsnak nevezném. Még az idénre ígérte a Sun a 8 processzoros Opteron rendszerét, így azért én ezt lényegesen elõbb várom. Mondjuk úgy fél-3/4-ed éven belülre.

[special]

Kicsit elmebetegeskedtem, közzéteszem, hátha valakit érdekel (note, a két proci ára megegyezik, a rendszerek árai nem elérhetõek, vélhetõen az Itaniumé a platform drágasága miatt sokkal magasabb):

Persze a lényeg kimaradt:  IBM Corporation eServer 325 (2-way 2.4 GHz AMD Opteron vs. SGI Altix 350 (2-way 1400MHz/3MB, Itanium 2)

INT_rate                                        I2/O (%)       O/I2 (%)      Gyõztes                                 

Compression                                       60,25        165,98      Opteron                                            
FPGA Circuit Placement and Routing                   85        117,65      Opteron                                            
C Programming Language Compiler                   76,75        130,29      Opteron                                            
Combinatorial Optimization                       273,26          36,6      Itanium                                            
Game Playing: Chess                               53,23        187,86      Opteron                                            
Word Processing                                   73,54        135,98      Opteron                                            
Computer Visualization                            82,17        121,69      Opteron                                            
PERL Programming Language                          71,1        140,65      Opteron                                            
Group Theory, Interpreter                         56,74        176,25      Opteron                                            
Object-oriented Database                          93,69        106,73      Opteron                                            
Compression                                       82,43        121,31      Opteron                                            
Place and Route Simulator                        105,91         94,42      Itanium                                            
                                                                                                                   
Átlag a legnagyobb különbséget kiszûrve           70,07         124,9      Opteron                                 
                                                                                                                   
FP_rate                                            I2/O          O/I2      Gyõztes                                 

Physics / Quantum Chromodynamics                  81,25        123,08      Opteron                                 
Shallow Water Modeling                           108,45         92,21      Itanium                                 
Multi-grid Solver: 3D Potential Field            110,48         90,51      Itanium                                 
Parabolic / Elliptic Partial Differential        230,23         43,44      Itanium                                 
3-D Graphics Library                              64,21        155,73      Opteron                                 
Computational Fluid Dynamics                     127,25         78,58      Itanium                                 
Image Recognition / Neural Networks              578,36         17,29      Itanium                                 
Seismic Wave Propagation Simulation              161,44         61,94      Itanium                                 
Image Processing: Face Recognition                95,35        104,88      Opteron                                 
Computational Chemistry                           98,88        101,13      Opteron                                 
Number Theory / Primality Testing                 92,13        108,54      Opteron                                 
Finite-element Crash Simulation                    78,2        127,88      Opteron                                 
High Energy Nuclear Physics Accelerator D         210,2         47,57      Itanium                                 
Meteorology: Pollutant Distribution               69,39        144,12      Opteron                                 
                                                                                                                   
Átlag a legnagyobb különbséget kiszûrve           117,5         98,43      Itanium  

Szerkesztette: special 2004. 09. 03. 10:29 -kor

[hvuk]

Idézet: hvuk - Dátum: 2004. szept. 3., péntek - 10:34

Az elsõ mondatban arról beszéltem, hogy az Intelnek nem "urgent", a másodikban meg arról, hogy "urgent"-nek kellene, hogy legyen.

Amúgy épp az elõbbi hozzászólásomban írtam a véleményem megváltozásáról. De az teljesen logikus egy beszélgetésben, hogy a vélemények változnak mivel új megvilágításba kerülnek az ismeretek, amik miatt az emberek álláspontja megváltozhat. Ez teljesen normális folyamat, csak a nagyon buták ragaszkodnak a véleményükhöz körömszakadva. És persze ebben nincs semmi szégyelnivaló.

A fenti esetben persze másról van szó, ott a bekezdés késõbbi részében nem az elsõ mondattal vitatkoztam.

[hvuk]

A HWSW láblógatós cikkében a 925G/P chipsetes DDR400-as (CL2) és DDR2-533-as (CL4) memóriával szerelt 3.6 GHz-es P4-eket tesztelték (többek közt). A DDR-2-es gép a 800MHz-es rendszerbusz miatt persze csak korlátozottan tudta kihasználni a DDR2 nagyobb sávszélességét. A versenyben a DDR400-as rendszer nagyjából 3%-al verte meg a másik gépet (bár elég nagy a szórás, volt, hogy a DDR2-es rendszer nyert). A késleltetése a DDR2-es rendszernek kb. 7%-al volt magasabb, mint a DDR-ének. Az IMC hatására kb. 55-60%-ra esne a késleltetés, ami ez alapján kb. 15-18%-os teljesítménynövekedést okozna (a DDR-hez képest). Ez persze nagyon durva becslés volt és nagyon sok helyen hibázhat a dolog. A legjobb lenne egy olyan teszt, ahol egy P4-es rendszer késleltetését és teljesítménykülönbségét néznék CL2 és CL3 esetén. Majd megpróbálok elõásni egy ilyen cikket.

[Michell]

Üdv.
Nos akkor a sok jövõbenézés után a múlt és a jelen. Mivel megint egy Itanium2 közelébe kerültem, illetve elõkerültek a saját teszttáblázataim. Mindenesetre számomra elég vegyes képet mutatnak.

Az adatsorok némi adatbázisteszt summázata 1.egyszerû insert, és változó ERP feladatok , a 2. és 7. adatot kivéve tárolt eljárás futása - tesztenként változó diszkmûvelet aránnyal.
(Idõeredmények másodpercben, kivéve a p.=perc.
Azzal pedig teljesen felesleges jönni, hogy azonos feltételekkel kellene tesztelni, csak azt tudtam nézni aminek a közelébe jutottam legalább napokra - szabadon, illetve a  paraméterezés is olyan amivel az adott gépet ki tudtam használni.)

  DTK  HP-Xeon  Sun  HP-Itanium
1.  538      139          754  245
2. 24        16            42      19
3. 32        15            12        7
4. 86        40            25      17
5.  409      295          295      10
6. 40        14            58      45
7.  140 p.                            80 p.

Konfigok röviden:
DTK-2xPIII/550MHz-256MB-SCSI-W2000-Oracle 8i
HP-P4Xeon DP/2.4GHz-512MB-SCSI-W2003-Oracle 9i
Sun-4xUSIII/750 MHz-8GB-FibreCh-Solaris9-Oracle 9i
HP-RX2600 Itanium2/1.3GHz-2GB-SCSI-W2003/64-Oracle 9i

[special]

Idézet: hvuk - Dátum: 2004. szept. 3., péntek - 11:16

A HWSW láblógatós cikkében a 925G/P chipsetes DDR400-as (CL2) és DDR2-533-as (CL4) memóriával szerelt 3.6 GHz-es P4-eket tesztelték (többek közt). A DDR-2-es gép a 800MHz-es rendszerbusz miatt persze csak korlátozottan tudta kihasználni a DDR2 nagyobb sávszélességét. A versenyben a DDR400-as rendszer nagyjából 3%-al verte meg a másik gépet (bár elég nagy a szórás, volt, hogy a DDR2-es rendszer nyert). A késleltetése a DDR2-es rendszernek kb. 7%-al volt magasabb, mint a DDR-ének. Az IMC hatására kb. 55-60%-ra esne a késleltetés, ami ez alapján kb. 15-18%-os teljesítménynövekedést okozna (a DDR-hez képest). Ez persze nagyon durva becslés volt és nagyon sok helyen hibázhat a dolog. A legjobb lenne egy olyan teszt, ahol egy P4-es rendszer késleltetését és teljesítménykülönbségét néznék CL2 és CL3 esetén. Majd megpróbálok elõásni egy ilyen cikket.

Játékteszt azonos órajelû Pentium 4-ekkel 400/533/800-as változatokban?

[hvuk]

Idézet: special - Dátum: 2004. szept. 3., péntek - 11:28

Játékteszt azonos órajelû Pentium 4-ekkel 400/533/800-as változatokban?

Nem, én azonos busz/memória frekvenciára, de eltérõ késleltetésre gondoltam. Ugyanis a késleltetés csökkenésének hatását szeretnénk nézni a P4 teljesítményére és ebbõl következtetni az IMC hatására.

Kellene egy késleltetés mérés, meg néhány teszt. Elsõsorban valós alkalmazásokról (mondjuk játékok vagy tömörítõk és (de)kóderek). Ebbõl és abból, hogy tudjuk, hogy IMC-vel mekkora lenne a késleltetés meg lehet becsülni a teljesítmény növekedést.

Szerkesztette: hvuk 2004. 09. 03. 10:51 -kor

[special]

De miért nem jó, amit írtam? A processzor órajele azonos, a memória elérése pedig változik (nyilván nem a memória ugyanaz lenne, csak DDR200/266/400 módokban, ugyanolyan idõzítésekkel). UT botmatch például kiváló lenne.

[hvuk]

Idézet: special - Dátum: 2004. szept. 3., péntek - 11:56

De miért nem jó, amit írtam? A processzor órajele azonos, a memória elérése pedig változik (nyilván nem a memória ugyanaz lenne, csak DDR200/266/400 módokban, ugyanolyan idõzítésekkel). UT botmatch például kiváló lenne.

Ne már! Valamit vagy én értek félre nagyon vagy te! Az IMC nem növeli meg a sávszélességet (illetve igen, de ezt most hanyagoljuk el), viszont rendkívûl (kb. felére) csökkenti a késleltetést. Ergo a késleltetés hatására (és csak arra!) vagyunk kíváncsiak. A te kísérletedben azonban a sávszélesség változik, annak a hatására viszont nem vagyunk kíváncsiak. Illetve igen, de az most irreleváns.

[Atti]

Idézet: special - Dátum: 2004. szept. 3., péntek - 11:56

a memória ugyanaz lenne, csak DDR200/266/400 módokban, ugyanolyan idõzítésekkel

pont fordítva, ugyanaz a buszsebesség, csak más idõzítéssel

[special]

Most ugye nem azt mondjátok, hogy az busz és a memória órajelének növekedése nem csökkenti a memória elérés processzor órajelében mért késleltetését?

[hvuk]

Idézet: special - Dátum: 2004. szept. 3., péntek - 12:31

Most ugye nem azt mondjátok, hogy az busz és a memória órajelének növekedése nem csökkenti a memória elérés processzor órajelében mért késleltetését?

Persze, hogy csökkenti! Csak éppen a mérésnél fogalmad sem lesz, hogy mennyi teljesítménynövekedés származott a megnövelt memória sávszélességbõl és mennyi a lecsökkent késleltetésbõl. A fix sávszélesség esetén viszont egyszerû a dolog: minden növekedés a lecsökkent késleltetésnek köszöhetõ.

Szerkesztette: hvuk 2004. 09. 03. 11:36 -kor

[special]

Idézet: hvuk - Dátum: 2004. szept. 3., péntek - 12:35

Persze, hogy csökkenti! Csak éppen a mérésnél fogalmad sem lesz, hogy mennyi teljesítménynövekedés származott a megnövelt memória sávszélességbõl és mennyi a lecsökkent késleltetésbõl. A fix sávszélesség esetén viszont egyszerû a dolog: minden növekedés a lecsökkent késleltetésnek köszöhetõ.

Ez igaz, de közelítésnek az IMC-hez a gyakorlatban szerintem jobb eredményt fog adni, mint a memóriamodulok bizergálása. Ezért kell olyan programot vagy algoritmust keresni, amely erõsen késleltetésfüggõ és nagyon kevéssé sávszélesség. Ehhez elegendõ megkeresni azokat az eredményeket, ahol az egycsatornás IMC-vel ellátott K8-ak gyalázták a Pentiumokat.

[Rive]

Idézet: special - Dátum: 2004. szept. 3., péntek - 12:45

Ez igaz, de közelítésnek az IMC-hez a gyakorlatban szerintem jobb eredményt fog adni, mint a memóriamodulok bizergálása. Ezért kell olyan programot vagy algoritmust keresni, amely erõsen késleltetésfüggõ és nagyon kevéssé sávszélesség. Ehhez elegendõ megkeresni azokat az eredményeket, ahol az egycsatornás IMC-vel ellátott K8-ak gyalázták a Pentiumokat.

Nem jó, sajnos. A programok körének szûkítésével pont a teszt általánossága, az eredmények extrapolálhatósága veszik el.

Ami mûködik: az ember elkezdi azonos core esetén állítani a memória paramétereit és az FSB/FCore szorzót. Minden méréssorozathoz - egy mérés nem mérés! - rögzít egy latency és egy bandwidth értéket. Úgy harminc-negyven méréssel késõbb összerak egy táblázatot, majd a célbavett területre készít egy közelítõ függvényt, ami megmondja, mennyire és hogyan függ az adott program esetében a runtime a paraméterektõl az adott határértéken és hibán belül.

Szerkesztette: Rive 2004. 09. 03. 11:53 -kor

[hvuk]

Na, találtam egy baba cikket! optimális memória a P4-hez.

A leglassab és a leggyorsabb konfig közti különbséget néztem. A leggyorsabb konfig 2-2-2-5 beállításokkal ment, a leglassabb 3-4-4-8-al. Mindkét esetben egy 3.2 P4 volt az alany 800 MHz-s rendszerbusszal és 400 MHz-s DDR-rel. A leggyorsabb konfig késleltetése a Cachemem szerint 242, a leglassabb esetben 289 (csak tudnám, hogy miben mérték, gondolom órajel ciklusban, bár végül is mindegy). A késleltetés 84%-ra esett vissza a lassú-gyors váltásnál. Az eredmények kivonatos formában (csak a nem szintetikus bechmarkokat néztem):

Teszt: gyors/lassú - gyorsulás

Winrar: 100/122 - 22%!!!
MPEG-4: 43/40.7 - 5.5%
Quake3: 465/423 - 10%
UT: 66.2/62.6 - 5.7%
Serious Sam: 138/130: 6%

Az eredmény tehát elég vegyes, de mindenütt legalább 5.5%-os növekedést lehetett tapasztalni. Vegyük figyelembe, hogy a játékok 1024x768-ban futottak, ahol a grafikus kártya is némileg korlátozó tényezõ lehetett. Kivéve talán Q3 esetét. Nyugodtan mondhatjuk tehát, hogy a késleltetés 84%-ra történõ visszaesése mintegy 7-8%-os teljesítménynövekedést okozott átlagosan. Az 55-60%-ra történõ visszaesés tehát 18-20%-ot jelentene (ha igaz a lineáris interpoláció). Magyarán a P4 is jelentõsen gyorsulna az IMC-tõl. QED. 

[hvuk]

A Winrar mérése folyamán gondolom volt némi mérési hiba is. Persze lehet, hogy a latency mérés nem volt pontos vagy a két hiba együtt okozhatta. A lényegen ez azonban nem változtat.