Athlon 64 4000+ vs Athlon 64 X2

[TGEN]

Verwijderd schreef op maandag 04 december 2006 @ 20:10:
[...]
Wat mij meer verbaaste was dat wanneer ik de htt link verlaagte.
Dat het systeem Minder soepel loopte .
Het lijkt wel de snelweg maar dan in file

Nogal wiedes, je draait t met een HTT multiplier van 1x. Reken jij eens uit hoe weinig bandbreedte je dan nog overhebt voor DMA naar je videokaart framebuffer? Ja, dat gaat over de HyperTransport link, want de geheugencontroller zit op de CPU die.

Wat ik erger vond is dat mijn systeem op den duur steets langzamer ging lopen met htt link op 1x (liep zelfs er op vast)

Met deze observatie kunnen wij helaas niks, er is immers geen qualificatie en quantificatie voor.

De htt zelf is een ontwerp dat nog in zijn kinderschoenen staat.
Ik geloof best dat het ontwerp op den duur steets beter presteert (misschien wel bij versie 3?)

Vertel jij mij eens waar jij de kennis vandaan hebt om HyperTransport als technologie van een waardeoordeel te voorzien. Ben jij lid van het HyperTransport consortium, en heb je daarom toegang tot allerlei implementatiedetails die wij niet hebben? Heb jij toevallig ook een doctoraal in de informatica of elektrotechniek, op WO niveau dus?

[Soepster]

Verwijderd schreef op maandag 04 december 2006 @ 20:13:
[...]


de toekomst zal steets beter dual core gaan ondersteunen
Oblivion is zo game die meerderen cores ondersteunen. (wegens xbox360)
Omdat de software die microsoft heeft uit gebracht voor de xbox 360 100% compatebel is met de pc versie.

Wel, de benchmarks wijzen uit dat de huidige games die dual core ondersteunen zoals Quake 4 en Oblivion, op een X2 4800+ maar een paar fps beter lopen dan op een FX 57. Ik zou het dan ook van de prijs laten afhangen.

Ik zou hypertransport trouwens geeen techniek in de kinderschoenen noemen. Je gaat toch ook niet een cpu op 100 mhz XP laten draaien en dan zeggen dat die CPU techniek in de kinderschoenen staat omdat de boel het niet trekt!

[ Voor 16% gewijzigd door Soepster op 04-12-2006 21:27 ]

[Verwijderd]

TGEN schreef op maandag 04 december 2006 @ 21:12:
[...]

Nogal wiedes, je draait t met een HTT multiplier van 1x. Reken jij eens uit hoe weinig bandbreedte je dan nog overhebt voor DMA naar je videokaart framebuffer? Ja, dat gaat over de HyperTransport link, want de geheugencontroller zit op de CPU die.


Je oke dus htt verlagen heeft wel invloed terwijl men zeg van niet
Dat is nu bewezen
[...]

Met deze observatie kunnen wij helaas niks, er is immers geen qualificatie en quantificatie voor.


Ooit gehoort van eigen mening ?
Of je eigen systeem kennen waar je op werk?
Ik merkte het wel dat het systeem langzamer werkte
Of jij dat wel of niet belangrijk vind is jouw probleem.
[...]

Vertel jij mij eens waar jij de kennis vandaan hebt om HyperTransport als technologie van een waardeoordeel te voorzien. Ben jij lid van het HyperTransport consortium, en heb je daarom toegang tot allerlei implementatiedetails die wij niet hebben? Heb jij toevallig ook een doctoraal in de informatica of elektrotechniek, op WO niveau dus?

Mag ik vragen wat daar mee te maken heeft?
Ik volg het nieuws over de htt bus omdat de techniek er achter totaal anders is.
Info kan je over op de web vinden (ook op tweakers)
Wat ik belangrijk vind of jij belangrijk vind doet er niet terzaken .
Vind ook hoe jij er op reageert als een persoon die juist de htt techniek als heilig beschouwt.
Zit jij zelf bij de HyperTransport consortium?

[TGEN]

Verwijderd schreef op maandag 04 december 2006 @ 21:52:
[...]
Mag ik vragen wat daar mee te maken heeft?

Ik neem aan dat je op het laatste punt reageert, je quotetechniek maakt dat niet echt duidelijk. Het heeft er in zoverre mee te maken dat je bij gebrek aan kennis van zaken beter geen waardeoordelen moet geven, of politicus moet worden.

Ik volg het nieuws over de htt bus omdat de techniek er achter totaal anders is.
Info kan je over op de web vinden (ook op tweakers)

