I ran this on an AmigaONE XE G4 clocked at 800Mhz, it
is a modified memspeed.c which selects the best figures
for a given memory size over a period of time.

The program itself does not perform a single block of modifications - it is in fact sequential access of
4 bytes at a time in a block of 64 bytes - so these
may not be the hardware speeds but are reasonably indicative of access from a C like programming languages for writes/reads.

During the testing period the machine was used as normal, causing context swaps, the theory being that perhaps we could get at least some of them operating without a context swap!

Write figures:

(bytes)
64 2844.444 MB/s
128 2844.444 MB/s
256 2844.444 MB/s
512 3200.000 MB/s
1024 3200.000 MB/s
2048 3657.143 MB/s
4096 3657.143 MB/s
8192 3200.000 MB/s
16384 3200.000 MB/s
32768 4266.667 MB/s
65536 1422.222 MB/s
131072 1347.360 MB/s

(end of CPU cache figures )

262144 984.615 MB/s
524288 308.434 MB/s
1048576 269.474 MB/s
2097152 269.474 MB/s
4194304 263.918 MB/s
8388608 266.667 MB/s

Read figures:
64 4266.667 MB/s
128 2844.444 MB/s
256 4266.667 MB/s
512 4266.667 MB/s
1024 5120.000 MB/s
2048 4266.667 MB/s
4096 5120.000 MB/s
8192 4266.667 MB/s
16384 4266.667 MB/s
32768 3657.143 MB/s
65536 1600.000 MB/s
131072 1706.667 MB/s

(end of CPU cache figures )

262144 1066.667 MB/s
524288 275.269 MB/s
1048576 224.561 MB/s
2097152 228.571 MB/s
4194304 232.727 MB/s
8388608 224.561 MB/s

Note that running the program, we have assotiated costs between
the timer start and end, there is the cost of processing the
loop and stopping condition, the cost of copying 4 bytes at a time
and the cost of moving the pointer around. During this time
the longer the segment of memory being played around with
the more scheduler swaps we are going to hit. The faster the CPU
the less impact any of the overhead we have ( kernel, inner loop,
stopping condition ) has on the actual process.

What we would like to do, is get a tighter inner loop, and do a
decent block copy - perhaps one using Altivec instructions,
this should get us closer to the actual limits.

So who was it who said mem access on AmigaONE would suck?!

These look pretty good to me...

Ian

_________________
Life starts at 030, is fun at 040 and causes impotence at x86.

Well this is from a Pentium 3 laptop running at 800Mhz
( x21 ) from mains electricity:

*** MEMORY WRITE PERFORMANCE (256 MB LOOP) ***
size = 64 bytes: 1600.000 MB/s
size = 128 bytes: 1600.000 MB/s
size = 256 bytes: 1828.571 MB/s
size = 512 bytes: 1706.667 MB/s
size = 1024 bytes: 1828.571 MB/s
size = 2048 bytes: 1969.231 MB/s
size = 4096 bytes: 2133.333 MB/s
size = 8192 bytes: 1969.231 MB/s
size = 16384 bytes: 1969.231 MB/s
size = 32768 bytes: 1505.882 MB/s
size = 65536 bytes: 1600.000 MB/s
size = 131072 bytes: 1505.882 MB/s
size = 262144 bytes: 501.961 MB/s
size = 524288 bytes: 228.571 MB/s
size = 1048576 bytes: 159.006 MB/s
size = 2097152 bytes: 154.217 MB/s
size = 4194304 bytes: 158.025 MB/s
size = 8388608 bytes: 161.006 MB/s
*** MEMORY READ PERFORMANCE (256 MB LOOP) ***
size = 64 bytes: 2560.000 MB/s
size = 128 bytes: 2560.000 MB/s
size = 256 bytes: 2327.273 MB/s
size = 512 bytes: 2133.333 MB/s
size = 1024 bytes: 2133.333 MB/s
size = 2048 bytes: 2560.000 MB/s
size = 4096 bytes: 2327.273 MB/s
size = 8192 bytes: 2560.000 MB/s
size = 16384 bytes: 2560.000 MB/s
size = 32768 bytes: 1347.368 MB/s
size = 65536 bytes: 1422.222 MB/s
size = 131072 bytes: 1422.222 MB/s
size = 262144 bytes: 382.090 MB/s
size = 524288 bytes: 246.154 MB/s
size = 1048576 bytes: 250.980 MB/s
size = 2097152 bytes: 256.000 MB/s
size = 4194304 bytes: 234.862 MB/s
size = 8388608 bytes: 243.810 MB/s

@DaveP

Interesting. In the test, are you actually copying a block of memory? If you just read a byte / word etc into a variable and not use it, is it not possible that within the loop the actual read is optimised away and only the last read processed (just after the loop).
Naturally the write test would have to write the data, but a clever compiler would spot the misused memory read in the loop a mile away...

_________________
Doing stupid things for fun...

@Karlos

Good question. I'll make the code available so you can see
if you think it gets optimised out.

Certainly the test performs a hell of a lot faster if I comment
the reading code out so I guess probably not

Regards

Dave.

That does imply there is extra work done in the loop then.

A while back, when trying to measure bus speeds I bumped into this effect. I had to do the loop in asm in the end , then I had total control over the loop itself as well as the read.

Do you calibrate an empty loop first and subtract the time?

_________________
Doing stupid things for fun...

No I dont do that, thats a good idea I could also subtract
the time taken to increment the pointer and do all the offset
additions.

Quote:

DaveP wrote: No I dont do that, thats a good idea I could also subtract the time taken to increment the pointer and do all the offset additions.

Well, thats what I meant really - do everything you would do normally except the read / write step, that hopefully should compensate for most of the overheads.

_________________
Doing stupid things for fun...

@DaveP

Pardon my total programming ignorance here, but does the amount of RAM one have affect the results in any way?

Yes. You should ensure that the amount of free, unallocated memory exceeds that which is used by the application.

Ok, thx

Quote:

DaveP wrote: Yes. You should ensure that the amount of free, unallocated memory exceeds that which is used by the application.

Hmm .... that in a nut shell explains why windos will NEVER work.


AmigaOne! AOS4.0! Showing us all, the way!

Well you have to beware the swap algorithm on any system that implements VM.

I don't think that swap is happening, but Ill reboot later on without any swap partitions ( I know - naughty ) and rerun the test.

Good point.