@itix

Could you please post exact model of your memory stick ?

@All

Ah, uboot upgrade.

Intresting to see, if it makes any difference for speed.

@wegster

Quote:

by wegster on 5-Mar-2005 1:52:51 @Valiant Thanks! So thats the G4-800Mhz, on an 'unfixed' XE board then right?

Right.

Quote:

Any idea if your RAM is CL2 or CL3?

Sorry, I have no idea. I've got whatever Software Hut stuffed in when I bought it from them. I could probably crack open my A1 and look at the stick if I knew what to look for. Anyway, here are my results for the other tests:

ramspeed -b 3
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

INTEGER Copy: 152.95 Mb/s
INTEGER Scale: 152.72 Mb/s
INTEGER Add: 149.20 Mb/s
INTEGER Triad: 162.28 Mb/s
---
INTEGER AVERAGE: 154.29 Mb/s

ramspeed -b 6
RAMspeed (UNIX) v2.3.0 by Rhett M. Hollander (Alasir Enterprises), 2002-04

4Gb per pass mode

FL-POINT Copy: 182.21 Mb/s
FL-POINT Scale: 153.18 Mb/s
FL-POINT Add: 143.58 Mb/s
FL-POINT Triad: 143.42 Mb/s
---
FL-POINT AVERAGE: 155.60 Mb/s

_________________
--
-=#Val#=-
Valiant@Camelot


Amiga 1000; Amiga 2000; Amiga 3000T; CD-TV; CD32;
AmigaOne-XE 800Mhz G4;Sam400ep 666Mhz;
AmigaOne X-1000 1.8Ghz PA6T-1682M

@minator

Thanks for the data! See below.

Quote:

minator wrote: @wegster Quote: 1. WTF is up with the INT write speeds on the uA1-C? 121MB/sec versus 190MB/sec??! That's more than different grade of RAM can produce. I did some memory tests a couple of years back on the Peg 1 and a G3 iBook and these are pretty similar. It appears the G3 memory write speed is not that great. G4 improves in both areas, especially writes. There appear to be 2 Apple memory controllers, one sucks badly (was in the G3 iBook) and a second much better vesion in the G4 tower and my PowerBook, ArticiaS reads slower than the sucky Apple one but writes faster.

Yep, I'd believe it, which is one of the reasons I really wanted to see some more G3/G4 (Peg, A1, Mac) data.

Quote:

I'll attempt to interpret these to explain what's going on: As with memny memory test it's not actually testing the memory directly so these values are impacted by the cache speed. If you want the memory speed only you need to write a test which only uses the internal registers (preferably FP or Altivec). That said these figures are quite useful as I'm writing a modular synth and these tell me the working set I can use at any one time. From the "INTEGER & WRITING" figures below: 1kb - 32Kb blocks: (3.6-3.9 GB/second) - looks like this is hitting the L1 cache 64kb - 256kb (2 GB / second) - looks like this is hitting the L2 cache 512kb - 1024kb (420 MB - 1Gb / second) - starting to run out of L2. 4096kb upwards (374 MB / second) - cache is having a small effect - this is the RAM speed.

Sure, which is why I discarded the 'in cache' results in the summary section and said as much- you still obviously get cahce affecting the actual numbers, but once you're out of the block size fitting into cache it's a more realistic, and more importantly, a value that can be compared to other systems with more of a 'real' comparison. It would be most ideal if you were able to disable the L2/L3 cache entirely to entirely disregard cache effects from different sized CPUs.

Hmm, this statement:
Quote:

If you want the memory speed only you need to write a test which only uses the internal registers (preferably FP or Altivec).

I'm assuming this would need to be done in assembly only (unless you can dsiable the L2 cache via OS4 and Linux, and other OSes)? Any such beast exist? Or IOW, we know these tests aren't 100% 'real' numbers due to the cache effect even in 'non cache hit' results. Is there something better?


Making your results the same without the cache hits for comparison:
PowerBook G4 (7447A 1.33GHz): (512k L2 cache?)
INT READ: 355MB/sec
INT WRITE: 375MB/sec
INTMEM: 383MB/ec
FP READ: 345MB/sec
FP WRITE: 470MB/sec
FPMEM: 440MB/sec

