Benchmarks met dual channel DDR @ HardOCP

Bijna een maand voordat de nieuwe dual channel DDR chipset Granite Bay van Intel aangekondigd wordt, heeft HardOCP het voor elkaar gekregen om dit nieuwe speeltje te benchen. Het gaat natuurlijk om een pré-productie model, maar de resultaten zijn desalniettemin indrukwekkend te noemen. In sommige scores wordt de huidige high-end oplossing met PC1066 RDRAM zelfs met 30% verslagen. Kyle 'FrgMstr' Bennett van HardOCP heeft de resultaten op zijn forum gezet, nadat een artikel op de frontpage op verzoek van een 'vendor' verwijderd was. The Inquirer vraagt zich af hoe lang Intel het nog volhoudt om Rambus als high-end geheugen aan te raden:

The numbers are so high in fact that they're getting on for 30% above the scores seen from top-end 32-bit PC1066 systems, which makes us wonder how much longer Intel will recommend RAMBUS for the top-tier, once the new chipset sees light of day.

Reacties (67)

[Anoniem: 45216]

Ik denk dat AMD nu heeel erg snel actie moet gaan ondernemen, en de manier waarop het geheugen aangesproken wordt grondig gaat herzien. Dat gaat ook gebeuren met de Hammer, maar die is gewoon minstens een half jaar verwijderd van een release. Intel hoeft alleen een nieuwe chipset uit te brengen...

[-=bas=-]

Geheugen transfers zijn ook niet alles!

Een CPU moet goed zijn op alle fronten, dan merk je pas echt een performance verbetering.
Een Porsche met vierkante wielen gaat ook niet hard

[Anoniem: 63569]

Inderdaad, geheugentransfers zijn niet alles.
Een hoop cache, hoge kloksnelheid en goeie streaming instructionsets helpen ook een hoop.

Kortom, AMD komt tekort op de P4 op alle fronten.

(Nee dit is geen trolling, dit is harde werkelijkheid. P4 is een generatie verder dan de Athlon... Hammer maakt dit misschien weer goed)

[Cheetah]

Inderdaad, geheugentransfers zijn niet alles.
Een hoop cache, hoge kloksnelheid en goeie streaming instructionsets helpen ook een hoop.

Hoge kloksnelheden dus niet perse. Dit is de zogenoemde MHz mythe waar Intel ons maar al te graag in doet geloven. AMD Athlons hebben een hogere IPC dan Intel P4 processors, waardoor ze op veel minder hoge kloksnelheden alsnog "veel snellere" P4's kunnen bijhouden.

Ik zou hier dus eerder processorarchitectuur dan kloksnelheid neerzetten, en ik durf te betwijfelen dat de processorarchitectuur van de recentere Athlons echt veel achterloopt op die van de P4's. Het is een andere architectuur, maar daarom nog niet slechter...

Veel cache maakt ook niet altijd veel verschil. Dit is sterk afhankelijk van:
1. (Opnieuw) de gebruikte processorarchitectuur
2. Het type cache dat je verwerkt (L1, L2 ...)
3. Het soort software dat gebruikt wordt

Wat betreft de geheugentransfers: Er zijn momenteel ook Dual Channel DDR chipsets voor AMD in ontwikkeling. nVidea is zelfs al een heel eind met hun nForce2 chipset, waarvan een pre-productiemodel zelfs enkele weken voor deze Intel chipset is "uitgeprobeerd"

En tussen haakjes: een opmerking als "AMD komt tekort op de P4 op alle fronten" is wel degelijk een troll

[Anoniem: 63569]

Nee, dit is meer de 'anti-MHz' mythe van AMD.
Bij CPUs is het inderdaad zo dat meer MHz niet direct meer performance meer betekent. Dit heeft te maken met de enorm hoge snelheden die daar bereikt worden, en de complexiteit van het ontwerp.
Doordat de gates nog steeds ongeveer dezelfde minimale tijd nodig hebben om te settlen, kun je minder gates per stage gebruiken, en heb je meer stages nodig op hogere kloksnelheden.
Dit introduceert extra latency. De throughput wordt echter niet aangetast.
Kortom, in SOMMIGE gevallen is de IPC relatief minder, in andere gevallen kan ie hetzelfde zijn, zo niet beter, dat ligt aan allerlei omstandigheden.
(Test bijvoorbeeld eens SSE2 code op een P4 tegen SSE of x87 code op een Athlon, dan wint de P4 gemakkelijk, op dezelfde kloksnelheid).

Maar we hadden het hier niet over de CPU, we hadden het hier over geheugen, cache en FSB... Daar gaat nog wel de regel op van 'Meer MHz is beter'.
En daar doelde ik dus op.

Verder is de processorarchitectuur van de Athlon in feite niet of nauwelijks veranderd sinds de introductie.
Het grootste verschil is de toevoeging van SSE geweest. Verder zijn er alleen kleine wijzigingen gemaakt aan dingen als cache, FSB, en kleine optimalisaties aan het ontwerp.
Het blijft dus nog steeds een soort van PIII-generatie CPU.

Verder heb je niets aan dual-channel DDR op een Athlon, zolang de FSB niet (minstens) twee keer zo snel wordt als ie nu is Sneller geheugen heeft geen nut als je CPU de bottleneck is, dat probleem hadden we al bij DDR333 en DDR400 oplossingen. Bij nForce is de extra bandbreedte bedoeld voor de onboard GPU.

En een troll is iets wat niet onderbouwd is, of gewoon overtrokken.
Dit was een feit. Ik ben verder niet tegen AMD (ik gebruik zelfs een XP1800+ thuis ), maar feit is wel dat Intel een stuk voor ligt met FSB, chipsets etc, op het moment. AMD heeft nog steeds die PIII-concurrent uit 1999. Maar dat weten ze zelf ook wel, want Hammer is onderweg. Mijn punt is dus dat ie er nog niet IS.

[CARman]

Als reactie op Scali :

Maar we hadden het hier niet over de CPU, we hadden het hier over geheugen, cache en FSB... Daar gaat nog wel de regel op van 'Meer MHz is beter'.
En daar doelde ik dus op.

Natuurlijk gaat voor het geheugen ook hetzelfde op. Kijk maar es naar het verschil in de bovenstaande benchmark. Het RDRAM geheugenin de benchmark loopt op 800 MHz en alle DDR SDRAM concurenten draaien op een veel lagere snelheid. Nou kan ik hier niet helemaal uithalen wat de testsetups zijn ( en het artikel is inmiddels verwijdered ), maar neem es gewoon de onderste PC2700 DDR tegen PC800 RDRAM, hier zijn de verschillen al minimaal terwijl er toch 133MHz in clockverschil in zit. Gaan we kijken naar PC2700 op de SiS 645DX chipset dan is datzelfde lager geclockte PC2700 al sneller ..........

Uiteindelijk is dit

The numbers are so high in fact that they're getting on for 30% above the scores seen from top-end 32-bit PC1066 systems

het resultaat. Wat duidelijk aantoont dat ook bij geheugen het MHz verhaal niet op gaat.

edit:

Nu is het dus niet alleen de frequentie, maar ook de busbreedte. En zo kun je nog wel -tig oorzaken aanhalen. Het ging me nou net ff om de opmerking 'Meer MHz is beter'. Die is onzinnig en raakt kant nog wal. Er zijn veel meer factoren. En dat de P4 juist door hun hoge frequentie en lange pipilines een waanzinnige behoeft aan geheugenbandbreedte hebben was vorig jaar ook al bekend. Ofwel de P4 was zijn tijd vooruit en kan nu pas een beetje echt aan het werk, omdat nu pas te technologie zo ver is om aan de geheugenbandbreedte van de P4 te voldoen. En die geavanceerdere instructies hebben helemaal nix te maken het de snelheid van het geheugen of van de CPU. Want een machine in is multimedia met MMX ook sneller dan 1 zonder op hetzelfde platform.

[Anoniem: 35845]

De efficientie waarmee het geheugen gebruikt kan worden is onafhankelijk van de snelheid van de processor of de grootte van de caches of de snelheid van de FSB. Dit is puur afhankelijk van de geheugencontroller in de chipset (of straks bij hammer : in de CPU zelf).

Het gaat er dus om of een chipset ook daadwerkelijk de maximale bandbreedte van het geheugen kan gebruiken. Bij DDR333 is dat 2700MB/sec als theoretische limiet. Nou zal je dat in de praktijk nooit halen i.v.m. overhead.

De praktische bandbreedte van het geheugen gaat dan ook niet omhoog als je een snellere proc in je PC propt. Of eentje met meer cache geheugen. Wel als je een moederboard met een andere (betere) chipset erin stopt.

