Geheugenondersteuning Athlon 64 revisie E onderzocht

Bij AnandTech is een artikel verschenen waarin de geheugenondersteuning van de Athlon 64 revisie E wordt getest. Processors gebaseerd op de E-revisie zijn de Athlon 64 X2, de op de Venice-core gebaseerde Athlon 64 en de op de San Diego-core gebaseerde Athlon 64 FX. De E-revisie bevat verschillende kleine verbeteringen en tweaks waaronder een aantal nieuwe “memory dividers”, één van de factoren die bepalen op welke kloksnelheid het geheugen zal draaien. Met behulp van de nieuwe dividers is het mogelijk om gebruik te maken van geheugen met een hogere kloksnelheid zonder de HyperTransport-link te overklokken.

Door gebruik te maken van de nieuwe dividers wordt een maximale geheugensnelheid mogelijk die varieert tussen de 244 en 266MHz, afhankelijk van de kloksnelheid van de processor. Het blijkt dat de Athlon 64-processors, zowel de single core als de dual-coremodellen, weinig baat hebben bij sneller geheugen. In de meeste benchmarks is de winst slechts enkele procenten. AnandTech concludeert dan ook dat het een verstandig besluit is geweest van AMD om voorlopig ‘slechts’ DDR400-geheugen te ondersteunen voor de Athlon 64-serie. De nieuwe geheugendividers zijn wel een goede kans voor de computerenthousiastelingen om de laatste procenten performance uit de pc te persen.

Zelfs de dual core Athlon 64 X2 4800+ heeft nauwelijk baat bij sneller geheugen

Reacties (14)

[Kaaswagen]

"in de winst slechts enkele procenten"

Naast dat het een typo is, lijkt het mij een overbodige zin.

Het lijkt me dat men zoiets niet ontwikkeld om er 10-20% op vooruit te gaan, maar het gaat juist om die enkele procenten.

[familyman]

Hoe kan het nou toch dat het opvoeren van de geheugensnelheid weinig tot geen zin heeft? De processors zijn toch vele malen sneller dan het geheugen.

Als het op de snelweg doorstroomt, rijdt ook mijn auto sneller.

Wat mis ik?

[latka]

Je processor werkt voornamelijk met het cache geheugen, alleen als hier de gegevens niet inzitten wordt er naar het geheugen gegaan. Tevens vind er prefetching plaats die ervoor zorg dat er meer data (namelijk het gevraagde adres en een aantal opvolgende) alvast in de cache zitten. Als de processor 1 instructie uitvoert die iets langer duurt, dan kan de cache makkelijk gevuld worden. Alleen als de processor een 'if-then' statement tegenkomt zal het kunnen zijn dat de data niet in de cache zit (en met branche-prediction is die kans ook nog vrij klein). M.a.w. het is niet zo dat een 30% overclock op het geheugen 30% extra winst brengt. Je vergelijking met een auto op de weg loopt dus mank omdat je auto geen caching heeft:-)

[Countess]

bij de vergelijking miss je om zeg lucht weerstand.

je moter (cpu) meer toeren (mhz) laten lopen zorgt ervoor dat je sneller gaat.
maar dat gaat niet 1 op 1 omhoog. 10% meer toeren is niet 10% meer snelheid. dit komt voornamlijk door (lucht)weerstand.

als je de auto makelijker door de lucht (data) laat gaan (verlaag de luchweerstand door stroomlijnen) ga je ook een beetje sneller zonder het toerental te verhogen.
dat gebeurt hier ook met het geheugen. meer geheugen bandbreedte zocht ervoor dat de cpu wat minder "weerstand" heeft.

[Luud]

[Tikkie off topic]

Je verhaal is goed bedoeld maar klopt niet.

Aangezien de overbrenging van motor naar wielen vast is, is een verandering van toerental direct gerelateerd aan een verandering van snelheid (aangenomen dat we niet tussentijds schakelen)

Verander je voorbeeld door niet het toerental maar de hoeveelheid brandstof te nemen en het klopt al een stuk beter.

[Arieke]