Quote:

Cache (max) Reading 9 GB / second Writing 3.975 GB / Second Memory Reading 344 MB / second Writing 467 MB / second

True, I suppose we should actually be grabbing the in cache results as a seperate data point. I was initially thinking I wanted primarily to meausre the bus performance, which would be out of cache only (not really, but after block reads/writes are all in cache), bu this is useful too.

Your G4 powerbook #s look very close to my dual G4 powermac numbers, which makes sense.

_________________
Are we not done with the same silly arguments and flames yet??!

@itix
Thanks! so 'adjusted' numbers for comparison are below now:

Pegasos 2
CPU: 7447 1000MHz (G4)
RAM: 768MB NOTE: Using OS4 memspeed binary (probably should re-run from native compile)

INT READ: ~224MB/sec
INT WRITE: 237MB/sec
INTMEM: 207MB/sec
FP READ: 228MB/sec
FP WRITE: 322MBs/sec
FPMEM: 213MB/sec

Numbers by comparison are a bit higher than the A1XE numbers:
XE-G4-933Mhz 7557/256K cache CPU: (AOS4 pre-2, 'fixed' XE board):
INT READ: ~205MB/second
INT WRITE: ~190MB/second
FP READ: ~209MB/second
FP WRITE: ~415MB/second

I _think_ the Peg 2 has DDR RAM, however, correct? If so, it doesn't appear from this to be using the capabilities of DDR, which is interesting because:
1. It lends a bit of credence to the statements that PPC G4s don't really benefit from DDR (although DDR RAM is still cheaper )

OR

2. Peg 2 still doesn't have a great memory controller either...possibly combination of above, as we've seen the PowerMac/PB numbers do a fair amount better than either the A1s or Pegs.

Please someone correct me if I'm wrong about Peg 2 being DDR? (or of course if there's another option I'm missing..?

_________________
Are we not done with the same silly arguments and flames yet??!

@mlehto

Quote:

mlehto wrote: @wegster This is intresting... Ppl shouls test drbombcrater SetA1 tool (mem tweaker). You have memory stick from kgrach, officially working as good as possible ?? I got similar results with my SE with ramspeed than ppl here with uA1.

The problem with that is technically, using a second benchmark program, _might_ make those results invalid, at least in comparison to these results already posted. That's unfortunately often the case with benchmark programs of almost any type, and why for example spec.org does the industry standard specInt, SpecFP, LADDIS/SFS (filesystem) tests for all systems to be on 'common ground' with the same benchmark.

I'd love to give DrBC's tests a run for comparion purposes, especially if it's disabling the L2 cache entirely..

_________________
Are we not done with the same silly arguments and flames yet??!

@JKD
Quote:

I made a native compile of that utility (well, I downloaded the source and typed make!) and it shows different results on the Peg2. I'll post later. I think it maybe shows there are different optimizatinos between the versions and/or os4emu somehow has an influence (which would be weird)

Yeah, please do! I saw that was being run inder emu, which means 'cool, I haven't _seen_ anything run under OS4emu '...but probably not the best test, be better to run MOS/PPC native. Heh, my gcc/tools install is evidently hosed at momen, source is just ansi 'clean' C, but I can't link the program yet.

_________________
Are we not done with the same silly arguments and flames yet??!

@wegster

The Peg2 has DDR. This phenomenon was also seen in earlier Macs.

Theortetical maximum CPUmemory bandwidth = 133 MHz x 2 * 4 / 1024 / 1024 MB/s = 1,014.7 MB/s

This is lessened by RAM speed/waitstates time though...

Unrelated to memory speed but is it possible one cannot see the full benefits of DDR bandwidth unless ths bus heavily loaded, since there are several bandwith contenders, CPU, DMA utilizing the crossbar technology of the Marvell? (I could be talking out of my hat though...)

Steve

@wegster
Quote:

Yeah, please do! I saw that was being run inder emu, which means 'cool, I haven't _seen_ anything run under OS4emu

itix re-ran a native version for you already, my results are very close to this (same system)