Wat jij bedoelt is dat de PIV processor ook daadwerklijk nut heeft van hogere geheugenbandbreedte. De Athlon niet. En dat vind jij een voordeel voor de PIV? Dus dat de Itanium2 daadwerkelijk nut heeft van je 550W voeding (lees : een 550W voeding nodig heeft i.v.m. het enorme stroomverbruik) is een pluspunt voor de Itanium2?

De PIV heeft gewoon een veel grotere geheugenbandbreedte nodig dan de Athlon om behoorlijk te kunnen presteren. Dat vind ik persoonlijk geen pluspunt maar een minpunt. Net zoals ik hoger stroomverbruik niet positief vind, vind ik hoger bandbreedtegebruik ook niet positief zolang dat geen verbeteringen in de prestaties tot gevolg heeft (net als bij stroomgebruik dus). En om een PIV op hetzelfde niveau te laten presteren als een Athlon heeft een PIV
- hogere kloksnelheid nodig
- hogere geheugen bandbreedte nodig

Dat is opzich helemaal niet zo'n probleem overigens, maar de hogere bandbreedte vereiste is wel weer een extra kostenpost om rekening mee te houden.
Tja, als je echt het beste van het beste wilt ben je gewoon veel geld kwijt

edit:
reactie op Carman

Meer Mhz is wel beter als je twee zaken vergelijkt die voor de rest hetzelfde zijn (PIV 2.26 -> PIV 2.8). Zolang de performance van dat element dan ook maar de bottleneck is natuurlijk...
Zit de bottleneck ergens anders, of vergelijk je dingen die niet allen qua aantal Mhz verschillen, dan is alleen de snelheid van het object in Mhz geen relevante indicatie voor de performance ervan.

[Anoniem: 35845]

sorry Scali, maar OF je hebt mijn post niet gelezen OF je WILT het gewoon niet begrijpen...

Dat een AMD niet meer bandbreedte kan benutten heeft op zich NIETS te maken met de efficientie waarmee het geheugen benaderd/aangestuurd wordt.

Efficientie kun je ook wel definieren als (praktisch beschikbare bandbreedte / theoretische bandbreedte)
, de Sis645DX kan dus effectief 95.5% van de door PC333 aangeboden bandbreedte gebruiken (met CAS2).

Dat een athlon niet alle praktisch beschikbare bandbreedte zal benutten heeft dus niks met de efficiency van het geheugen te maken.

Verder is je verhaal over caches m.b.t. het hoofdgeheugen niet zo relevent, associativity/write back policies hebben invloed op de praktische bandbreedte van het cache geheugen, niet op die van het main memory.

En dat een PIV meer bandbreedte nodig heeft om te presteren is dus GEEN fabeltje : hang een PIV maar eens in een SDRAM config, dan kom je daar nog wel achter. Een PIV heeft meer geheugenbandbreedte nodig omdat een PIV voor het uitvoeren van b.v. 1M instructies meer data uit het geheugen moet halen dan een athlon. Dit o.a. omdat de PIV meer pipeline stages heeft, wat in het geval van een branch-misprediction betekent dat er veel meer data overnieuw opgehaald moet worden. Eventuele vergroting van het cache geheugen (L1,L2) zorgt ervoor dat de main memory bus minder gestresst wordt, omdat deze data dan uit het cache komt, i.p.v. uit het main memory gehaald moet worden. Dat zorgt er dus voor dat een processor minder praktische geheugenbandbreedte nodig heeft voor hetzelfde aantal instructies.

Ik durf dus te betwisten dat mijn conclusie dat de PIV meer bandbreedte nodig heeft 'vaag' zou zijn, dat is gewoon een feit.

SSE2 heeft om diezelfde reden dus GEEN invloed op de prestaties van het geheugen, allen op de bandbreedte-honger van de CPU zelf. Met SSE2 werkt een CPU intern zo efficient, dat ie de main memory bus veel sneller verzadigd. Hij heeft dus meer bandbreedte nodig. Jij doet het lijken of SSE2 meer bandbreedte genereerd. Dat is dus gewoon klinkklare onzin. SSE2 heeft optimalisaties voor geheugenbenadering omdat de benodigde bandbreedte anders nooit leverbaar zou zijn. Deze optimalisaties reduceren dus de benodigde bandbreedte, en vermeerderen NIET de beschikbare bandbreedte!

[Anoniem: 63569]

Aan de andere kant is het gebruikte RDRAM maar 16 bits, dus wat is je punt?
Behalve dat vergelijken een beetje lastig is omdat het zulke uiteenlopende technologieen zijn.

Ik had het er meer over dat DDR-geheugen (en zeker Dual-DDR) op een P4 veel efficienter gebruikt kan worden (en de benchmarks tonen dat aan) dan op een Athlon, door de betere chipsets, hogere FSB, meer en snellere cache, meer geavanceerde instructies, en de hogere kloksnelheid van de CPU zelf.

[Anoniem: 63569]

Nee, je leest niet goed.
AMD heeft maar een bus van 266 MHz tussen de CPU en chipset.
Meer dan DDR266 kun je dus niet benutten.

Verder heeft de CPU zeker wel met de efficiency van het geheugen te maken...
Hoeveel cache heeft ie? Hoe groot is een cacheline? Hoeveel cachelines heeft ie? Hoeveel prefetcht ie per keer? Is de policy set-associative, en zo ja, hoe groot is een set? Hoe is de write-back policy?
Chipset is in feite van ondergeschikt belang, op de kloksnelheid na. Het meeste hangt af van de CPU.

Verder is dat "Een P4 heeft meer geheugenbandbreedte nodig om te presteren" een beetje een fabeltje.
Als een P4 sneller 100 mb kan lezen dan een Athlon, dan is ie nou eenmaal sneller als er 100 mb gelezen moet worden.
Sommige programma's gebruiken die bandbreedte niet, dan heb je er niks aan... Maar je hebt het tenminste wel, wanneer het nodig is.
Benchmarks hangen van een hoop andere dingen af dan bandbreedte alleen, dus vergelijken met een Athlon gaat niet zo eenvoudig, en dit soort vage 'conclusies' kun je met andere benchmarks zo weerleggen.
Feit is dat de P4 een nieuwe CPU is die om een nieuwe aanpak vraagt om hem optimaal te benutten. Athlon daarentegen werkt bijna optimaal met huidige software, omdat het al een gedateerd ontwerp is.
P4 zal alleen maar beter gaan presteren naarmate de software meer aangepast wordt. LightWave is daar al een leuk voorbeeld van.

Verder heeft SSE2 WEL invloed op de prestaties van het geheugen, het zijn STREAMING SIMD Instructions...
Voor stream-processing, en jawel, een stream zit in het geheugen.
SSE had ook al dingen als movaps enzo om het geheugenaccess te optimaliseren (alleen aligned dqwords lezen/schrijven), en movntq voor write-through.

[CARman]

Kijk nou es goed wat je hier zelf neer zet.

Omdat de P4 sneller 100 Mb kan lezen is ie ook sneller. De P4 en bandbreedte een fabeltje ............

Toen de P4 op de markt kwam met RDRAM, was ie de snelste CPU op de markt. Zijn geheugenbanbreedte was het hoogste wat je maar kon bedenken. En TOCH was een AMD TB1400 sneller dan een 1,4 GHz P4 ( en met gelijk geheugen ook nog wel een 1,6 ). Dit weerlegt jou hele verhaal. Tot slot heeft men met dual-channel DDR de bandbreedte nog wat opgeschroeft en de P4 wordt steeds effectiever, dat bandbreedte verhaal is dus toch geen fabeltje ..........................

En natuurlijk zal dezelfde software steeds beter gaan presteren op dezelfde CPU, als je de code optimaliseerd voor bijvoorbeeld SSE2, maar dat heeft dus helemaal niets met clocksnelheid te meken. Tenslotte zal de software op een tragere CPU met SSE2 ook sneller lopen. Dat is gewoon effectiever gebruik maken van da hardware.

[Jan de Olde]

P4 zal alleen maar beter gaan presteren naarmate de software meer aangepast wordt. LightWave is daar al een leuk voorbeeld van.

Lightwave is inderdaad een goed voorbeeld van wat er kan gebeuren als je software optimaliseerd voor een processor. Alleen niet een eerlijke vergelijking want dan zou je ook moeten kijken naar een Lightwave die is geoptimaliseerd voor een Athlon XP.

Zo achterhaald als jij doet voorkomen is de Athlon nou ook weer niet. Ook al is het een vorige generatie. Het is een feit dat AMD wat achterop aan het raken is met de topmodellen, maar dat heeft eerder met productieproblemen te maken dan een achterhaalde core. Ondanks al die indrukwekkende P4 specs is een XP op gelijke mhz'en nog altijd sneller...

[Anoniem: 63569]

LightWave is ook geoptimaliseerd voor SSE, dus ook indirect voor Athlon XP.
SSE2 is gewoon een stuk sneller, klaar.
En P4 is dus sneller als je het gebruikt, klaar.
En steeds meer programma's zullen het gaan gebruiken, klaar.