ik moet ni persee op een snelweg te zijn. Sommige wegen zijn ook goed.

[SG]

van 2,8 naar 3ghz geeft 7% bruto performance winst ceiling.

In games 'n magere 3 á 4 % in doomIII How rekening mee dat dit netto winst is door die dividers door mem iets te verhogen. Die 200Mhz zal +/-5% brenggen.

Dus die mem dividers brengen 'n winstje wat je met 'n 100 a 150hz speed bump maakt alleen op de snelste cores dit zal afzwakken naar lagere klokken.

Dit is interesant voor OC'er's.
OC'en maakt het geheel wat meer bandbreedte hongerig. OC'mem hald daar dus mee rrendement uit.


X2 4400+ met WC en dan OC mem

[Heezy]

Zou iemand me kunnen uitleggen waarom AMD niet veel gebruik maakt van extra bandbreedte, en Intel CPU's wel aub? Ik weet dat Intel cpu's een lange smalle pipeline hebben, en AMD een korte dikke. Maar Intel heeft toch over het algemeen meer cache dan AMD.

Iemand die me zou kunnen helpen?

[Countess]

omdat intel die lange pipeline heeft hebben ze er veel last van als iets niet in de cache gevonden kan worden als het nodig is (de hele pipeline moet leeg en ze moeten opnieuwe beginnen, wat dus een ramp is met de lange pipeline)

om er voor te zorgen dat dit zo min mogenlijk voor komt past intel (en AMD) branch predictions en prefetching too.
de CPU gaat dus proberen te voorspellen welke data hij nodig zal zijn voor de bewerking waar hij nu me bezig zijn, en zelfs de bewerking die hij verwacht straks uit te gaan voeren.

omdat intel hiermee een stuk agressief moet zijn als AMD (vanwegen de lange pipeline) haalt intel veel sneller dingen uit het geheugen die ze denken misschien nodig to gaan hebben.
dat heeft tot gevolg dat intel veel meer dingen uit het geheugen haalt die later helemaal niet nodig bleken te zijn.
daarom heeft intel veel meer geheugen bandbreedte nodig om het zelfde te doen als een AMD CPU.

[Heezy]

Bedankt voor de mooie uitleg.

[Bubbles]

Was dit niet eigenlijk al gewoon 'common knowledge'?

Ik bedoel, leuk hoor dat je sneller geheugen kunt inprikken en dat het op die snelheid ook netejes kan lopen, zonder dat je andere zooi zit te overklokken, maar het was al veel langer bekend dat het weinig tot geen effect leek te hebben. Dit was al het geval in de tijd van 100-133 MHz SDRAM, waar de FSB op 100 MHz stond en het geheugen op 133. Zelfde verhaal bij de overstap van 133-166 en de chipsets voor de AthlonXP die 200 MHz voor geheugen ondersteunden, terwijl de FSB nog op 166 MHz bleef hangen.

Het verleden heeft allang aangetoond dat een a-synchrone geheugensnelheid t.o.v. FSB amper meerwaarde heeft.

[Gogar]

Het verleden is voorbij. In de tijd van de 100-133MHz SDRAM had je nog een FSB, en die was dus de bottleneck. Bij de A64 zit het geheugen direct aangesloten op de processor en is de FSB niets meer dan een getalletje geworden.

[Skyline GT-R]

De nieuwe geheugendividers zijn wel een goede kans voor de computerenthousiastelingen om de laatste procenten performance uit de pc te persen.

Dat denk ik niet omdat je de MP van de Athlon kan verlagen laat iedereen zijn geheugen 1:1 lopen met de HTT bus, en ik denk niet dat er zoveel geheugenmodus zijn die nog kunnen volgen in de DDR533 modus bij een beetje overklokken...

[Gogar]

Ik heb vannochtend al de A64 OC Optimizer aangepast om de nieuwe dividers te gebruiken. Ze staan nu ook op de divider tablel zodat je makkelijk kunt zien wat de exacte geheugen snelheid is bij elke multiplier en divider
linkjes:
http://math.gogar.com/athlon64.cgi
http://math.gogar.com/athlon64.cgi?showtable=1