ragemem benchmark results thread !

Here are the results on my A4000T with CStormPPC and CVisionPPC: (There is a problem with Zorro Slots at the moment. I need to clean them since ZoRRAM is giving me troubles especially under OS3.9 (Using OS3.9, I can't copy stuff to RAM because it reboots the machine after a few seconds. It's random actually. Sometimes it would copy more than 200MBs before rebooting. Once it simply slowed the OS to a crawl).

THANKS TO STACHU FOR MAKING MY CYBERSTORMPPC COME ALIVE AGAIN. I GUESS THIS IS THE RECORD FOR CLASSIC AMIGAS WITHOUT PCI BUSBOARDS. ;)

New Shell process 3
3.OS41:> ragemem

RAGEMEM v0.37 - compiled 11/06/2010

CPU: 604e 9.12546 @ 400 Mhz
Caches Sizes: L1: 32 KB - L2: none - L3: none
Cache Line: 32

---> CPU <---
MAX MIPS: 797

---> L1 <---
READ32: 1511 MB/Sec
READ64: 3020 MB/Sec
WRITE32: 1268 MB/Sec
WRITE64: 2407 MB/Sec

---> RAM <---
READ32: 98 MB/Sec
READ64: 104 MB/Sec
WRITE32: 53 MB/Sec
WRITE64: 54 MB/Sec
WRITE: 94 MB/Sec (Tricky)

---> VIDEO BUS <---
READ: 5 MB/Sec
WRITE: 18 MB/Sec

Just for a laugh and as there isn't a post of the X1000...

@328gts

i have an sam460ex :)

i did some benchmarking before and after installing latest RadeonHD drivers. but i was using SysMon ragemem and didn't fine the log, but i have the Mips score.

i also was using RadeonHD 0.55 to start with.

before update: ati drv 0.55

GfxBench2D score: 5903
ragemem: 2291 mips

after installed ati driver 1.2

GfxBench2D score: 5890
ragemem: 2308

after installed ati driver 2.4

GfxBench2D score: 5880
ragemem: 2308

@Severin

Does anyone know why the RAM write speeds on X1000 are so appalling in ragemem? The x1000 RAM Write speeds are the slowest of all the NG Amigas.

@ddni

I'm guessing you're thinking about the tricky write speed? As the other ram speeds are most often better than other machines.

@ddni

Quote:
Actually, only the "tricky" write speed is "appalling," the others are very good.

I'm guessing that "tricky" means that it's using the dcba cache instruction to prepare a cacheline for a write without wasting bandwidth reading it from RAM. While this boosts performance on 32-bit CPUs, it's an illegal instruction on 64-bit (G5) CPUs like the PA6T in the A1-X1000. Hence, that instruction triggers an exception handler, and that slows things right down.

Hans

Interesting. Thanks for the explanation.
Do existing programs make that call in real day to day usage?

@ddni
Quote:
AFAIK, the vast majority of programs don't use it. A developer has to be pretty concerned with performance to even consider using such lowlevel techniques. Dcba has to be used carefully, because it operates on an entire cacheline. That means handling special cases so you don't accidentally wipe memory before/after the data that you're working on. Besides, the "dcbz" instruction is similar enough, and is safe to use on G5 CPUs (although you don't get all the speed benefits because of the larger cacheline size).

It's possible that the kernel may use it on hardware that supports it. IIRC, some functions such as the memcopy ones are optimised on a per-CPU basis.

Hans

@Severin

Is it me or the X1000 results are low in MIPS and video Bus ?

no one noticed 7454 3.3 @ 1400 MHZ = 4194 MIPS ?

Went through the thread but did not spot x1000 results.
Someone with better eyes.... please?

@KimmoK

@ddni
Thanks!


So...
>7454 1400 MHZ = 4194 MIPS ?

= 3 MIPS/Mhz while it should reach 2,3 MIPS/Mhz ??


PA6T 1800 Mhz = 3082 MIPS

= 1,7MIPS/Mhz while it should reach 2,2MIPS/Mhz