Verder vind ik een Athlon zeker wel achterhaald, toen ie uitkwam in 1999 was het al niet veel beter dan de PIII die in feite nog op de PPRO uit 1995 gebaseerd is.
En er is in die 3 jaar niet veel veranderd. SSE is de enige noemenswaardige verbetering.

Verder is het punt niet dat een Athlon XP op gelijke MHzen sneller is dan een P4, danwel dat de P4 veel makkelijker op veel hogere kloksnelheden te fabriceren is.
De PMMX was in veel gevallen ook sneller dan een PII op gelijke kloksnelheden (wegens kortere pipeline -> lagere latency, beetje hetzelfde verhaal als Athlon vs P4 nu), maar wat boeit dat als de snelste PMMX 233 MHz is, en een PII op 450 MHz loopt? PII is uiteindelijk toch wel sneller.
Zo is het met P4 ook. Athlon XP gaat nooit de 3 GHz halen, P4 is er al voorbij (engineering samples al ver over de 3 GHz, als het goed is, 3 GHz volgende maand in de winkels).
P4 is gewoon ontworpen voor extreem hoge kloksnelheden en hoge geheugenbandbreedte, en Athlon niet, en dat maakt het verschil.

[CARman]

Kijk, ik snap precies wat je bedoeld, en ik ben het tot op zekere hoogte ook met je eens. Maar op een aantal punten sla je de plank in mijn ogen mis hoor.

Als ik bandbreedte nodig heb, is de P4 gewoon altijd sneller...

Maar aangezien de P4 veel langere pipelines heeft dan een Athlon is er bij 1 misprediction al heel wat geheugenbandbreedte extra nodig om de nieuwe instructie weer een beetje vlot in de CPU te krijgen ( ondertussen staat wel de hele CPU op die instructie te wachten ). Door de kortere pipelines van de Athon is de CPU core misschien wel trager ( kwa clock ) , maar de effectiviteit is weer beduidend beter. Bovendien heeft een Athlon misschien maar de helf van de tijd nodig om de nieuwe instructie te krijgen als bij de P4. Daarom heeft de P4 een veel grotere honger naar geheugenbandbreedte dan een Athlon. En dat is nou net datgene dat de real-life performance nogal beïnvloed. Jou verhaal over de snellere P4 bij hoge bandbreedte gaat dus alleen in theorie op bij een 100% correcte prediction. En als programmeur moet jij weten dat 100% bepaald geen werkelijkheid is. Als dat namelijk zo was, dan zou het hele MHz verhaal inderdaad wel op gaan.

Dus juist om foute instructie te corrigeren heeft de P4 veel meer bandbreedte nodig om de core effectief met instructies te bestoken.

Als je trouwens software voor 3Dnow gaat optimaliseren zul je zien dat het omgekeerde van SSE2 ook voor de Athlon op gaat. Dus dat heeft vrij weinig met het geheugen te maken.

[Anoniem: 63569]

Een PIV heeft meer geheugenbandbreedte nodig omdat een PIV voor het uitvoeren van b.v. 1M instructies meer data uit het geheugen moet halen dan een athlon. Dit o.a. omdat de PIV meer pipeline stages heeft, wat in het geval van een branch-misprediction betekent dat er veel meer data overnieuw opgehaald moet worden.

Dit is ook weer onzin trouwens.
P4 gebruikt geen x86 codecache meer, maar cachet de micro-ops. Dat betekent dat je zelfs MINDER stages nodig hebt bij een branch-prediction zolang de code maar in cache is, want dan is het al gedecodeerd, en hoeft het alleen nog maar door de laatste paar execute-stages.
Verder is de branch-prediction verbeterd, dus zal een P4 minder misses hebben dan een Athlon.
En je gaat nooit 1M instructies uitvoeren, 90% van de tijd zit in 10% van de code -> de meeste tijd breng je in loops door, die zijn al gecachet na de eerste run.

[Anoniem: 35845]

Reactie op scali :

Ten eerste zou ik het plezierig vinden als je duidelijk maakt op wie je reageert :

Je quote me niet goed.

Ik heb jou niet gequote, en dat lijkt nu wel zo. Ik snap best wel hoe het zit, maar om nou te zeggen dat het
er allemaal duidelijker op wordt... nee dus.

Kijk, ik ben programmeur, en ik weet waar ik over praat

Ik ook. Hebben we dan allebei per defenitie gelijk?

Maarja, de meeste mensen hier hebben er niet echt verstand van, en begrijpen alleen die one-liners als "P4 heeft meer MHz en bandbreedte nodig dan een Athlon"... Ja, in de praktijk is dat vaak zo, maar zeker niet altijd, en wie weet er hoe en waarom?

Ik geloof dat ik in een vorige post reeds redelijk heb aangegeven hoe en waarom.
Vaak maar zeker niet altijd.... hoe vaak? Ik doe hier een voorzichtige schatting : 90%. Alleen SSE2 blaast alles weg.
Daar staat dan ook tegenover dat de classic FPU van de PIV echt HEEL ERG bedroevend is en deze ook op ALU gebied
in de Athlon zijn meerdere moet erkennen. Denk aan de barrel-shifting functie die de PIV mist, waardoor
ALLE voor PIII/Athlon geoptimaliseerde software enorm traag wordt met integer verminigvuldigingen.

Verder heb ik nergens een link gelegd tussen SSE2 en kloksnelheid. Ik heb alleen gezegd dat SSE2 een P4 beter kan laten presteren dan een Athlon op dezelfde kloksnelheid, en daar heeft de P4 dus een streepje voor.

Inderdaad. Als software SSE2 ondersteunt is een PIV ALTIJD sneller, zelfs met SDRAM, zelfs op dezelfde clocksnelheid.
Helaas is veel software dat niet, en ook LANG niet alle software die nu gemaakt wordt is dit. MSVC6/7 poepen zelfs
code uit die echt BEDROEVEND presteert op de PIV.

Verder vind ik een Athlon zeker wel achterhaald, toen ie uitkwam in 1999 was het al niet veel beter dan de PIII die in feite nog op de PPRO uit 1995 gebaseerd is.
En er is in die 3 jaar niet veel veranderd. SSE is de enige noemenswaardige verbetering.

Designtechnisch vind ik de Athlon VERUIT superieur aan de PIV. Dit in verband met de ogenschijnlijk 'stomme' bottlenecks die in de PIV zitten.
Zo kan een PIV maar 3 instructies/clock naar zn pipelines dispatchen, terwijl allen zn double-pumped ALU's er al 4 kunnen verwerken.
Ook is de l1 cache van de PIV gewoon te klein voor zo'n CPU.

Dat een athlon niet alle praktisch beschikbare bandbreedte zal benutten heeft dus niks met de efficiency van het geheugen te maken.

Wat is dit nu voor onzin? Geheugen heeft geen efficiency... Dat lees je gewoon, klaar.
Het gaat om het totale systeem. Hoe spreekt de CPU/chipset het geheugen aan? Hoe snel is de bus tussen CPU en geheugen?
En over de efficiency van dat subsystem hadden we het dus.

Het gaat hier om de efficiency van de geheugencontroller natuurlijk... (stom dat ik dat niet vermeld)
En die is dus wel degelijk belangrijk. Anders zou de chipset toch ook niet uitmaken voor je geheugenbandbreedte?
De CPU spreekt geheugen overigens niet direct aan. Dat doet dus de geheugen controller (in de chipset)

Verder is je verhaal over caches m.b.t. het hoofdgeheugen niet zo relevent, associativity/write back policies hebben invloed op de praktische bandbreedte van het cache geheugen, niet op die van het main memory.

Fout dus, cache leest uit mainmem en schrijft naar mainmem. Daar heeft het invloed op.
De manier waarop dat gebeurt, is heel belangrijk, namelijk voor burst-access naar het geheugen.

Maar goed, als je niet weet waar je over praat, dan geeft dat niet hoor. Dat heerst hier.

OK. Ten eerste : cache geheugen leest zelf NIKS!
De memory controller in de chipset regelt het zo dat als de CPU een 64bits datawoord opvraagt, de volgende 64bits datawoorden ook op worden gehaald en naar de cache van de processor worden gestuurd (cache line fill heet dat)
Het enige wat lees/schrijf operaties uitvoert zijn de controllers (main memory controller in chipset, cache memory controller in CPU)
Jouw burst-accesses zijn dus voor een deel automatisch in de access-strategy van de main memory controller
Een programma kan hier natuurlijk ook voor geoptimaliseerd zijn. Daardoor vermindert dan de latency van de reads.
En om mij nou maar gelijk te beschuldigen dat ik niet weet waarover ik praat : dat heb ik wel meer als mensen een discussie niet kunnen 'winnen'.
Een domme dooddoener dus, die helemaal niet nodig is en je post eigenlijk tot flamebait diskwalificeert.