Het zou je sieren als je er ook wat meer van begreep, en niet allerlei conclusies zou trekken uit meningen van anderen en minstens dubieuze manieren van het benchmarken van de performance van de HyperTransport bus dan wel interne crossbar in multicore CPUs van AMD. Zeker als er geen sluitende informatie beschikbaar is over hoe dat precies in elkaar steekt.

Wat ik belangrijk vind of jij belangrijk vind doet er niet terzaken .

Het doet in zoverre terzake, dat het een goed onderbouwde mening meer aandacht en respect verdient; iedereen kan uit z'n nek kletsen immers, daar is geen greintje kennis voor nodig.

Vind ook hoe jij er op reageert als een persoon die juist de htt techniek als heilig beschouwt.
Zit jij zelf bij de HyperTransport consortium?

Ik probeer je alleen te wijzen op je gebrekkige onderbouwingen en ongerelateerde conclusies. Mijn voorkeur voor bepaalde technieken voor het verbinden van processoren onderling is bij deze irrelevant. En nee, ik ben zeker geen lid van het HyperTransport consortium.

[Verwijderd]

Ik gebruikte een programma die voor dualcore bestemt is (wat voor een maak niet uit)
De programma geeft aan dat bij de HTT multiplier verlagen de prestatie vermindert.

Het hele stuk gaat ook over met overklokken
De meeste mensen klokken de HTT multiplier omlaag zodat ze verder kunnen klokken.
Door terug klokken heb je verlies en moet je terug halen door bus klok verder te verhogen
De amd athlon 64 x2 proc heeft extra last er van als je de HTT multiplier verlaagt omdat er twee proc's gemonteerd zijn.
Dus de vraag is was doet de htt bus als je er meerderen amd x2's gaat monteren?
Wel er komt een hogeren Htt bus aan met de vermoedelijke reden dat de huidige htt bus te laag is.

Daar ging deze test om namelijk.

[TGEN]

Verwijderd schreef op maandag 04 december 2006 @ 22:43:
Ik gebruikte een programma die voor dualcore bestemt is (wat voor een maak niet uit)
De programma geeft aan dat bij de HTT multiplier verlagen de prestatie vermindert.

Wat voor benchmark maakt wel uit, want er zijn zoveel parameters waar je rekening mee dient te houden. Een microbenchmark die aan cache trashing doet en tegelijkertijd memory performance meet is in dit geval een betere test.

Het hele stuk gaat ook over met overklokken
De meeste mensen klokken de HTT multiplier omlaag zodat ze verder kunnen klokken.
Door terug klokken heb je verlies en moet je terug halen door bus klok verder te verhogen

Ze stellen een lagere HTT multiplier in *juist* om de base HT clockspeed te kunnen verhogen, want aan de hand daarvan worden o.a. de clockspeed van het geheugen bepaalt (die overigens ook weer een aparte divider heeft). 4x250 is effectief even snel als 5x200, maar als je geheugen 1:1 draait draait die vervolgens wel op 250MHz ipv 200MHz (500 en 400MHz effectief wegens DDR), wat weer meer geheugenbandbreedte oplevert.

De amd athlon 64 x2 proc heeft extra last er van als je de HTT multiplier verlaagt omdat er twee proc's gemonteerd zijn.

Natuurlijk, meerdere cores die een bus moeten delen maken het geheel altijd trager; in het 100% load geval is de bus per core effectief 50% trager. Bedenk wel, dat de HyperTransport bus alleen voor I/O gebruikt wordt in single-socket setups, en het gros van de bandbreedte van een klassieke FSB zoals gebruikt bij de Pentium 4/D en Core 2 Duo wordt gebruikt voor geheugenverkeer, wat hier dus niet het geval is vanwege de on-die geheugencontroller. DMA verkeer van en naar andere apparatuur natuurlijk wel, maar die hebben zelf meestal niet voldoende bandbreedte om die bus te vullen, tenzij je de bus natuurlijk dermate limiteert zoals in jouw voorbeeld van een HTT multiplier van 1.

Dus de vraag is was doet de htt bus als je er meerderen amd x2's gaat monteren?
Wel er komt een hogeren Htt bus aan met de vermoedelijke reden dat de huidige htt bus te laag is.

Of hij voor de huidige processorsnelheden te traag is ben ik niet met je eens, daar de bandbreedte van subsystemen die erachter hangen in het normale geval nog niet voldoende is om de bus te vullen (denk aan PCIe x16). Dat men met het oog op de toekomst wel met snellere versies komt is niet meer dan logisch.

