x86-64 cpu - Dutch Power Cows

vrijdag 21 maart 2003 17:22

Acties:

Topicstarter

Misschien niet echt nuttig maar toch....

Ik zit me af te vragen of je met zo'n cpu op dezelfde kloksnelheid nou een veel beter resultaat haalt als met de huidige 32 bits cpu's? Iemand die daar wat over kan vertellen? Er van uit gegaan dat de client ook voor een 64 bits cpu is dan he.

Not all chemicals are bad. Without hydrogen or oxygen, for example, there would be no way to make water, a vital ingredient in beer.

vrijdag 21 maart 2003 17:26

Acties:

Verwijderd

Dat vroeg ik me nou ook al af

vrijdag 21 maart 2003 17:29

Acties:

YakuzA

Wat denk je nou zelluf hey :X

een x64 cpu kan normale x32 taken 20 tot 30% sneller uitvoeren.

als je ook nog client nog voor x64 was geschreven zou ie in principe nog 2x zo snel worden

komt iig in de buurt dit

Death smiles at us all, all a man can do is smile back.
PSN

vrijdag 21 maart 2003 17:43

Acties:

E-jey

Als de client geoptimaliseerd zou worden voor de opteron/athlon 64 zou dat denk ik wel meer opleveren. Hij is iig sneller op zelfde kloksnelheid. Dit komt doordat de hammer een on-die geheugen controller heeft, meer registers en 64 bit schijnt ook weer voor snelheid te zorgen. Alleen al de on-die geheugen controller zorgt voor 10 tot 20% meer snelheid.

Let wel op dat x64 niet bestaat!. Tis IA-64 of x86-64.
Dat de processor 64bit is ipv 32 wil niet zeggen dat 2x zo snel is. Als het programma ervoor geoptimiliceert zorgt dat ook weer voor 20% snelheids winst.

correct me if I am wrong plzz

vrijdag 21 maart 2003 17:57

Acties:

DaGreatRV

Wah seggie nou?

En dan nog maar hopen dat AMD niet die ene belangrijke instuctie heeft geschrapt zoals Intel heeft gedaan bij de P4.

vrijdag 21 maart 2003 18:14

Acties:

YakuzA

Wat denk je nou zelluf hey :X

DaGreatRV schreef op 21 maart 2003 @ 17:57:
En dan nog maar hopen dat AMD niet die ene belangrijke instuctie heeft geschrapt zoals Intel heeft gedaan bij de P4.

block rotate ^_^

magoed voor rc5 zou ie 3 a 4x zo snel kunnen gaan op zelfde klok als client er voor geoptimaliseerd is denk ik

en dat x64 tikte ik omdat ik ut teveel werk vond op de rest ervoor te tikken ;p

[ Voor 12% gewijzigd door YakuzA op 21-03-2003 18:14 ]

Death smiles at us all, all a man can do is smile back.
PSN

vrijdag 21 maart 2003 19:39

Acties:

E-jey

Hij zou ongetwijfeld 2x zo snel kunnen zijn. 3/4x vind ik een beetje veel

Onthou wel dat hij op 1.6Ghz word geintrocuceert in september. Denk dat Intel dan ook een stuk verder is.

vrijdag 21 maart 2003 19:51

Acties:

YakuzA

Wat denk je nou zelluf hey :X

E-jey schreef op 21 March 2003 @ 19:39:
Hij zou ongetwijfeld 2x zo snel kunnen zijn. 3/4x vind ik een beetje veel
Onthou wel dat hij op 1.6Ghz word geintrocuceert in september. Denk dat Intel dan ook een stuk verder is.

hij plakt 2x x32 aan elkaar, das al 2x zo snel en dan issie over dat totaal nog die 20 a 30 sneller ;p met beetje fantasie kom je der wel uit

Death smiles at us all, all a man can do is smile back.
PSN

vrijdag 21 maart 2003 20:31

