@bernd_afa

see my last post it`s being updated new test result for Blizzard PPC 334Mhz.
there has been some newer improvement on my card but can`t upload test just yet.

if possible remove all old test result for Blizzard PPC and replace with new Blizzard PPC @334Mhz.

also new 68060@76Mhz on Blizzard no data trashing (fixed)
new Bvision 100Mhz memory clock new standard.
new PCI bus speed 38Mhz but can operate @43Mhz under OS4.0 only (awaiting possible fix for OS3.x).

Last edited by delshay on 27-Aug-2010 at 07:14 PM.
Last edited by delshay on 27-Aug-2010 at 06:36 PM.
Last edited by delshay on 27-Aug-2010 at 06:34 PM.
Last edited by delshay on 26-Aug-2010 at 09:04 PM.
Last edited by delshay on 26-Aug-2010 at 08:36 PM.
Last edited by delshay on 26-Aug-2010 at 08:33 PM.
Last edited by delshay on 26-Aug-2010 at 08:28 PM.

_________________
The Machine: Bride Of The Pin•Bot by Williams Electronics

@pavlor
>That says something about this test...

I develop the compiler optimizer(for amiblitz) and learn a lot about CPU architecture to do this.

and during that i find out, the real world fft and inverse fft for float and integer is a good test situation to see how good a CPU perform in out of order execution and performance /MHZ.

But of course more tests are better, because CPu architecture can be so diffrent that a CPU can in 1 program faster and in other slower.but thats only around 10-20 %.

maybe HammerD can do the mp3 encode benchmark with his cyberppc OS4.so we can see if the result differ much from this bench.

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=30008&forum=2#576603

The IBM G3 freescale 604e G4 G5 PPC(the extreme expensive Power CPU i do not count) is the glory of PPC, all other later PPC designs are target to embedded and trim to use less power and so they give less performance per MHZ.

but i find intresting, that the old Cyberstorm PPC in a design of 12 years ago with slow EDO RAM give such a good performance in compare to SAM

Last edited by bernd_afa on 27-Aug-2010 at 10:07 AM.
Last edited by bernd_afa on 27-Aug-2010 at 10:05 AM.
Last edited by bernd_afa on 27-Aug-2010 at 10:05 AM.
Last edited by bernd_afa on 27-Aug-2010 at 10:05 AM.
Last edited by bernd_afa on 27-Aug-2010 at 10:03 AM.

@bernd_afa

Quote:

maybe HammerD can do the mp3 encode benchmark with his cyberppc OS4.so we can see if the result differ much from this bench.

Yes, that would be better benchmark.

Quote:

The freescale G3 604e G5 PPC is the glory of PPC, all other later PPC designs are target to embedded and trim to use less power and so they give less performance per MHZ.

You mean that other designs than 604e, G3 and G5 give less performance per MHz? Or that even G3, e600 and G5 give less performance per MHz than 604e?

Quote:

but i find intresting, that the old slow EDO RAM give such a good performance in compare to SAM

How memory intensive is your benchmark?

@pavlor
>You mean that other designs than 604e, G3 and G5 give less performance per MHz?

yes, but G3 from freescale is too slow.only G3 from IBM is fast, have faster FPU as G4 from freescale, only miss altivec.g3 freescale can cvompare with the 603e.

but as far i known no Amiga PPC system use G3 from freescale.

>How memory intensive is your benchmark?

dont know exact, but i guess 20-25% is uncached memaccess done.

but you can see the memory slowdown effect when you compare the speed at 500 MHZ of the SAM 667 and 800 MHZ.the 800 MHZ version is not depend on clock speed faster.

same you can see on the cybppc 150 to 366 speed when look at 500 MHZ time

Last edited by bernd_afa on 27-Aug-2010 at 11:09 AM.
Last edited by bernd_afa on 27-Aug-2010 at 11:06 AM.
Last edited by bernd_afa on 27-Aug-2010 at 11:05 AM.
Last edited by bernd_afa on 27-Aug-2010 at 11:04 AM.

@bernd_afa

Quote:

yes, but G3 from freescale is too slow.only G3 from IBM is fast, have faster FPU as G4 from freescale

Remember that 750CX/CXe/FX/GX are newer than original G3 CPUs from both IBM and (then) Motorola, thus their speed advantage is logical.

Quote:

g3 freescale can cvompare with the 603e.

Nonsense. At least integer performance per MHz is on par with 604e (much better than 603e). Even 440 core has (much) better performance per MHz than 603e (compare SAM and Efika).

@pavlor
>Nonsense. At least integer performance per MHz is on par with 604e (much better >than 603e). Even 440 core has (much) better performance per MHz than 603e >(compare SAM and Efika).

and where are values that can compare between efika and SAM ?
I still think 440ep is the slowest PPC design ever build.

too bad that nobody with a efika do the benchmark here