Jij doet het lijken of SSE2 meer bandbreedte genereerd. Dat is dus gewoon klinkklare onzin. SSE2 heeft optimalisaties voor geheugenbenadering omdat de benodigde bandbreedte anders nooit leverbaar zou zijn.

Spreek je jezelf hier nu niet keihard tegen?

Nee. Niet geoptimaliseerde geheugenaccess vergroot de benodigde memory bandbreedte. Dat is dus NIET HETZELFDE ALS dat geoptimaliseerde access de geleverde bandbreedte verhoogt!
Als een CPU uit zn cache leest, doet ie dat met veel meer dan 2.7GB/sec. Is de bandbreedte van het geheugen dan ineens >2,7GB? Tuurlijk niet.
Hij heeft de hele bandbreedte van het geheugen dan niet eens NODIG. Dat wordt namelijk gewoon uberhaupt niet aangesproken.
DAT is wat ik zeg (en in vorige posts al eerder gezegd heb, maar daar trek jij je geloof ik niet zo
erg veel van aan).

Zie het maar zo : als ik belastingkorting krijg, betaal ik minder belasting, en is mijn netto-inkomen groter.
Daar wordt mijn bruto inkomen dus NIET hoger door!
Vervang nu belasting door optimalisatie, netto inkomen door "netto bandbreedte" en bruto inkomen door "praktische geheugenbandbreedte"
benodigde bandbreedte kan je splitsen in "netto bandbreedte" en "verspilling"
Door minder verspilling toe te passen daalt bij gelijkblijvende netto bandbreedte de benodigde bandbreedte. Simpel toch?

Voor programmeurs is het al jaren duidelijk dat handig gebruik van MMX/SSE/SSE2 extensies voor prefetch, write-through, aligned read/write de enige manier is om de geheugeninterface daadwerkelijk optimaal te benutten.

Voor programmeurs is het al jaren duidelijk dat optimalisatie op DIT niveau door de compiler dient te gebeuren!

Ook snijdt jouw argument dat de PIV code cache uit micro ops bestaat geen hout. De data waarop ik bewerkingen wil gaan uitvoeren zou bij een branch-miss ook wel eens ergens anders vandaan moeten kunnen komen.
Dat kost dus bandbreedte.
En als die hele caches zo weinig uit zouden mogen maken i.v.m. loops zoals jij stelt, waarom SPRONG de performance van de PIV dan
vooruit door de verdubbeling van de cache? Waarom zou 'ie dan uberhaupt traag zijn met SDRAM?

Dat jij niet begrijpt dat 3DNow geoptimaliseerde code sneller draait op een Athlon als op een PIV snap ik echt niet.
En het punt wat Carman probeert te maken is dus dat met processor specifieke optimalisaties je ALTIJD voordeel boekt.
En dat het dus een beetje een open deur is om te stellen dat voor de PIV geoptimaliseerde software veel sneller is
dan niet voor de Athlon geoptimaliseerde software.
Bovendien is zijn opmerking dat dit niks met geheugenbandbreedte te maken heeft gewoon waar.

Al met al begin ik het vermoeden te krijgen dat we het over nogal verschillende dingen hebben.
Geheugenbandbreedte is, zoals ik al vaker gesteld heb hier, in mijn optiek de praktisch benutbare
bandbreedte tussen main memory controller en in dit geval DDR333.
Het lijkt erop dat jij geheugen bandbreedte als netto-bandbreedte definieert naar de processor.
Die is natuurlijk wel afhankelijk van de access-patterns door de CPU. Wat overigens nog steeds
niet wegneemt dat de PIV in 'klassieke' software meer verspilling veroorzaakt en zodoende meer.

Zo verder wil ik er geen woord meer aan vuil maken. Als je verder wilt discussieren dan graag per mail : [e-mail]
Ik moet bovendien weg

[Madrox]

over clock en mhz :

Pc100 = 100mhz
PC2100 = 133mhz
PC2700 = 166mhz
PC3200 = 200mhz

RDram Pc800 = 400mhz
RDram Pc1066=533mhz

Waar haal je die 133mhz vandaan ?

[Anoniem: 63569]

Dat een athlon niet alle praktisch beschikbare bandbreedte zal benutten heeft dus niks met de efficiency van het geheugen te maken.

Wat is dit nu voor onzin? Geheugen heeft geen efficiency... Dat lees je gewoon, klaar.
Het gaat om het totale systeem. Hoe spreekt de CPU/chipset het geheugen aan? Hoe snel is de bus tussen CPU en geheugen?
En over de efficiency van dat subsystem hadden we het dus.

Verder is je verhaal over caches m.b.t. het hoofdgeheugen niet zo relevent, associativity/write back policies hebben invloed op de praktische bandbreedte van het cache geheugen, niet op die van het main memory.

Fout dus, cache leest uit mainmem en schrijft naar mainmem. Daar heeft het invloed op.
De manier waarop dat gebeurt, is heel belangrijk, namelijk voor burst-access naar het geheugen.

Maar goed, als je niet weet waar je over praat, dan geeft dat niet hoor. Dat heerst hier.

Jij doet het lijken of SSE2 meer bandbreedte genereerd. Dat is dus gewoon klinkklare onzin. SSE2 heeft optimalisaties voor geheugenbenadering omdat de benodigde bandbreedte anders nooit leverbaar zou zijn.

Spreek je jezelf hier nu niet keihard tegen?

Voor programmeurs is het al jaren duidelijk dat handig gebruik van MMX/SSE/SSE2 extensies voor prefetch, write-through, aligned read/write de enige manier is om de geheugeninterface daadwerkelijk optimaal te benutten.

[tikimotel]

PC800 is 100 x Quadbus x Dualchannel = (100 x4 x2)
PC1066 is 133 x Quadbus x Dualchannel = (133 x4 x2)

verdee ik reageerde toch echt op de posting van Alex4you....

[Anoniem: 63569]

Maar aangezien de P4 veel langere pipelines heeft dan een Athlon is er bij 1 misprediction al heel wat geheugenbandbreedte extra nodig om de nieuwe instructie weer een beetje vlot in de CPU te krijgen ( ondertussen staat wel de hele CPU op die instructie te wachten )....

Dat is allemaal leuk en aardig, maar daar hadden we het niet over. We hebben het natuurlijk over DATA, niet CODE.
Code dat echt bandbreedte nodig heeft, is streaming code, en dat zijn loops die geheel in code-cache kunnen, code-cache MAG geen probleem zijn bij goed geschreven code. Branch prediction trouwens ook niet, zeker niet bij P4 waar je ook nog aan een simpele vorm van predication kunt doen.

Nu snap ik waarom je de hele tijd zo raar loopt te brallen, jij denkt dat het om code gaat, het gaat om DATA natuurlijk, duh?

Verder heeft 3dnow! weinig of niks met SSE2 te maken. En ik begrijp niet echt wat voor punt je nou wilt maken. 3dnow! heeft enorme latencies en veel te kleine registers, je kunt op een Athlon in de meeste gevallen ook beter SSE gebruiken omdat dat gewoon sneller is. Heeft verder ook betere instructies voor geheugen/cache-toegang.

[CARman]

Laatste reactie op een pure Intelfan ( sorry dat ik het zo breng, maar het kan echt niet anders zijn dan dat ).

Als alles dat je in de posts hierboven aankaart waar is, moet een Intel P4 op alle punten superieur zijn aan een AMD ( in welke vorm dan ook tot nu toe ). Ik zet hier ff wat quotes van jou zelf neer :

Kortom, AMD komt tekort op de P4 op alle fronten.

Maar nu even over het geheugen :

Maar we hadden het hier niet over de CPU, we hadden het hier over geheugen, cache en FSB... Daar gaat nog wel de regel op van 'Meer MHz is beter'.

Het maakt geen verschil of de geheugenbandbreedte omhoog gaat want dat was niet van belang. Zie vorige quote. Alleen kloksnelheid van het geheugen telt, tenslotte. Pfff, alweer de vorige quote

Laten we het dan es over geheugen hebben.

Aan de andere kant is het gebruikte RDRAM maar 16 bits, dus wat is je punt? Behalve dat vergelijken een beetje lastig is omdat het zulke uiteenlopende technologieen zijn.

OK, de zijn verschillend, dus mag ik ze niet vergelijken. Hmmm, maar dat mag jij wel doen met 2 verschillende instuctiesets ?

Test bijvoorbeeld eens SSE2 code op een P4 tegen SSE of x87 code op een Athlon, dan wint de P4 gemakkelijk, op dezelfde kloksnelheid