Acties:

Glashelder

Anti Android

YakuzA schreef op 21 March 2003 @ 18:14:
[...]

block rotate ^_^

magoed voor rc5 zou ie 3 a 4x zo snel kunnen gaan op zelfde klok als client er voor geoptimaliseerd is denk ik

en dat x64 tikte ik omdat ik ut teveel werk vond op de rest ervoor te tikken ;p

Was het niet Bit Rotate? Ik weet niet of dat hetzelfde is maar toch?

PV 4915wp op oost, 2680 wp op west, 1900 wp op zuid. pvoutput - AUX 8 kW bi bloc

vrijdag 21 maart 2003 20:32

Acties:

E-jey

Fantasie heb je zeker

Je cpu is niet 2x zo snel als hij 64 bit is

Hij is alleen 20% ofzo sneller als het progsel ervoor geoptimaliceert is

vrijdag 21 maart 2003 20:34

Acties:

Glashelder

Anti Android

E-jey schreef op 21 maart 2003 @ 20:32:
Fantasie heb je zeker

Je cpu is niet 2x zo snel als hij 64 bit is Hij is alleen 20% ofzo sneller als het progsel ervoor geoptimaliceert is

Waar haal jij dat nou weer vandaan

PV 4915wp op oost, 2680 wp op west, 1900 wp op zuid. pvoutput - AUX 8 kW bi bloc

vrijdag 21 maart 2003 20:46

Acties:

E-jey

Dual-Zip:
heb ik ergens gelezen in een nieuwspost van T.net. Nou zijn er nogal veel posts op t.net over de hammer. Ik kan het daarom niet vinden

Staat volgensmij ook in dat preview van t.net

vrijdag 21 maart 2003 21:18

Acties:

Nutcaze

Topicstarter

Dat heb ik dus ook gelezen van die 20 a 30% snelheidswinst. Ik kan me echter voorstellen dat bij RC5-72 (en ik denk dat RC5-64 helemaal optimaal zou zijn geweest) het voordeel toch wel enorm stijgt. Aangezien (bij RC5-64) het niet meer opgebroken hoeft te worden in 2 keer 32......ik heb er verder geen verstand van maar dat idee heb ik nu zelf.

Not all chemicals are bad. Without hydrogen or oxygen, for example, there would be no way to make water, a vital ingredient in beer.

vrijdag 21 maart 2003 21:37

Acties:

Verwijderd

Nutcaze schreef op 21 March 2003 @ 21:18:
Dat heb ik dus ook gelezen van die 20 a 30% snelheidswinst. Ik kan me echter voorstellen dat bij RC5-72 (en ik denk dat RC5-64 helemaal optimaal zou zijn geweest) het voordeel toch wel enorm stijgt. Aangezien (bij RC5-64) het niet meer opgebroken hoeft te worden in 2 keer 32......ik heb er verder geen verstand van maar dat idee heb ik nu zelf.

Nee dat is dus duidelijk.
Dat het met RC5-64 beter zou gaan dan met RC5-72 is dus werkelijk de plank misslaan. Dat er in beide toevallig "64" staat maakt het niet "Meer Compatible".

Ik zou nog maar een keertje een x86-32 of x86-64 beschouwing lezen

vrijdag 21 maart 2003 21:54

Acties:

Verwijderd