Out of intrest, due to messing with ideas in data processing etc, can your code handle FFT of mega, giga, and possibly terra sample sizes, and if it can, does it at least equal theoretical slow down proportional to log log samples? As in, taking the FFT of a 1024 sample block takes x time, taking 1024 blocks therefore takes 1024 times, but taking the FFT of the complete 1024*1024 samples, takes twice as long, due to the log time taken to shuffle the 1024 blocks.

I think I manaaged to get some C++ source code example to work in HiSoft Basic in UAE on Ubuntu, so it would be intresting to see some more realistiic values for possible speed. 8) Currently I can only do a 256 due to plotting etc, so when I get it over a few seconds or megasample size, can see whats better and by how much.

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

@RodTerl
>Out of intrest, due to messing with ideas in data processing etc, can your code >handle FFT of mega, giga, and possibly terra sample sizes,

thats not my code, but it can of course handle unlimet size.currently you can see on the test 413696 samples are process in this test.

see the output in the bench.

time needed xxxxxms for 413696 samples,

Last edited by bernd_afa on 27-Aug-2010 at 08:04 PM.

@bernd_afa

CPU was replaced with IBM 604e 350MHz and clocked at 366.667MHz with 66.667 oscillator and 5.5 multiplier.

66.667 x 5.5 = 366.667 MHz

My 060 is clocked at 50MHz still, but there is some timing issues, so I will replace 060 CPU with latest mask 060 and clock it using the same oscillator as the PPC clock so both CPUs will have same bus speed.

Hopefully that will fix the freeze I can get sometimes. RAM controller is very lame on CS PPC so you have to be very careful about RAM you select. My ram isn't so great. I have some IBM 72-pin simms from ebay on order, so hopefully they are better (they come from IBM server).

BTW my lame result (see private msg):

3.RAM Disk:> lame WhereDoAllTheJunkiesComeFrom.mp3.wav
LAME 3.98.2 32bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding WhereDoAllTheJunkiesComeFrom.mp3.wav
to WhereDoAllTheJunkiesComeFrom.mp3.wav.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
100/9467 ( 1%)| 0:01/ 2:01| 0:01/ 1:34| 2.0408x| 1:33
-04:04-------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 1.0 99.0 93.0 4.0 3.0 ***Break
3.RAM Disk:> lame WhereDoAllTheJunkiesComeFrom.mp3.wav
LAME 3.98.2 32bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding WhereDoAllTheJunkiesComeFrom.mp3.wav
to WhereDoAllTheJunkiesComeFrom.mp3.wav.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9467/9467 (100%)| 2:20/ 2:20| 2:21/ 2:21| 1.7542x| 0:00
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 3.5 96.5 88.6 6.9 4.5
Writing LAME Tag...done
ReplayGain: -5.4dB

_________________
AmigaOS 4.x Beta Tester - Classic Amiga enthusiast - http://www.hd-zone.com is my Amiga Blog, check it out!

@HammerD

ok, thanks for info, your value show that on lame Test that SAM 800 is 64% faster as your 366 PPC.The SAM 800 user do not finish the lame test, normaly the Factor relatime decrease on longer test.so the SAM is maybe more slower.

and on this fft benchmark SAM 800 is 49% faster as your 366 MHZ cyberstorm with fft and float and 70% faster on integer.

I hope thats enough that pavlor see that this benchmark is near real world tests, but need less time
I dont know how much speed depend on FPU on lame or if it use more integer.

Last edited by bernd_afa on 31-Aug-2010 at 08:14 PM.
Last edited by bernd_afa on 31-Aug-2010 at 08:13 PM.

@bernd_afa

Quote:

I hope thats enough that pavlor see that this benchmark is near real world tests, but need less time

I hope you are joking... As you wrote:

Quote:

I dont know how much speed depend on FPU on lame or if it use more integer.

That would bring some info to our discussion!

I think that even 666 MHz 440EP will be 60 % (or even more) faster than 366 MHz 604e (so 160 % of 366 MHz 604e) in integer operations. However, we can only interpret application benchmarks.

Quote:

The SAM 800 user do not finish the lame test, normaly the Factor relatime decrease on longer test.so the SAM is maybe more slower.

Did you mean user from this thread (Samo39, post 36) ?


@HammerD

Can you run OGR-NG on your 604e and post your scores?

This test is *completely* dominated by the 68K emulator.

I just ran it in E-UAE on my Mac. Going by the other scores a 2.4GHz Core2Duo should produce the second fastest result.

Actual results:
Float: 21862ms
Integer: 27557ms
integer: optimised 9691ms
According to the test it's the second slowest!

What's more according to the Mac's CPU monitor E-UAE doesn't load the CPU more than 24% even when set to max.

This shows 2 things:

1) This does not measure CPU speed.
2) E-UAE on the Mac sucks really, really badly (I don't think E-UAE includes the 68K JIT).

_________________
Whyzzat?

@Pavlor

Yes this values from SAM 800

Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
12948/12948 (100%)| 1:59/ 1:59| 2:00/ 2:00| 2.8233x| 0:00

But when i compare, the SAM user do use a other test.you can see diffrent frames.

thats from 366 MHZ cybppc

3.RAM Disk:> lame WhereDoAllTheJunkiesComeFrom.mp3.wav
LAME 3.98.2 32bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding WhereDoAllTheJunkiesComeFrom.mp3.wav
to WhereDoAllTheJunkiesComeFrom.mp3.wav.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9467/9467 (100%)| 2:20/ 2:20| 2:21/ 2:21| 1.7542x| 0:00

>

>Can you run OGR-NG on your 604e and post your scores?

have you a link how to do this and SAM values for this ?

you cant use some other benchmark values, because OS4 have only the GCC.so you should use OS4 values


>I hope you are joking... As you wrote:

>>Quote:
>>I dont know how much speed depend on FPU on lame or if it use more integer.

this doesnt matter, FPu and integer differ only around 20%.

@minator
>2) E-UAE on the Mac sucks really, really badly (I don't think E-UAE includes the 68K JIT).

Yes your results show that no JIT is used.

only when a JIT is used, then it measure really CPu speed.

The test use asm instructions that every CPU have.

the JIT of the target system need only translate the instruction to a simular instruction of the target CPU.

thats a simple process and every JIT do in same way.

So this make sure, that no diffrent results due to diffrent compilers can happen and so can see how good the CPU out of order execution work.

Last edited by bernd_afa on 01-Sep-2010 at 05:22 PM.

@bernd_afa

Quote:

have you a link how to do this and SAM values for this ?

see http://n1cgi.distributed.net/speed/

Remember that this sort of application is not much useful benchmark for comparison of different architectures. However, it gives some information when comparing CPUs from one architecture (eg. PPC). G4/G5 values are higher because of AltiVec.

@pavlor
>see http://n1cgi.distributed.net/speed/

>Remember that this sort of application is not much useful benchmark for >comparison of different architectures. However, it gives some information when >comparing CPUs from one architecture (eg. PPC). G4/G5 values are higher because >of AltiVec.

ah you mean this benchmarks.this benchmarks do not have much memory access, and it use only very very few asm instructions. near all run in 1. Level Data cache.

this test show that the 440ep have good values,
but thats as you can remember the useless rc5 benches are the glory of PPC and every CPU developer of a PPC take care to make the few needed instructions for this, fast as other PPC, to show that his design is not slow.

that on X86 this benches are slow is because, X86 have no register exchange instruction.When this is add in X86 then it can lots faster.

but because high performance on such tests is only usefull for hackers, i think nobody add such a instruction in X86

@bernd_afa

Quote:

but thats as you can remember the useless rc5 benches are the glory of PPC and every CPU developer of a PPC take care to make the few needed instructions for this, fast as other PPC, to show that his design is not slow.

We compared PowerPC to PowerPC, not PowerPC to x86 (etc.). In this regard is careful usage of OGR-NG valid, as I pointed in my prior post.

It is interesting that OGR-NG score scales with estimated CPU performance (eg. 68040 vs 68060 or 603e vs 750FX).

@pavlor
>We compared PowerPC to PowerPC, not PowerPC to x86 (etc.). In this regard is >careful usage of OGR-NG valid, as I pointed in my prior post.

but there is no OGR value for sam, i dont know if the OGR Benchmark is compile for OS4 or 68k

@bernd_afa

Quote:

but there is no OGR value for sam, i dont know if the OGR Benchmark is compile for OS4 or 68k

Native PowerPC. Look again.

SAM 440EP 666 MHz OGR-NG

AmigaOne 750FX 800 MHz OGR-NG

I hope these links work.

A1-SE@733MHz, OS4.1.2

Speed test for FFT + iFFT: (float)
time needed 3933ms for 413696 samples, => 1.19258344173431x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer)
time needed 2899ms for 413696 samples, => 1.61794781684875x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer handoptimized 68K ASM)
time needed 1339ms for 413696 samples, => 3.50293564796447x speed @44100Hz/stereo


same machine, OS4.0 Final Update

Speed test for FFT + iFFT: (float)
time needed 3865ms for 413696 samples, => 1.21356558799743x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer)
time needed 2903ms for 413696 samples, => 1.61571848392486x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer handoptimized 68K ASM)
time needed 1411ms for 413696 samples, => 3.32418918609619x speed @44100Hz/stereo

Last edited by OS4_Gamer on 02-Sep-2010 at 05:48 PM.

_________________
A1-SE G3@733MHz, 1Gb RAM, Radeon9250, Sil0680, SB-Live 5.1 with OS4.0/4.1, Debian-Linux

@pavlor
>Native PowerPC. Look again.

>SAM 440EP 666 MHz OGR-NG

>AmigaOne 750FX 800 MHz OGR-NG

>I hope these links work.

ah so the ogr-ng. i test only the ogr list.

but when you calc a little you can see that a SAM 440 ep or a 604e without second level cache or a G3 750FX with 512 kb 2. Level cache give near same performance.

so again here, this test run only in cache and its no real world situation, because in real world 2. level cache give speedup.