Ik weet niet precies wat hier je doel is, maar als ik je posts zo es terug lees staat er een hoop info, waarvan minimaal de helft kant noch wal raakt. De punten en argumenten die je erbij haalt zouden zonder uitzondering aantonen dat een P4 op de helft van een AMD clocksnelheid nog sneller zou moeten zijn. Nou wil het toeval dat ik altijd vrij nieuwsgierig ben in het hoe of wat en waarom. Maar in alle reviews die ik ben tegen gekomen en gelezen heb, komt de superieuriteit van de P4 niet echt naar voren hoor. Hij loopt gewoon harder en je kunt er effectiever gebruik van maken door hem meer geheugenbandbreedte te geven. Vandaar dat ie wel weer een leuke prong in performance gaat maken met deze configuratie.

Tot slot nog een leuke quote van jou mbt geheugenbandbreedte

Als een P4 sneller 100 mb kan lezen dan een Athlon, dan is ie nou eenmaal sneller als er 100 mb gelezen moet worden

Ik dacht dat bandbreedte niet uitmaakte O, nog eentje

Kijk, ik ben programmeur, en ik weet waar ik over praat, als ik bandbreedte nodig heb, is de P4 gewoon altijd sneller... Hij heeft niet meer nodig ofzo... het is niet iets dat je 'verbruikt' om een CPU te laten draaien... Als je het nodig hebt, is het er.

Echt heel vermoeiend .................. pak de applicatie & game benchmarks es bij van die zo voorbij komen op Tweakers en je zult zien dan de P4 niet half zo superieur is als jij hier steeds maar schetst.

[Anoniem: 63569]

Laatste reactie op een pure Intelfan ( sorry dat ik het zo breng, maar het kan echt niet anders zijn dan dat ).

Ik heb toch echt een XP1800+ hoor
Sterker nog, dit is m'n tweede Athlon, ik had eerst een TBird 1400.

Maar omdat ik AMD gebruik, hoef ik nog niet blind te zijn voor alle andere technologieen. Ik probeer objectief te zijn. Wat goed is, is goed, klaar. Bandbreedte is goed (trust me on this one )

Het maakt geen verschil of de geheugenbandbreedte omhoog gaat want dat was niet van belang. Zie vorige quote. Alleen kloksnelheid van het geheugen telt, tenslotte. Pfff, alweer de vorige quote

Geen idee waar je naartoe wilt hiermee. Ik heb niet gezegd dat ALLEEN de kloksnelheid telt. Alleen dat als de kloksnelheid van het geheugen/FSB/cache omhoog gaat, dat dat beter is.

Aan de andere kant is het gebruikte RDRAM maar 16 bits, dus wat is je punt? Behalve dat vergelijken een beetje lastig is omdat het zulke uiteenlopende technologieen zijn. OK, de zijn verschillend, dus mag ik ze niet vergelijken. Hmmm, maar dat mag jij wel doen met 2 verschillende instuctiesets ?

Je mag best vergelijken, maar dan wel op een zinnige manier... Dualchannel bij Rambus heeft een andere betekenis dan Dualchannel bij DDR... DDR was namelijk al 32 bits, Rambus maar 16. Dus in feite zijn dualchannel Rambus en singlechannel DDR vergelijkbaar.

En die instructiesets... ja, AMD heeft het aan zichzelf te wijten dat ze nog steeds geen support voor SSE2 hebben. Ik vind dat als je 2 gelijkwaardige CPUs hebt (beide x86, beide zelfde prijsklasse), en de 1 biedt extra instructies die sneller zijn, dat je die best mag gebruiken in een vergelijking. Ze zitten er toch op?

De punten en argumenten die je erbij haalt zouden zonder uitzondering aantonen dat een P4 op de helft van een AMD clocksnelheid nog sneller zou moeten zijn.

Dat is sterk overdreven, dat heb ik helemaal niet gezegd. Kennelijk lees je met een AMD danwel anti-Intel bril?
Ik wou alleen de standpunten nuanceren... P4 heeft een slechte reputatie, maar de ervaringen die ik ermee heb opgedaan, zijn zeer goed, ik vind dat ie erg veel goede punten heeft. Ik heb nooit beweerd dat ie altijd sneller is dan een Athlon op dezelfde kloksnelheid ofzo... We weten allemaal dat dat niet zo is.
Ik heb alleen gezegd dat in bepaalde gevallen een P4 best superieur aan een Athlon kan zijn. Ja, als je AMD-zealot bent, is dat tegen het zere been natuurlijk, tough.

Maar in alle reviews die ik ben tegen gekomen en gelezen heb, komt de superieuriteit van de P4 niet echt naar voren hoor.

Ja dat is het verschil he... Ik schrijf m'n eigen software, en kan makkelijk wat aanpassinkjes proberen om te kijken hoe een en ander loopt... Die reviews zijn allemaal gebonden aan gedateerde benchmarks die de P4 niet allemaal recht doen. LightWave is al een goed voorbeeld in de juiste richting.
Dat is het soort dingen dat ik zelf ook zie als ik op een P4 programmeer.

Hij loopt gewoon harder

Ja, en dat is nou juist het mooie. Intel heeft een generatie voorsprong op AMD hiermee. Die P4 schaalt heerlijk omhoog. De Athlon zal vroeger of later afhaken in de strijd om de GHzen. Maar goed, dan kan de Hammer het overnemen, we zullen zien wat die ervan bakt.

Als een P4 sneller 100 mb kan lezen dan een Athlon, dan is ie nou eenmaal sneller als er 100 mb gelezen moet worden Ik dacht dat bandbreedte niet uitmaakte?

Hoe kom je daar nou bij? Mijn punt was juist dat het WEL uitmaakte. Wat 1 van de aantrekkelijke punten van de P4 is.

Echt heel vermoeiend .................. pak de applicatie & game benchmarks es bij van die zo voorbij komen op Tweakers en je zult zien dan de P4 niet half zo superieur is als jij hier steeds maar schetst.