Het is moeilijk te voorspellen wat de exacte snelheidswinst van een hammer processor ten opzichte van een athlon zal zijn.
Ten eerste heb je sneller toegang tot je geheugen vanwege de geintegreerde northbridge. Dat kan al een 20-30% schelen bij programma's die in 32-bit emulatiemode draaien. Voor dnet verwacht ik weinig effect hiervan omdat de client zo klein is dat ie in de cache past.
Ten tweede is het aantal beschikbare registers verdubbeld; hierdoor is het minder vaak nodig om tussenresultaten naar het geheugen te schrijven. Dit scheelt ook al gauw een 20%. Het is wel nodig om de applicatie speciaal voor de hammer te hercompileren. De dnet core is in assembly geschreven; het hangt van het registergebruik af hoeveel versnelling er mogelijk is; laten we voorlopig maar aannemen dat het 20% is.
Ten derde kan de hammer met 64 bits parallel werken. Dit kan een factor 2 opleveren als je 64 bits nodig hebt. Daar staat tegenover dat sommige athlons al voorzien zijn van de 128 bits brede SSE registers. Het is afhankelijk van de code in hoeverre SSE bruikbaar is. Voor RC5-64 kun je optimaal gebruik maken van de 64 bits registers (50% sneller), bij RC5-72 kun je van 3 naar 2 registers (33%sneller). Voor OGR heb ik geen idee.
Zo redenerend kom je op een 46% minder kloktikken voor dezelfde RC5-72 output. Als je wilt wachten op de geoptimaliseerde client.

Peter

vrijdag 21 maart 2003 23:25

Acties:

stappel_

dual-zip schreef op 21 March 2003 @ 20:31:
[...]
Was het niet Bit Rotate? Ik weet niet of dat hetzelfde is maar toch?

het was de shift. maar de instructie is niet weggehaald, hij is niet meer in hardware aanwezig. de CPU emuleert de instructie nu. vroeger was de shift 1 cpu click. nu iets van 4-6 clicks.

Ubero: #2, Euler: #1, GOT: #1, Des: #1, Zeta: #1, Eon: #3, OGR-24: #3, OGR-25: #7,
LM: #7, AP: #5, DF: #19, D2OL: #37, SOB: #50, TSC: #63, RC5: #96

zaterdag 22 maart 2003 00:10

Acties:

Avier

1x vouwen voor Avijf

Bravo Mathfox-Peter. Gevoelsmatig wil ik toevoegen dat het waarschijnlijk iets lager is omdat er op het laden (en gebruik van) de client zelf al volledig in cache kan. Maar nogmaals bravo.

-on-210x297 (bij d2ol)

"Na een fles whiskey op landscape"

zaterdag 22 maart 2003 10:36

Acties:

Verwijderd

Avier schreef op 22 March 2003 @ 00:10:
Bravo Mathfox-Peter. Gevoelsmatig wil ik toevoegen dat het waarschijnlijk iets lager is omdat er op het laden (en gebruik van) de client zelf al volledig in cache kan.

Het blijft koffiedik kijken.

En ik had de effecten van de snellere geheugeninterface al op 0 gesteld voor dnet. (Met SETI of distributed folding maakt dat weer veel uit.)
Er is nog een tweede orde effect aan de langere registers: er zijn minder registers nodig per getal waar je mee rekent. In de athlon heb je 7 bruikbare registers; daarin kun je 2 72 bits getallen opslaan (3 registers per getal) en dan hou je een register over. Heb je 64 bits registers, dan zijn er 2 per getal nodig en dan heb je opeens 3 vrije registers van de 7 (en dat maakt voor een assembler programmeur een wereld van verschil). Met de acht extra registers is er opeens een zee van ruimte.
Die zee van ruimte in de registers betekent dat er veel minder load en store operaties nodig zijn; en ik heb het idee dat dat het punt is waar de meeste pentiums op vastlopen (adresberekeningen en toegang tot L1 cache). Ik verwacht dat in een hammer dnet client de snelheid beperkt wordt door de hoeveelheid rekenwerk (optellingen en vermenigvuldigingen).

Peter

woensdag 18 juni 2003 20:32

Acties:

Nutcaze

Topicstarter

Om maar even een oud topic naar boven te halen:

Weet iemand of er al een dnet client is voor de Opteron, ik kan 'm zelf bij dnet in ieder geval niet vinden. En zo ja: iemand die mij inzage kan geven dan wat het prestatieverschil is t.o.v. zijn/haar vorige CPU.