Daar ging deze test om namelijk.

Ik had de indruk dat de test bedoeld was om aan te tonen in hoeverre de hoeveelheid en configuratie van L2 caches op multicore CPUs van invloed was op de framerate van een bepaald programma.

[Verwijderd]

Ik had de indruk dat de test bedoeld was om aan te tonen in hoeverre de hoeveelheid en configuratie van L2 caches op multicore CPUs van invloed was op de framerate van een bepaald programma

Nee dat was een anderen topic voor
Dit ging puur over het overklokken van de htt bus en wat er dan gebeurde.
Kon je nu beter een hoge htt bus met bevoorbeeld 4x?
Of kon je beter een lage htt bus met 5x hebben?
En wat gebeurde er met de htt bus als je het verlaagt ? (was iemand anders zijn vraag)

Dit heb ik getest voor ze met mijn systeem. (bord is voor 100% instelbaar kwa nforce4 chip voltagen en de htt bus voltage )(waardoor ik een hogere klok kon halen met vaste 5x htt)

[TGEN]

Verwijderd schreef op maandag 04 december 2006 @ 23:15:
Ik had de indruk dat de test bedoeld was om aan te tonen in hoeverre de hoeveelheid en configuratie van L2 caches op multicore CPUs van invloed was op de framerate van een bepaald programma

Nee dat was een anderen topic voor

Ik denk niet dat het praktisch is om die benchmark voor een ander probleem te gebruiken.

Dit ging puur over het overklokken van de htt bus en wat er dan gebeurde.
Kon je nu beter een hoge htt bus met bevoorbeeld 4x?
Of kon je beter een lage htt bus met 5x hebben?

Dat hangt natuurlijk af wat je doen wil: zoals ik eerder al zei, aan die HTT bus clock hangen ook andere clocks vast, dus als je die wil verhogen moet je wel de HTT bus clock verhogen (zonder met individuele dividers te prutsen).

En wat gebeurde er met de htt bus als je het verlaagt ? (was iemand anders zijn vraag)
Dit heb ik getest voor ze met mijn systeem. (bord is voor 100% instelbaar kwa nforce4 chip voltagen en de htt bus voltage )(waardoor ik een hogere klok kon halen met vaste 5x htt)

Dan heb je minder I/O performance dus, dat is redelijk simpel.

[Verwijderd]

TGEN schreef op maandag 04 december 2006 @ 21:12:
[...]

Nogal wiedes, je draait t met een HTT multiplier van 1x. Reken jij eens uit hoe weinig bandbreedte je dan nog overhebt voor DMA naar je videokaart framebuffer? Ja, dat gaat over de HyperTransport link, want de geheugencontroller zit op de CPU die.

Volgens mij heeft dat er niet veel mee te maken. Het single-threaded algoritme lijkt geen last te hebben van een tragere HTT-link (geen lagere framerates en geen haperingen), terwijl er nog steeds evenveel data naar de videokaart gestuurd wordt.

[Verwijderd]

TGEN schreef op maandag 04 december 2006 @ 23:04:
[...]
Ik had de indruk dat de test bedoeld was om aan te tonen in hoeverre de hoeveelheid en configuratie van L2 caches op multicore CPUs van invloed was op de framerate van een bepaald programma.

In principe was het niet bedoeld als benchmark voor systemen, maar meer om uit te zoeken welk van de twee mogelijke implementaties het meest efficient zou zijn op de meeste systemen.
Dat je er ook verschillende CPUs en cache-technieken mee kunt vergelijken is een bijkomend voordeel... en dat blijkt dat de HTT-link invloed heeft op de synchronisatie van de cores was een toevallige ontdekking. De consensus was dat de cores via de crossbar communiceerden, en verder onafhankelijk waren van de HTT-link, maar waarschijnlijk is er dus wel een bepaalde afhankelijkheid.

Ik wil trouwens wel opmerken dat ik bij de Pentium D geen verschijnselen als stotteren/haperen heb gezien. Dat betekent misschien dat Intel de communicatie tussen de cores meer voorrang geeft boven andere I/O dan bij AMD het geval is. Of misschien juist dat AMD een (grotere) buffer gebruikt, en eerst wat transacties opspaart, om die in een soort burst-mode te versturen.
Qua bandbreedte zou de Pentium D (met 800 MHz FSB) namelijk in het nadeel moeten zijn tov een HTT-link, zelfs op 4x, als ik me niet vergis.