ragemem benchmark results thread !

RAGEMEM v0.37 - compiled 11/06/2010

CPU: AMCC PPC440EP 1.3 @ 666 Mhz
Caches Sizes: L1: 32 KB - L2: none - L3: none
Cache Line: 128

---> CPU <---
MAX MIPS: 1323

---> L1 <---
READ32: 2448 MB/Sec
READ64: 4867 MB/Sec
WRITE32: 2457 MB/Sec
WRITE64: 4896 MB/Sec

---> RAM <---
READ32: 277 MB/Sec
READ64: 277 MB/Sec
WRITE32: 165 MB/Sec
WRITE64: 165 MB/Sec
WRITE: 907 MB/Sec (Tricky)

---> VIDEO BUS <---
READ: 28 MB/Sec
WRITE: 63 MB/Sec

RAGEMEM v0.37 - compiled 11/06/2010

CPU: AMCC PPC440EP 1.3 @ 666 Mhz
Caches Sizes: L1: 32 KB - L2: none - L3: none
Cache Line: 128

---> CPU <---
MAX MIPS: 1332

---> L1 <---
READ32: 2471 MB/Sec
READ64: 4934 MB/Sec
WRITE32: 2483 MB/Sec
WRITE64: 4947 MB/Sec

---> RAM <---
READ32: 279 MB/Sec
READ64: 300 MB/Sec
WRITE32: 165 MB/Sec
WRITE64: 165 MB/Sec
WRITE: 909 MB/Sec (Tricky)

---> VIDEO BUS <---
READ: 28 MB/Sec
WRITE: 63 MB/Sec

The two patches did make a difference! Before, videos above 640x480 were jerky but now I can play DVD resolution smoothly using DvPlayer. Also, demos and games under E-UAE are noticeably faster now.

@trixie

Thanks for remind me about videos, I completely forgot to test them with DVPlayer and MPlayer with both fixes.

@trixie

Quote:

I just posted this in the News comments, but it also seems to fit here.

Regarding MPlayer and DVplayer.
I have no idea why, but neither player would present a DVD playback without extreme
frame skipping and voice way out of sync while using the standard CD/DVD connection
of the 440ep/667MHz. To get decent playback the SATA cable had to be plugged into
the connector under the HD standard connector (port 1 in MPlayer GUI).

Those problems, and others, are now gone after doing just the pci-mini-update. The
sam440ep_setup has also added to the performance of the Sam.

ahh I miss this thread!..ok 460ex owners let's get some results posted here

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.