Ik heb overigens zelf geen Opteron, ben alleen benieuwd.

Not all chemicals are bad. Without hydrogen or oxygen, for example, there would be no way to make water, a vital ingredient in beer.

woensdag 18 juni 2003 23:57

Acties:

Floor-is

5.2

Ik kan wel een bergje opterons leveren, zijn vanaf a.s. maandag vrij beschikbaar bij mijn leverancier(s).

Ik doe zelf UD-THINK, 64-bit is wel tof, maar die ukkels hebben al geen linux-client, waardoor de kans op een 64-bit client al helemaal klein wordt.

Bericht hierboven

donderdag 19 juni 2003 00:02

Acties:

Verwijderd

Floris schreef op 18 June 2003 @ 23:57:
Ik kan wel een bergje opterons leveren, zijn vanaf a.s. maandag vrij beschikbaar bij mijn leverancier(s).

Heb je er ook moederborden bij? en dimmetjes...

donderdag 19 juni 2003 00:39

Acties:

Verwijderd

Tsjah; blijf maar lekker verderdromen:
Dnet-crew's view op 64-bit platformen en RC5 (kort)

[19:15:18] <acidblood> First, I'd like to say that 64-bit machines do not help RC5 in any way.
[19:15:58] <acidblood> In fact, they hinder RC5, since the algorithm calls for modulo-2^32 arithmetic, which is just a fancy way of saying that all arithmetic should be done in 32-bit registers and truncated whenever it exceeds that.

Dus NEE; die factor 2 tussen 32 en 64 bits zul je niet om die reden terugvinden in de performance van je koe. Wellicht dat andere specifieke cpu optimalisaties een factor 2 kunnen bereiken, maar het staat los van "64 bits is 2x 32 bits, dus het gaat 2x zo snel"

donderdag 19 juni 2003 07:39

Acties:

YakuzA

Wat denk je nou zelluf hey :X

YakuzA schreef op 21 March 2003 @ 18:14:
[...]

magoed voor rc5 zou ie 3 a 4x zo snel kunnen gaan op zelfde klok als client er voor geoptimaliseerd is denk ik

Death smiles at us all, all a man can do is smile back.
PSN

donderdag 19 juni 2003 11:26

Acties:

Verwijderd

SETI@Home op een 4P Opteron:
http://www.amdmb.com/article-display.php?ArticleID=240

In the single processor, single work unit test, the computer completed the work unit in approximately 2.217 hours (2:13) as noted with SetiSpy

Most would expect that performance would suffer quite a bit because while each SETI@Home client has it’s own processor, they still have to share other system resources, with the Opteron based system, the performance hit was almost nil. Here are the times for each of the processors:

CPU0 – 2.2110 hours (2:13)
CPU1 – 2.2654 hours (2:16)
CPU2 – 2.2145 hours (2:13)
CPU3 – 2.2121 hours (2:13)

4 clients tegelijkertijd.. en dat met bijna 0% vertraging (ze elkaar in de weg zouden kunnen zitten)... wat een prestatie!

$_/-\o_$ $_/-\o_$

Natuurlijk mag het aantal 'brute MHz'en' nog wel wat hoger

donderdag 19 juni 2003 11:54

Acties:

Verwijderd

Verwijderd schreef op 19 June 2003 @ 11:26:
SETI@Home op een 4P Opteron:
http://www.amdmb.com/article-display.php?ArticleID=240

[...]

4 clients tegelijkertijd.. en dat met bijna 0% vertraging (ze elkaar in de weg zouden kunnen zitten)... wat een prestatie! $_/-\o_$ $_/-\o_$

Natuurlijk mag het aantal 'brute MHz'en' nog wel wat hoger

Statistieken van een SGI Octance² dual dus op seti ..

processor 1 = 0.55 hour
processor 2 = 0.47 hour

client is 64bits voor irix dus retesnel