Ja, dat zijn dus die verouderde PIII-applicaties, daar heb ik het al over gehad. Ik heb het over de dingen die ik gemaakt heb.
Misschien dat ik nog ergens m'n Boyer-Moore benchmark kan vinden...
Probeer eens scali.scali.eu.org/bmtest2.zip
Was niet eens bedoeld als een P4 benchmark ofzo... (had ik op m'n TBird 1400 geschreven), maar toen we mensen met een P4 lieten testen, kwamen we tot ZEER aangename verassingen... Denk maar wat je wilt. Sourcecode zit erbij als het goed is, gewoon C, geen P4-specifieke optimalisaties of wat dan ook.

[Anoniem: 63569]

Alleen AMD gebruikt Dual pumped busjes en de P4 Quad pumped

Ja en daarom heb je 2 keer zoveel signaaloverdracht bij dezelfde kloksnelheid, dus 2 keer zoveel bandbreedte, simpel he?

(en ook een paar die Intel gewoon goed vinden!)

Ja sommige mensen denken dat er bij Intel alleen maar incompetente mensen rondlopen die alleen maar waardeloze CPUs kunnen ontwerpen ofzo...
Het tegendeel is waar, er is goed nagedacht over de P4, en hoewel hij enorm veel verschilt van de PIII/Athlon-generatie, is het toch een interessante CPU.

[Anoniem: 35845]

Ok, ondanks mijn eerdere toezegging toch nog een korte epiloog op mijn aandeel in de hele discussie :

om te beginnen vind ik het prettig om weer eens een discussie over dit onderwerp te zien die het niveau <INTEL|AMD> <RULES|ZUIGT> ontsteigt.
Gezien de moderaties hebben er meer mensen meegenoten en dat is natuurlijk mooi. Zo hier en daar ging het een beetje offtopic geloof ik maar ik hoop dat iedereen zich daarin kan vinden gezien de situatie. Zo hier en daar had ik toch ook een beetje het idee dat er nog wel eens langs elkaar heen gepraat werd. Laat ik nog maar eens duidelijk stellen : het gaat hier dus in eerste instantie NIET om het vergelijken tussen een PIV en een Athlon. theoretische verhandelingen daarover zijn praktisch gezien oninteressant : gewoon live testen met de software die je wilt gebruiken, dan weet je waar je je geld het beste aan kunt spenderen.

Hoewel mijn voorgaande post dit misschien doet vermoeden ben ik zeker geen intel of PIV hater, ik probeer alleen argumenten te geven die aan de discussie bijdragen (als iedereen de zelfde richting in argumenteert heb je ook geen discussie).

Ik heb een flink aantal intels versleten en ben inmiddels 'aan de Athlon', puur om budgettaire redenen. Als geld geen rol had gespeelt had ik overigens voor een PIV 2.8Ghz gekozen, sneller dan dat is er momenteel gewoon niet op de x86 markt. Punt.

De PIV is een proc met een mooie toekomst en blijft qua performance voorlopig goed doorschalen met kloksnelheid. Het is gewoon een CPU met een interessant concept, waarvan de uitvoering imo op sommige punten beter had gekunt (barrelshifters terug, meer L1 data cache, meer instruction dispatchers), maar Intel heeft nu eenmaal anders besloten (misschien maar goed ook voor AMD ). Daar ik in een groot bedrijf werk met een behoorlijke diversiteit aan werkstations/servers kan je dus rustig zeggen dat ik meer ervaring met Intel procs dan met AMD's heb. En die ervaringen zijn gewoon goed.

[Anoniem: 35845]

scali : als je denkt dat ik die zaken ter plekke even verzin of zo dan heb je het mis. Ik heb heel wat achtergrondartikelen gelezen (ook van designers) over het ontwerp van de PIV. Hoe denk je dan dat ik aan die info kom?

Verder stoort het mij een beetje dat je te pas en te onpas mensen arrogant/dom/onwetend noemt. Alsof jij alle wijsheid in pacht heb zeg, kom nou. Je kan ook discussieren zonder dit soort geflame.

En ten slotte : dacht je nou echt dat er bij intel alleen dingen om technische redenen gedaan worden? Dat de ontwerpers van CPU's het daar voor het zeggen hebben? Kom nou. Die hebben dus geen moer in te brengen. Er worden dus gewoon net als bij alle andere bedrijven concessies gedaan aan technische superioriteit om marketing/economische redenen. Het was dus wel degelijk mogelijk geweest de door mij genoemde puten in het PIV ontwerp te integreren. Of denk je dat Intel met de PIV het summum van al haar mogelijkheden heeft laten zien? Wat dacht je van Itanium/Itanium2? Dat zouden ze wel kunnen en niet het verhogen van de L1 data cache voor de PIV? En waarom kunnen ze dat bij AMD dan wel met de Athlon (128k L1)?

Dat de PIV dan een snelle/grote L2 cache heeft is natuurlijk schitterend, maar L2 cache is er dan ook voornamelijk om L1 cache misses op te vangen. Meer L1 cache is dus ALTIJD beter dan L2 cache, o.a. in verband met bandbreedte- en latencyverschillen. Als ik dus mag kiezen tussen 512k L1 cache en 16K L2 cache of andersom dan weet ik het wel (jij ook trouwens).

En je mail heb ik overigens wel gelezen. Ik lees daarin geen nieuwe argumenten. En zoals ik al eerder heb gemeld vind ik je oude niet in alle gevallen overtuigend.

En je progsel heb ik niet geprobeerd nee. Ik heb hier thuis geen beschikking over een PIV. Maar dat het sneller is op een PIV neem ik voor kennisgeving aan. Een koe is weer veel sneller op een athlon, dus je punt is? Dat de software bepalend is voor je platformkeuze? Heb ik ook al gezegd. Punt.

[Anoniem: 63569]

Reaktie op CARman:

Je quote me niet goed.
Ik zei:

Als een P4 sneller 100 mb kan lezen dan een Athlon, dan is ie nou eenmaal sneller als er 100 mb gelezen moet worden.

Dat is gewoon logisch </cruijff>
Ik had het niet over de CPU zelf, ik had het over een voorbeeld waarin de P4 overduidelijk sneller is.
Als voorbeeld tegen wat er hier vaak beweerd wordt.
Kijk, ik ben programmeur, en ik weet waar ik over praat, als ik bandbreedte nodig heb, is de P4 gewoon altijd sneller... Hij heeft niet meer nodig ofzo... het is niet iets dat je 'verbruikt' om een CPU te laten draaien... Als je het nodig hebt, is het er.
Dat de CPU verder op dezelfde kloksnelheid als een Athlon soms minder presteert, dat is niet afhankelijk van de geheugenbandbreedte an sich... Die kan alleen het verlies van IPC weer een beetje goedmaken, dat is een ander verhaal. Maarja, de meeste mensen hier hebben er niet echt verstand van, en begrijpen alleen die one-liners als "P4 heeft meer MHz en bandbreedte nodig dan een Athlon"... Ja, in de praktijk is dat vaak zo, maar zeker niet altijd, en wie weet er hoe en waarom?

Verder heb ik nergens een link gelegd tussen SSE2 en kloksnelheid. Ik heb alleen gezegd dat SSE2 een P4 beter kan laten presteren dan een Athlon op dezelfde kloksnelheid, en daar heeft de P4 dus een streepje voor.

Je moet mijn post dus zorgvuldiger lezen en quoten als je aanmerkingen wilt maken.

[Anoniem: 25693]

Ehm, ik wil niet moeilijk doen maar op het moment is de FSB van de P4 en de Athlon gelijk. Alleen AMD gebruikt Dual pumped busjes en de P4 Quad pumped. Maar ja, Intel houd nu eenmaal van hoge getallen.

Maar wel een vette discussie man. Goede oprmerkingen van een paar mensen die er echt wat vanaf wisten (en ook een paar die Intel gewoon goed vinden!)

[Anoniem: 63569]

waarvan de uitvoering imo op sommige punten beter had gekunt (barrelshifters terug, meer L1 data cache, meer instruction dispatchers), maar Intel heeft nu eenmaal anders besloten

De beste stuurlui staan aan wal he?
Dacht je dat die Intel-lui incompetent waren? Er zijn goede technische redenen waarom ze het zo gedaan hebben en niet anders.
Kennelijk heb je je mail ook niet gelezen, daarin heb ik uitgelegd dat het aantal instruction dispatchers sowieso al genoeg is in de praktijk... en dat meer dispatches waarschijnlijk niet haalbaar was.
(Let wel, deze CPU moet naar 10 GHz schalen, kun je niet vergeleken met zo'n achterhaald design als van de Athlon).
En om dezelfde reden zit er ook geen barrel shifter in, en zo 'weinig' L1 cache. Het is waarschijnlijk niet haalbaar om dit te fabriceren op hoge kloksnelheden... de die zal te groot worden, en de yield zal te laag worden, of uberhaupt fysiek onmogelijk.
Verder had ik al uitgelegd in mijn mail dat de P4 een hele mooie low-latency L2-cache achter de L1 cache heeft hangen, wat in de praktijk prima werkt, en niet echt onderdoet voor de Athlon met meer L1 cache, maar minder, en slechtere L2 cache.
(heeft iemand dat scali.scali.eu.org/bmtest2.zip geprobeerd? Zul je zien hoe schrikbarend veel beter het P4 cache/memory subsystem is)

Maar goed, als je je mail niet wilt lezen, moet je maar eigenwijs en dom blijven zeuren.

(Leuke moderators hier trouwens... arrogante onzin-posts zoals "Ik zou het beter gedaan hebben dan Intel" worden hoger gewaardeerd dan realistische posts. Laten we wel wezen. Niemand behalve Intel maakt CPUs van 3 GHz en hoger... Voorlopig heeft Intel gelijk... Ik kan ook wel van die onzin zeggen als "Als ik bij AMD werkte, zou ik de CPUs op 10 GHz laten maken", dat kan nu eenmaal niet, er moeten bepaalde keuzes afgewogen worden bij een ontwerp, en het P4 ontwerp is het enige dat op hoge kloksnelheiden gebouwd is. Zolang niemand anders het beter doet dan zij, is het kennelijk ook niet mogelijk. Iedereen wil toch zijn CPUs zo goed mogelijk maken?
Zijn natuurlijk weer van die domme AMD-zealots/anti-Intel eikels. Het gaat om feiten in de echte wereld, mensen)

[Anoniem: 63569]

En ten slotte : dacht je nou echt dat er bij intel alleen dingen om technische redenen gedaan worden? Dat de ontwerpers van CPU's het daar voor het zeggen hebben? Kom nou. Die hebben dus geen moer in te brengen. Er worden dus gewoon net als bij alle andere bedrijven concessies gedaan aan technische superioriteit om marketing/economische redenen.

Ja, Intel maakt met opzet waardeloze processors. Ze willen graag hun marktaandeel en goede naam te grabbel gooien, en failliet gaan. Ik zie wat je bedoelt.

Het was dus wel degelijk mogelijk geweest de door mij genoemde puten in het PIV ontwerp te integreren. Of denk je dat Intel met de PIV het summum van al haar mogelijkheden heeft laten zien? Wat dacht je van Itanium/Itanium2? Dat zouden ze wel kunnen en niet het verhogen van de L1 data cache voor de PIV? En waarom kunnen ze dat bij AMD dan wel met de Athlon (128k L1)?

Een Itanium is nu niet bepaald een x86 (duh?).
Die CPU is juist compleet het tegenovergestelde.
Bij een moderne x86 wordt misschien wel 60-70% van de core ingenomen door de instructie-decoders alleen.
Bij een RISC- danwel EPIC-ontwerp zijn de decoders juist extreem simpel. En dan heb je meer ruimte voor cache enzo ja, heel goed.
Itanium gaat trouwens ook niet op dezelfde extreme kloksnelheden lopen als de P4.
Verder ben je kennelijk blind. Ik heb al meermalen gezegd dat een Athlon een oudere generatie is. Die hoeft niet op 10 GHz te gaan lopen, zoals Intel's plannen met de P4 zijn. Dan heb je een ander soort ontwerp, en dan kun je meer L1-cache erin doen, je hoeft toch geen rekening te gaan houden met problemen boven de pak-m-beet 5 GHz, want daar kom je nooit. Verder heeft de cache van de Athlon sowieso hogere latency, dus wederom een verschil in ontwerp.

Als ik dus mag kiezen tussen 512k L1 cache en 16K L2 cache of andersom dan weet ik het wel (jij ook trouwens).

Dat ligt eraan. Als ik 512k L1 cache kan krijgen in een 1 GHz CPU, of 16k L1 cache in een 5 GHz CPU, geef mij dan die 5 GHz maar, de L2 cache is daar waarschijnlijk ongeveer net zo snel als de L1-cache in de 1 GHz, als je begrijpt waar ik naartoe wil.

En je mail heb ik overigens wel gelezen. Ik lees daarin geen nieuwe argumenten. En zoals ik al eerder heb gemeld vind ik je oude niet in alle gevallen overtuigend.

Eigenwijs, bevooroordeeld, arrogant, wie zal het zeggen?

En je progsel heb ik niet geprobeerd nee. Ik heb hier thuis geen beschikking over een PIV. Maar dat het sneller is op een PIV neem ik voor kennisgeving aan.

Ja, een P4 1.8 GHz met DDR266 was al ongeveer 2x zo snel als een XP1800+ met DDR266.
Dus als je nog vragen had over het superieure P4-cache/memory subsystem?

Een koe is weer veel sneller op een athlon, dus je punt is?

Een x87-code koe bedoel je? Of een specifiek voor Athlon geoptimaliseerde koe?
Wachten is dus op de SSE2-koe dan.

Dat heb ik al meermalen geprobeerd uit te leggen... De meeste benchmarks zijn verouderde PIII-programma's, die doen de P4 nog niet echt recht. Programma's gaan alleen maar beter lopen op de P4.
Bovendien lopen programma's op een P4 sowieso niet slecht. Iets langzamer dan een Athlon soms, ja ach. Om dan daar meteen de hele CPU op af te rekenen, vind ik erg kortzichtig, dus wou ik de goede punten even aanstippen. Maarja, dan heb je dus altijd van die blinde AMD-zealots die moeilijk gaan doen, en het blijkt eigenlijk altijd dat ze slecht geinformeerd zijn, of gewoon niet genoeg verstand van zaken hebben. Word ik een beetje moe van.

[apa]

Ik durf niet zo snel zeggen dat AMD het nu moeilijk gaat krijgen. Niet dat het aan Granite Bay of de P4 zou liggen, maar wel aan de markt. Meer en meer komen geruchten naar voren al zou het niet zo dom zijn om de K8 Hammer wat uit te stellen.

In deze slechte economische tijden spenderen mensen gewoon minder aan hun aankopen. Als AMD de Hammer nu dan zou lanceren, dan zouden ze misschien wel het snelste platform kunnen hebben, maar dan zou het nog niet gegarandeerd goed verkopen. Om het te laten verkopen zou AMD de prijzen laag moeten houden, wat het meteen ook wat minder interessant maakt voor henzelf (er komt minder geld binnen in het laatje).

Het is natuurlijk wel spijtig voor ons, maar ik durf dus niet zo snel te zeggen dat de vertraging helemaal negatief is.

[Cheetah]

De nForce2 chipset voor de Athlon bevat ook een Dual Channel DDR memorycontroller. Daarbij hebben enkele andere Athlon producenten momenteel ook DC DDR chipsets in ontwikkeling, dus met het "voordeel" van Intel op dit gebied zal het zo'n vaart niet lopen...

[TD-er]

Het zou interessanter geweest zijn, wanneer ze ook nog even de scores van de dualchannel Rambus boardjes erbij gezet hebben.

Nietemin een zeer leuke score van 4,5 GB/s

Is de toegangstijd nu ook lager, dan met een singlechannel chipset?
Om het ff te vergelijken met een HDD-RAIDset, daar gaat de toegangstijd ook omlaag, naarmate je meer schijven hebt. (Mijn RAID5-set van 4*5400 rpm schijven, heeft een toegangstijd van een 10000 rpm schijf, 5.3 ms)

[John_Glenn]

Nou, er staat toch een i850 met PC800 bij? Da's dus dualchannel rambus. Je kan vast wel schatten hoe dat zich verhoudt tot PC1066 op de i850 of SiS-chipset.

De toegangstijden worden gemiddeld inderdaad lager, lijkt mij. Aanvragen voor DIMMs op verschillende controllers komen immers niet meer in de rij te staan.

edit: Scali, voor zover ik weet is er alleen 16bit Rambus. Die marketingtrucs van Asus zijn leuk, maar zij hebben echt geen 32bit Rambus. Dat is gewoon dual 16bit in 1 module (dus er zijn wel 2 controllers nodig). De vergelijking is dus ook niet oneerlijk.
Wel had ik ook graag PC1066 willen zien - nu moet ik eerst een andere review ernaast leggen...
Maar Rambus is hierdoor niet dood hoor. Wat iedereen altijd vergeet te vermelden is dat het belangrijkste pluspunt van Rambus de hogere stabiliteit is (gaat dan om storingsgevoeligheid bij minder datapaden). High-end gebruikers vinden dat vast ook met de komst van Granite Bay nog belangrijk.

edit2: dual-dualchannel... als in quad-channel? Wordt denk ik een beetje ingewikkeld chipontwerp. Bovendien is dat niet echt extra zinvol: de bandbreedte van dual-channel RDRAM in synchrone mode komt al overeen met die van de P4 bus.

[Anoniem: 63569]

Dat is dualchannel 16 bit Rambus (Rambus was een seriele interface, weet je nog?)
Beetje oneerlijke vergelijking dus.

Maar ik weet niet of er 'dual-dualchannel' (2x wat ze nu hebben dus) Rambus chips zijn of komen.

Verder maakt dat op zich niet veel uit. PC1066 is nu de top, is dus leuk om in de test mee te nemen, om te zien hoeveel je erop vooruit gaat.

[edit2]
Ik dacht dat hij 2x Rambus wou zien, 2x PC800 ofzo.
PC1066 is inderdaad vergelijkbaar met 2xDDR266, PC800 is oneerlijk dus.
[/edit2]

[silentsnow]

DIt is allemaal wel heel leuk, maar dit is op een snelheid van 188MHz. Ik wil wel eens deze Dual Channel DDR config op standaard snelheid zien draaien. Uiteraard zal deze dan minder goed presteren.

[John_Glenn]

Slordige schatting: theoretisch moet je maximaal zo'n 6GB/s halen met dual DDR376. Hier zie je dus dat er maar driekwart wordt behaald.
Op standaard DDR266 snelheid max iets van 4,2GB/s... dus laten we hopen dat de efficiency dan hoger is (anders gaat de 645DX bijna even hard )!

Maargoed... * 786562 John_Glenn

[silentsnow]

Yep Dat zou dus beteken dat als je de efficientie van 75% (4.5GB/s in praktijk / 6.0GB/s in theorie) die THG haalt gebruikt met een 133MHz FSB je 3.2GB/s. Op 166MHz zou het 4GB/s zijn.

[kerel]

heel interessant de pentium is juist een processor die juist heel erg afhankelijk is van de hoeveelheid vanbreedte van het geheugen, dus ik ben heel benieuwd hoe deze nieuwe combinatie gaat presteren???

[John_Glenn]

Theoretisch moet dit heel gunstig zijn... de p4 bus is soort van een ddr bus met simultane reads en writes (vandaar 'quad pumped'). Nu heb je dus 1 ddr controller waarnaar geschreven kan worden, en tegelijk 1 waarvan gelezen kan worden: optimale aansluiting van de beschikbare busbreedte.

Lekker in synchrone mode met dual PC2100 en 133MHz fsb... en over een tijdje PC2700 en 166MHz...

[Anoniem: 23081]

Rambus blijft een marketinggeheugensoort. Waaauuuw 533MHz met DDR-effect, dus waaauuuw 1066 MHz effectief. Maar men vergeet 16 bit bussmalte, dat betekent minstens MHz/4. Dan heb je maar 266,5 MHz (DDR-SDRAM equivalent), maar Rambussen worden per 2 latjes (dual channel) gebruikt, dus 2*266,5MHz, dan heb je 533MHz (DDR-SDRAM equivalent).

Dus theoretisch is 2 latjes PC1066 Rambus (dual channel) evensnel als de 1 latje 533MHz DDR-SDram (single channel). Maar de latency wordt meestal vergeten, als je daarmee nog rekening houden, dan is het verschil tussen Rambus en DDR klein. Als men 2 latjes DDR-SDRAM (dual channel) gebruikt dan is 2*266MHz theoretisch evensnel als de PC1066. Als men 2*333MHz DDR gebruikt, dan is het theoretisch evensnel als PC1333.

Besluit deze DDR-chipset gaat 0wnen.

[Anoniem: 63569]

Het grote voordeel dat Rambus heeft, is niet de snelheid op zich, maar het feit dat het een seriele interface is.
Dit betekent dat het veel makkelijker op hoge snelheden kan werken zonder elektromagnetische interferentie en dat soort enge dingen.
Was dus de ideale combinatie met de P4 processor.
DDR was niet snel genoeg, en niet stabiel genoeg.

Nu is DDR iets stabieler, en iets sneller... maar toch is dit nog maar een nood-oplossing.
Als de kloksnelheid omhoog gaat, zul je weer tegen de instabiliteit van een parallele interface oplopen, dat is met een dual channel bus alleen maar erger geworden.

Dus op de lange termijn moet er toch een betere oplosssing komen... Misschien DDR-II, misschien toch Rambus, of misschien iets heel anders.

[frankvdtillaart]

Vraag ik me toch af hoe 'betrouwbaar' deze test is. Als het slecht uitkomt voor de gemiddelde tweaker (Intel beter / Rambus beter) dan wordt SiSoft altijd als onbetrouwbaar aangewezen.

Desalnietemin, ook ik vind deze resultaten er al heel erg lekker uitzien . Zeker voor een pre-prod model.

[max3D]

Wat een onmogelijk vaag nieuwsbericht blijkt dit te zijn. Het begint sensationeel:
"Het gaat natuurlijk om een pré-productie model, maar de resultaten zijn desalniettemin indrukwekkend te noemen. In sommige scores wordt de huidige high-end oplossing met PC1066 RDRAM zelfs met 30% verslagen"

Klinkt inderdaad heel indrukwekkend, maar waar gaat het echt om:
- het is een alpha bordje met beta drivers volgens Kyle
- dat bordje is zo instabiel dat het niet in staat om iets anders te draaien dan dit Sandra benchmarkje
- de P4 is hevig aan het 'clockthrottlen' bij deze 'benchmark'
- het geheugen draait hierbij op een fsb van 188 Mhz (verklaart gelijk de twee punten hierboven)
- bij een fsb van 166 komt er 'slechts' 4006 uit de memory benchmark, maar is het bordje nog steeds niet stabiel

Al die gegevens heb ik na wat doorlezen uit hetzelfde draadje en hetzelfde forum als waar het nieuwsbericht vandaan geplukt is.Ja, zo kan dus iedereen met een wonderbaarlijke benchmark aan komen zetten over nieuwe chipsets of technologieën. Met wat stikstof presenteert morgen iedereen een verhaal waar je verder inhoudelijk niets aan hebt.

Ik lees Tweakers nieuws al jaren omdat ik snel en efficient op de hoogte wil blijven; steeds vaker kost het me echter juist bergen tijd om er achter te komen dat de keizer geen kleren aan heeft.

Ik begrijp best dat Tweakers mee moet in de ratrace op het net om de laatste juicy story en ik vind het soms ook leuke verhalen, maar moet dat op deze manier gebracht?

Kan er niet een soort moderatiesysteem voor de nieuwspost zelf gemaakt worden?

Mijn voorstel:
om te beginnen iets met drie kleurtjes: harde, belangrijke feiten (nieuw produkt, technische doorbraak), harde, minder belangrijke feiten (categorie zoveelste rammelende thuistest van wat koelertjes) en de derde kleur voor de categorie Inquirer geruchten.

In een oogopslag is dan al duidelijk waar we het over hebben. Als dan ook nog de optie toegevoegd wordt om de lezers het bericht een puntenwaardering mee te laten geven spaar je de andere lezers heel veel tijd en onnodige ergernis. Idee?

[Anoniem: 26337]

ik geef je groot gelijk.

en om te bewijzen dat zulke hoge scores met Rimm makelijk te behalen zijn:

3985-3982

dat is mijn P4+P4T533+PC4200Rimm systeem, en het is niet extream overgeclockt.

[Weppel]

Dan stel ik voor dat je zelf eens nieuws gaat submitten, in plaats van hier lopen miepen dat het nieuws oud is..

[Tijgert]

Heeft de nieuwe Hammer met ingebouwde memory controller ook dual channel?

[silentsnow]

De Opteron krijg een Dual Channel DDR controller. DDR-333 zal het wel zijn, al verwacht ik dat volgende generaties gewoon DDR-II zullen ondersteunen. Volgens mij ondersteund de Opteron zelfs 72-bit DDR kanalen, das inclusief 8-bit voor een soort ECC modus.

[Anoniem: 2640]

het is tevens zo dat de Hammer ook overweg kan met een externe geheugen controller; je kunt dus altijd optimaliseren; ook kun je (intern) de geheugen controller van de hammer optimaliseren en aanpassen aan nieuwe geheugen standaarden.

[Anoniem: 66440]

ik ben nogal nieuw bij het hele gebeuren maar kan je nu gewoon DDR ram dubbel zo snel laten lopen als het mobo het maar ondersteund of zo.

lijkt me vet, dan neem ik corsair DDR400 op een nforce2 en blazen maar

[Anoniem: 63569]

Erm, het geheugen zelf gaat niet sneller lopen, je gaat alleen 2x zoveel geheugen tegelijk gebruiken.
(Zo'n soort trucje deed KT133A ook al met PC133 SDRAM).
Dus in feite wordt het wel 2x zo snel ja.

En aan een nForce2 heb je niks in dit geval. Die wordt begrensd door de CPU.
AMD heeft maar een 266 MHz bus, kun je wel sneller geheugen aan hangen, maar dat heeft geen effect.
DDR333 en DDR400 op een Athlon is al onzin in feite.
Je hebt alleen een klein beetje voordeel van de lagere latency, maar de snelheidswinst is nihil.

Intel heeft daarentegen een 533 MHz bus, en DDR400 is daar dus nog niet tegen opgewassen (PC1066 Rambus dus wel, maar dat was weer 16 bit, dus had je ook 2 channels nodig). Maar 2x DDR266 maakt ook 533, dus hebben ze gewoon nu 2 channels parallel aan de CPU geschakeld.

[silentsnow]

(Zo'n soort trucje deed KT133A ook al met PC133 SDRAM).
Dus in feite wordt het wel 2x zo snel ja.

De KT133A met PC133 SDRAM?? Dat volg ik niet helemaal.

En aan een nForce2 heb je niks in dit geval. Die wordt begrensd door de CPU.
AMD heeft maar een 266 MHz bus, kun je wel sneller geheugen aan hangen, maar dat heeft geen effect.
DDR333 en DDR400 op een Athlon is al onzin in feite.
Je hebt alleen een klein beetje voordeel van de lagere latency, maar de snelheidswinst is nihil.

De nForce 2 is nog niet eens uit! DDR333 heeft natuurlijk wel zin. Je hebt simpelweg meer geheugenbandbreedte. Dat is dan ook in de prestatie van je systeem te merken. Ik weet niet waarom jij denkt dat dat niet zo is. De snelheidwinst is dus niet nihil.

[John_Glenn]

Scali bedoelt bank-interleaving denk ik. Dat is natuurlijk niet hetzelfde als twee memcontrollers. Bij bank-interleaving vinden reads nog steeds wel na elkaar plaats...

Enne, ik heb toch echt benches van de nForce2 gezien (nieuws dat zowaar een keer niet door jou was gesubmit, Silentsnow ). En daar blijkt dus uit dat het inderdaad winst oplevert. Het PC1066+P4 pakket werd gewhoopt. Ik ben benieuwd hoe Granite Bay met P4 zich houdt tov nForce2 met Thoroughbred...

[jorisdekloris]

@mark3d

Dus wat je eigenlijk wil is gewoon een feiten rijte? Het maakt juist geruchten als deze juist leuk. Ikw ed dat de helft van de posters hierboven nog niet gezien had dat fsb op 188 stond.

Misschien was het vroeger minder belangrijk wat in de toekomst zou gebeuren. Misschien zijn roddels nu wel in. Misschien is dit wel de nieuwe manier van nieuwsposten.

OWKEE, jou systeem lijkt mij ook wel wat, nieuws beoordelingen. Alleen denk ik dat de nieuws revieuwers dat nu al doen.

Je moet je in beetje inleven in het stuk en niet alleen de cijfers lezen zoals vroeger. Je moet de onfo je eigen amekn en niet lezen, denk erover na... Dat doe jij duidelijk goed, de meeste niet.

[N0stradamus]

Volgens mij wil hij gewoon de headlines een kleurtje geven, zodat je op de frontpage snel kan zien wat voor type newspost het is.
Lijkt mij ook wel wat, trouwens.