@opi
Thanks, results 'standardized' below, but which CPU is this, Duron 1000MHz? Can you fill in the rest?

[quote]
opi wrote:
@wegster

AMD Duron with 266 DDR running Debian Linux 2.6.8, 64K L2 cache:
INT READ:
INT WRITE: 362MB/sec
INTMEM:
FP READ:
FP WRITE: 443MB/sec
FPMEM: 486MB/sec

_________________
Are we not done with the same silly arguments and flames yet??!

@itix
Thanks, standardizing and comparing to OS4emu run:
Peg2, 7447 1GHz, native MOS/PPC compile:
INT READ: 226MB/sec
INT WRITE: 466MB/sec
INTMEM: 216MB/sec
FP READ: 227MB/sec
FP WRITE: 466MB/sec
FPMEM: 213MB/sec

Pegasos 2 CPU: 7447 1000MHz (G4) RAM: 768MB NOTE: Using OS4 memspeed binary

INT READ: ~224MB/sec
INT WRITE: 237MB/sec
INTMEM: 207MB/sec
FP READ: 228MB/sec
FP WRITE: 322MBs/sec
FPMEM: 213MB/sec

And of course for comparison:
1XE-G4-800Mhz/7451/256K L2 cache, 'unfixed' XE board, AOS4 pre-2, os4depot ramspeed
INT READ: 202MB/sec
INT WRiTE: 210MB/sec
FP READ: 202MB/sec
FP WRITE: 366MB/sec

I guess this might make some sense- your writes have gone up significantly, virtually doubled. I'm guessing this is an optimization of the way block writes are broken down when dealing with blocks > the cache size...anyone have an alternative idea?

Reads of course, nothing can be done about- it is what it is...but OS4emu didn't 'hurt' it there any. Hmm, I think I need to get my compiler working and see if any differences are there then or not on the XE and see if there's any difference. If not, it would seem the peg2 IS faster at writes by a large margin.

_________________
Are we not done with the same silly arguments and flames yet??!

@thread

If anyone's interested I've compiled OS4/PPC, OS3/68k and Linux/x86 versions of Piru's simplewritespeed.c test, and added a read speed benchmark as well.

Grab 'em here.

@wegster
Quote:

I'd love to give DrBC's tests a run for comparion purposes, especially if it's disabling the L2 cache entirely..

I think disabling caches is a bad thing to do because that means you get a stable but artificial result. Real applications run with the caches on.

_________________
Who do you serve, and who do you trust? - Galen

@mlehto

Quote:

drbombcrater SetA1 make things different ... well done !-) (more tools like this) [/quote[ How? Is it a test or does it reset some registers somewhere, and then the _same_ memory tests show improved results? Can someone fill me in on this one? [quote[ I have 666/133 clocked SE. It is same "incarnation" as drbombcrater has, first public release. Memory stick is Kingston 512 MB reg ECC CL3. Some ppl drive their SE's like 733/133. Altoughht I have Zallmann NB cooler, I like too much my SE I definetly see slow writes and reads [/quote[ Well, it looks semi-apparent that different CPUs (say G3 vs G4) do in fact play a part in the reads and writes, and I'm thinking this is due to actual variations in cache speeds. I don't think the CPU speed matter much here, within reason. [quote] I use memory speed tool made by Harry Sintonen (known better as Piru) and it gives "better" results. Ie results wary more. But it is not publically avail yet. With this very tool I got 120MB/s and 210 MB/s results, They got better with SetA1 tool, 140 MB/s and 260 MB/s.

But- did you use the same tool to test the speed? If not, the results are somewhat suspect.

Quote:

My friend got 356 MB/s 32/64 bit read and 374 MB/s 32bit write and 625 MB/s 64 bit write with XE (1066/133 G4), with exactly same type of memory stick. So there should be something different between SE and XE. XE didn't responce to SetA1 much. Why, don't know.

Yeah, that was one of the things I wanted to see- differences between SE/XE/uA1/Peg etc, but the tests need to be done with same tool to compare apples to apples...

Quote:

You can see, that at least with this tool memoryspeeds get up. It should be insane, if nothing don't make any differ. Ppl in here have at least 666 G3 CXe, 800 FX/GX processors, varioius G4:s 800/933/1066, all popultaed with different type of memory sticks without any big differencies ?? I didn't want to read all results thought too carefully... These are after all "only" benchmarks. But it should be nice to know, where is bottleneck. OS itself, ArticiaS or how things are "prepared" by uboot. Anyway I feel that Piru's tool works better. Not because better results, but because it give results in larger scale.

What do you mean 'larger scale'?

It's been said before, but I expect the difference between CL2 and CL3 to be marginal, perhaps 5% at best on the same system. 5% is generally within tolerance between multiple runs, although I've see mor along the lines of perhaps 2% variation between runs...so it's still only a few percent all else being equal.

Quote:

This test made by itix was somehow intresting, at least you cannot say anything sure about emulated tests. And this test made with apple was cood also. Both with PPC at least.

Yeah, I think I'm going to have to build 2.3.1 from source and re-test once my compiler is happy..God help me if it makes a difference (re-test) Although the relative numbers for Se/XE/uA1 using the same binary should still remain comparable.

The PPC Macs is meant as a sanity check, as in the case of my powermac, it's using the same exact CPU as my XE, but does seem to have a better memory controller at this point (unless a rebuild of ramspeed on AOS makes a difference, as I built from source on all of the other systems)

Quote:

I didn't test this, but if you compile ramspeed yourself, compile it with -O2 switch and proper prosessor switch enabled.

Yes, that's how all of my other systems were compiled, aside from the ones not honoring the -O flag for the link stage. (OS X)

_________________
Are we not done with the same silly arguments and flames yet??!

@DrBombcrater

Quote:

DrBombcrater wrote: @thread If anyone's interested I've compiled OS4/PPC, OS3/68k and Linux/x86 versions of Piru's simplewritespeed.c test, and added a read speed benchmark as well. Grab 'em here. @wegster Quote: I'd love to give DrBC's tests a run for comparion purposes, especially if it's disabling the L2 cache entirely.. I think disabling caches is a bad thing to do because that means you get a stable but artificial result. Real applications run with the caches on.

EDIT- I'v rebuilt ramspeed on OS4 native, testing again to see if any differences, will post to os4depot shortly.

If anyone posts #s with simplewritespeed, _please_ note it as such when you post, as the numbers shoudl only be compared to runs using the same benchmark.

I agree about disabling cache, but it depends on what you're trying to test- in this case, I'm a bit more interested in the hardware 'limitation' of the memory controller and bus rather than in cache results.

Last edited by wegster on 05-Mar-2005 at 10:40 PM.

_________________
Are we not done with the same silly arguments and flames yet??!

@DrBombcrater

Quote:

If anyone's interested I've compiled OS4/PPC, OS3/68k and Linux/x86 versions of Piru's simplewritespeed.c test, and added a read speed benchmark as well.

anyone thought to test this on a Mini Mac yet?

that would be good to see

_________________
"The system no longer works " -- Young Anakin Skywalker

@wegster



Bog stock A1 G4 XE @800 512Mb RAM
Unfixed Mobo - Sil card installed latest flash NOT installed



B1

INTEGER & WRITING 1 Kb block: 2560.00 Mb/s
INTEGER & WRITING 2 Kb block: 2592.41 Mb/s
INTEGER & WRITING 4 Kb block: 2592.41 Mb/s
INTEGER & WRITING 8 Kb block: 2592.41 Mb/s
INTEGER & WRITING 16 Kb block: 2592.41 Mb/s
INTEGER & WRITING 32 Kb block: 2560.00 Mb/s
INTEGER & WRITING 64 Kb block: 1304.46 Mb/s
INTEGER & WRITING 128 Kb block: 1296.20 Mb/s
INTEGER & WRITING 256 Kb block: 1280.00 Mb/s
INTEGER & WRITING 512 Kb block: 305.22 Mb/s
INTEGER & WRITING 1024 Kb block: 295.95 Mb/s
INTEGER & WRITING 2048 Kb block: 282.48 Mb/s
INTEGER & WRITING 4096 Kb block: 275.64 Mb/s
INTEGER & WRITING 8192 Kb block: 272.70 Mb/s
INTEGER & WRITING 16384 Kb block: 271.26 Mb/s


B2
4Gb per pass mode

INTEGER & READING 1 Kb block: 3011.76 Mb/s
INTEGER & READING 2 Kb block: 3056.72 Mb/s
INTEGER & READING 4 Kb block: 3011.76 Mb/s
INTEGER & READING 8 Kb block: 3056.72 Mb/s
INTEGER & READING 16 Kb block: 3011.76 Mb/s
INTEGER & READING 32 Kb block: 3011.76 Mb/s
INTEGER & READING 64 Kb block: 1432.17 Mb/s
INTEGER & READING 128 Kb block: 1432.17 Mb/s
INTEGER & READING 256 Kb block: 1412.41 Mb/s
INTEGER & READING 512 Kb block: 252.22 Mb/s
INTEGER & READING 1024 Kb block: 211.57 Mb/s
INTEGER & READING 2048 Kb block: 208.98 Mb/s
INTEGER & READING 4096 Kb block: 208.77 Mb/s
INTEGER & READING 8192 Kb block: 208.98 Mb/s
INTEGER & READING 16384 Kb block: 208.77 Mb/s

B3

4Gb per pass mode

INTEGER Copy: 161.96 Mb/s
INTEGER Scale: 161.71 Mb/s
INTEGER Add: 158.84 Mb/s
INTEGER Triad: 171.96 Mb/s
---
INTEGER AVERAGE: 163.62 Mb/s


B4

4Gb per pass mode

FL-POINT & WRITING 1 Kb block: 2007.84 Mb/s
FL-POINT & WRITING 2 Kb block: 2027.72 Mb/s
FL-POINT & WRITING 4 Kb block: 2027.72 Mb/s
FL-POINT & WRITING 8 Kb block: 2027.72 Mb/s
FL-POINT & WRITING 16 Kb block: 2027.72 Mb/s
FL-POINT & WRITING 32 Kb block: 2027.72 Mb/s
FL-POINT & WRITING 64 Kb block: 1796.49 Mb/s
FL-POINT & WRITING 128 Kb block: 1812.39 Mb/s
FL-POINT & WRITING 256 Kb block: 1780.87 Mb/s
FL-POINT & WRITING 512 Kb block: 790.73 Mb/s
FL-POINT & WRITING 1024 Kb block: 591.91 Mb/s
FL-POINT & WRITING 2048 Kb block: 534.73 Mb/s
FL-POINT & WRITING 4096 Kb block: 512.00 Mb/s
FL-POINT & WRITING 8192 Kb block: 506.93 Mb/s
FL-POINT & WRITING 16384 Kb block: 500.73 Mb/s


B5

4Gb per pass mode

FL-POINT & READING 1 Kb block: 5851.43 Mb/s
FL-POINT & READING 2 Kb block: 6023.53 Mb/s
FL-POINT & READING 4 Kb block: 6023.53 Mb/s
FL-POINT & READING 8 Kb block: 6023.53 Mb/s
FL-POINT & READING 16 Kb block: 6206.06 Mb/s
FL-POINT & READING 32 Kb block: 5851.43 Mb/s
FL-POINT & READING 64 Kb block: 1878.90 Mb/s
FL-POINT & READING 128 Kb block: 1878.90 Mb/s
FL-POINT & READING 256 Kb block: 1828.57 Mb/s
FL-POINT & READING 512 Kb block: 255.04 Mb/s
FL-POINT & READING 1024 Kb block: 211.79 Mb/s
FL-POINT & READING 2048 Kb block: 208.98 Mb/s
FL-POINT & READING 4096 Kb block: 208.98 Mb/s
FL-POINT & READING 8192 Kb block: 208.98 Mb/s
FL-POINT & READING 16384 Kb block: 208.98 Mb/s


B6

4Gb per pass mode

FL-POINT Copy: 198.83 Mb/s
FL-POINT Scale: 167.73 Mb/s
FL-POINT Add: 153.60 Mb/s
FL-POINT Triad: 153.60 Mb/s
---
FL-POINT AVERAGE: 168.44 Mb/s

_________________
******************************************
I dont suffer from Insanity - I enjoy it

******************************************

@wegster

Quote:

I'm assuming this would need to be done in assembly only (unless you can dsiable the L2 cache via OS4 and Linux, and other OSes)? Any such beast exist? Or IOW, we know these tests aren't 100% 'real' numbers due to the cache effect even in 'non cache hit' results. Is there something better?

I wrote a memory speed test at one point in C but newer versions of gcc tend to mangle the reading speed test.

The gcc on the Mac doesn't seem to do this and these are the resuts I get :

Reading 350 MB / Second
Writing 559 MB / Second

Reading speed is slightly higher, writing speed improved quite a bit.

It allocates a big chunk of RAM (50MB) then reads or writes 32 doubles (256 bytes) over and over and over again. There are 32 FP registers and nothing else using them so the compiler should just use them. Using such a big chunk of ram should ensure any data cached is completely useless, using the full number of FP registers ensures latency effects are kept to a minium (using less registers reduces the speed measured).

_________________
Whyzzat?

@wegster


Quote:
But- did you use the same tool to test the speed? If not, the results are somewhat suspect.


No. But I really trust more that other tool. See below.

I made some comparisons between models with ramspeed about same time, when first uA1's arrived.


Quote:
What do you mean 'larger scale'?

It gives some difference between different models. I dont trust much test, wich seem to give same results with different models :)

And there have to be difference between models, if other tools finds them

Sorry my probably bad english

After all I dont care, what tool is used, if you/some other ppl can give explanation about this quite poor performance. It should be higher Allthough it is just benchmark.


Quote:
It's been said before, but I expect the difference between CL2 and CL3 to be marginal, perhaps 5% at best on the same system. 5% is generally within tolerance between multiple runs, although I've see mor along the lines of perhaps 2% variation between runs...so it's still only a few percent all else being equal.


Ok ... It may be. I thought, that CL2 and CL3 have difference.

Last edited by mlehto on 05-Mar-2005 at 11:23 PM.
Last edited by mlehto on 05-Mar-2005 at 11:21 PM.
Last edited by mlehto on 05-Mar-2005 at 11:20 PM.

@The_Editor
Thanks. so which version of uBoot are you running now then?

Is this with ramspeed from os4depot or?

Interesting- you're writes are faster than the other XEs, reads remain the same.

Summary of normalized data:
A1 G4 XE @800 512Mb RAM, nfixed Mobo, siI card, uBoot 1.1.1
INT READ: 209MB/sec
INT WRITE: 280MB/sec
INTMEM: 164MB/sec
FP READ: 210MB/sec
FP WRITE: 529MB/sec
FPMEM: 168MB/sec

_________________
Are we not done with the same silly arguments and flames yet??!

@mlehto

Quote:

But- did you use the same tool to test the speed? If not, the results are somewhat suspect.

Quote:

No. But I really trust more that other tool. See below. I made some comparisons between models with ramspeed about same time, when first uA1's arrived.

Are these posted somewhere?

BTW, bear in mind it depends on what is being tested as far as results 'should or shouldn't be' similar. In this case, we're seeing some effect of the cache speeds, as well as the cache size, plus the effeciency (or lack thereof) of the memory controller.

I'd fully expect an XE and uA1 with the same CPU to run similar results...what is/was a surprise is the current uA1-C runs on the write side, which may be a result of the OS not optimizing the size of writes (IOW, not knowing the CPU has a 1M L2 cache), or of the compiler.

Quote:

Quote: What do you mean 'larger scale'? It gives some difference between different models. I dont trust much test, wich seem to give same results with different models :) And there have to be difference between models, if other tools finds them

Not really, see above. If we were doing a purely computational test, or a 'combined' test using CPU as well as IO, then I'd expect to see (more) differences....

EDIT- I hate nested quotes

Last edited by wegster on 06-Mar-2005 at 12:11 AM.
Last edited by wegster on 06-Mar-2005 at 12:11 AM.
Last edited by wegster on 06-Mar-2005 at 12:09 AM.
Last edited by wegster on 06-Mar-2005 at 12:09 AM.

_________________
Are we not done with the same silly arguments and flames yet??!