So the test code or compiler perhaps are not the same in those tests???


(( I think 7454 should have same core & MIPS/Mhz as these http://www.freescale.com/webapp/sps/s ... _summary.jsp?code=MPC7448 ))

+++++++++++++
@angelheart
VideoRAM speeds depend greatly on what methode is used.
http://www.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/1551
So it seems x1000 can reach 1400MB/s currently.

@KimmoK

Once can compare different results from different apps all day long.

I was referring to post #122 X1000 result for RAGEMEM v0.37 -Video bus :

---> VIDEO BUS <---
READ: 66 MB/Sec
WRITE: 160 MB/Sec

compare against

post #60 CPU: AMCC PPC460EX 1.2 @ 1166 Mhz

---> VIDEO BUS <---
READ: 72 MB/Sec
WRITE: 261 MB/Sec

Then think about price difference.

surely bus/bandwidth is better on AMCC for this value - so that needs investigating to improve on future systems.

If we can collate all results into CSV would be great, then a small code can test a games usage of resources and offer recommended system / card requirements.

@angelheart
This is with 4.1 FE

RAGEMEM v0.37 - compiled 11/06/2010

CPU: P.A. Semi PWRficient PA6T-1682M B1 @ 1800 Mhz
Caches Sizes: L1: 64 KB - L2: 2048 KB - L3: none
Cache Line: 64

---> CPU <---
MAX MIPS: 3082

---> L1 <---
READ32: 6845 MB/Sec
READ64: 13670 MB/Sec
WRITE32: 6846 MB/Sec
WRITE64: 13668 MB/Sec

---> L2 <---
READ32: 3339 MB/Sec
READ64: 4979 MB/Sec
WRITE32: 2539 MB/Sec
WRITE64: 4042 MB/Sec

---> RAM <---
READ32: 2958 MB/Sec
READ64: 4150 MB/Sec
WRITE32: 2716 MB/Sec
WRITE64: 3507 MB/Sec
WRITE: 369 MB/Sec (Tricky)

---> VIDEO BUS <---
READ: 177 MB/Sec
WRITE: 161 MB/Sec

@thread

I wonder if ragemem is (hand) optimized for PA6T?
To my understanding we do not yet have gcc that can do PA6T optimizations.

@Thread

Crisot gave an explanation (in French) on Amiga-NG:

"Sur SAM460, la RAM tourne à la vitesse du L2... Soit le L2 du 460EX est pas terrible, soit j'ai loupé un truc (mais quoi...)

(On Sam460, RAM goes as fast as L2 cache. Either L2 from the Sam460 is rubbish or I missed someting)

Sur X1000, c'est encore pire, l'écriture RAM est supérieure à l'écriture L2, ce qui est matériellement impossible, la RAM passant forcément par le L2... Je me demande si ma loop est pas trop courte pour bencher à ces vitesses là.

(It's even worse on X1000 : writing in RAM is faster than writing in L2, which in impossible since RAM goes through the L2 cache... I'm wondering if my Loop is too short to bench such speeds)

Pour le tricky super lent, c'est parceque mon code n'est pas adapté à la Cache Line du PA6T.

(Regarding the super slow tricky test, it's because my code is not adapted to the PA6T Cache Line)

Pour les MIPS. Je n'ai que des hypothèses mais pas de réponse:

(Regarding MIPS, I have only hypothesis but no answers)

-Déjà, mon bench n'est pas multi-threadé, il n'utilise qu'un seul core, donc il faut multiplier par 2 ce chiffre.

(First, my bench is not multithreaed, it uses only one core so we must multiply x2 this value)

-Dans tous les cas le PA6T@2.0 Ghz est donné constructeur pour 8800 MIPS, ça fait 3960 MIPS par core@1.8 Ghz.

(Anyway, PA6T@2.0Ghz should give, from the manufaturer, 8800MIPS, so 3960 MIPS by core@1.8Ghz.)

-Ma loop n'est pas du tout optimisée pour le PA6T, elle a été écrite avec les datasheet des 604e/G3/G4/460EX. Je pense que le PA6T ne dispatche pas du tout les instructions de la même manière, mais sans datasheet je peux rien écrire.

(My loop is not at all optimized for the PA6T, it was written with 604e/G3/G4/460EX datasheets. I suspect the PA6T to not dispatch instructions the same way than the others but without the datasheets, I cannot be sure nor enhance Ragemem[i]).

-Au dela des MIPS la rapidité des caches et de la ram ont une énorme influence sur les performances CPU. A titre d'exemple, lire un seul octet en mémoire sur un XE (240 mo/sec) équipé d'un G4@1.0Ghz (3000 MIPS), c'est en temps machine l'équivalent de 104 instructions perdues (!!!) pendant lesquelles le CPU attend. En clair, un G4 attend continuellement après le reste de la machine, si on pouvait convertir le temps machine perdu en taches ménagères, la pelouse serait toujours tondue et la maison propre.

([i]Beyond MIPS, caches and RAM speed make a huge difference in CPU performances. For example, reading only on byte in memory on the XE (240MB/s) with a G4@1Ghz (3000MIPS), is equivalent of 104 lost instructions (!!!) while the CPU is waiting. To simplfy : a G4 is always waiting for the the other parts of the comuter. If we could convert the lost time by the system in household tasks, the house would always be clean.)

Je pense pas que core à core (ahah) le PA6T soit beaucoup plus puissant que le G4, mais tout ce qui tourne autour (caches, bus, ram) lui laisse infiniment plus de marge de manoeuvre. Le G4 ira beaucoup moins vite, mais paradoxalement glandera beaucoup plus.

(I don't think that the PA6T core is much more powerful than the G4 core, but everything that makes the X1000 (caches, FSB, RAM) gives him more latitude. G4 will be way slower but, paroxally, will wait a lot more for the rest of the architecture.)."

I hope I have translated everything correctly

wow just realized I never updated my old ragemem thread with results from my X1000 as I started it with my old Samflex@800.

well better late than never

X1000,4GB ram, Radeon HD7750-1GB VRam (low profile, single slot)

[img width=300]RageMem-June14-15-HD7750 [/url], [/img]

well now, very interesting seeing my much stronger Gigabyte HD7950, 3GB Ram performing worse here compared to my older single slot low profile HD7750 above??

also noticed that SuperTuxkart ran very smooth with my HD7750 and is running very slow & choppy with my HD7950?? more testing later with my 7950


[img]RageMem-HD7950-Jun16-15 by G S, [/img]

@angelheart

Quote:

The newer AMMC PowerPC SOCs only scale to 1.3Ghz.

The LSI Axxia PowerPC SOCs look much more interesting on paper. They scale as high as 1.8Ghz on a 4 core SOC and the 476fp core is rated at 2.7 DMIPs per Mhz. It also has bigger L2 cache than the 465 cores as well as large L3 cache.
It also has a SIMD unit although I'm not sure if this is Altivec/VMX* although it would make sense for IBM to have designed a a new vector unit for the 476fp.
LSI don't specify what version of PCIe is used on there product pages but I did see a product breif that sugested that it was PCIe 3.0

A system based on that faster Axxia SOCs should be able to trounce the X1000 in every aspect.

Both the Axxia ACP3500 and ACP3400 have a 1295 pin/ball count so in theory should be able to use the same board for both. That would give a good range of speeds and cores. The 3500 can have 2 cores at 1.1Ghz, 2 cores at 1.26Ghz, 4 cores at 1.26Ghz and 6 cores at 1.26Ghz while the 3400 can have 2 cores at 1.6Ghz or 4 cores at 1.8Ghhz

*VMX is IBM's name for Altivec.

@TSK

HI, I have the exact same machine, and G3 CPU.
What voltage do you run your CXe CPU on ?

I'm running mine at 666MHz at 1.64V, had to step it up from 1.59V.

Have you tried any higher ?

Thanks.