AmigaOS4 Petunia benchmarks

[rachy]

Let's make some things clear:

1. In every test emulation setup time calculated into the results. It takes 1.5 secs for a simple "RTS" program. (Later this time will be gone, eg. buliding jump tables take a lot of time, but it has to do only once.) So, I could decrease the running times with this value, but I want to be as correct as possible, and that vaules wouldn't be the ones what I actually measured.

2. Emulation is highly clock-speed dependant. On a 604/233 system results were a lot better, than on 604/180 actually is. (I could have explanation for this, but it is not really interesting, rather technical.) I had just no opportunity of getting such system right now. So, measuring the speed on a higher clocked system WILL imply better results.

3. The tests are sort. This is true, but on some system these tests take AGES to run. At the beginning I had a slower machine, and the emulation was slower too, that is why I chose these tests. Now everything run better, but I don't want to change the tests, because of these are the base of comparsion of the recent results.

4. Emulation is beta, not finished yet. AOS4 is beta not finished yet. I have ideas for improvements, but right now I am about stabilization and integration.

(BTW, I don't know what is wrong with julia test, it is running just fine on AmigaOS3.x, AmigaOS4 and UAE. Except MorphOS. Where is the fault then?  :-D Just a joke, don't take too serious...)

[jacadcaps]

Of course it's slow. It doesn't matter if it's faster than 060 if it runs half the speed it could get on PPC (or even less).

[jacadcaps]

2. You say it's clock dependant? Actually I launched some petunia tests on my 603/175 machine and demoeffect got 50 fps, c2ptest took around 6 seconds and mandelbrot took less than 4 seconds.

[Merko]

Well.. I guess it doesn't matter if you want to call Petunia "slow" or
Trance "fast". :-)

[rachy]

Just to let you know: I installed PPC based DOS to my AOS4 snapshot today morning (I used the emulated DOS up to now) and init of Petunia goes a lot faster. Eg. mandel test runs around 4 secs WITH the init...

Ok, I stop here now. Had enough for today.

[itix]

more than 060 50Mhz in a "poor" 604 180Mhz? And you say slow? Shut up piru.

More than 060 100MHz in a "very poor" 603 175MHz is really cool

[itix]

3. The tests are sort. This is true, but on some system these tests take AGES to run. At the beginning I had a slower machine, and the emulation was slower too, that is why I chose these tests. Now everything run better, but I don't want to change the tests, because of these are the base of comparsion of the recent results.

Running some real apps could be more fair in the future... Also making tests on OS4 without JIT could be interesting. To see how much PPC native OS can speed up 68k apps in the interpretive mode etc.

[zacman]

>more than 060 50Mhz in a "poor" 604 180Mhz?
>And you say slow?

If you see that with some other JIT emulation you
can get more than three times better results on a
slower machine then this *is* slow.

[Piru]

1. In every test emulation setup time calculated into the results. It takes 1.5 secs for a simple "RTS" program. (Later this time will be gone, eg. buliding jump tables take a lot of time, but it has to do only once.) So, I could decrease the running times with this value, but I want to be as correct as possible, and that vaules wouldn't be the ones what I actually measured.

The whole running time is included in the Trance results aswell, including the setup time.

Also, the Petunia website lets you believe the emulation is almost finished (just some tuning left). I'm sorry but I assumed the results were from the finished emulation. Sorry for my misinterpretation.

2. Emulation is highly clock-speed dependant.

I have found it not to be so. It's linear to CPU performance here, not to clock speed.

On a 604/233 system results were a lot better, than on 604/180 actually is. (I could have explanation for this, but it is not really interesting, rather technical.)

Well, DUH! It's hardly a rocket science to realize the same CPU with higher clockrate is faster, now is it?

Also, the busclock affects the memory access speed, as well as the memory speed settings. But, 604 has 64-bit access to memory whereas 603 has only 32-bit, so most memory related operations are faster on 604 regardless of bus speed. This definetely affects the benchmarks that work on memory (most of them do, mandel and julia are mostly compute bound).

I still find it interesting that Trance on 603/175 beats Petunia on 604/180, however. Must be the jumptable setup you go on about?

I had just no opportunity of getting such system right now. So, measuring the speed on a higher clocked system WILL imply better results.

3x and 2x better?

3. The tests are sort.

Short you mean?

This is true, but on some system these tests take AGES to run. At the beginning I had a slower machine, and the emulation was slower too, that is why I chose these tests.

Why not run the tests for specific time instead? Say 20 seconds. Should not be too hard to implement.

Also the tests should all include internal timer and result reporting.

(BTW, I don't know what is wrong with julia test, it is running just fine on AmigaOS3.x, AmigaOS4 and UAE. Except MorphOS. Where is the fault then? Just a joke, don't take too serious...)

Runs fine on my Pegasos, due to luck. The julia_fpu code has two serious bugs.

[Piru]

BTW, I don't know what is wrong with julia test, it is running just fine on AmigaOS3.x, AmigaOS4 and UAE. Except MorphOS. Where is the fault then?

In julia_fpu code. Read WriteChunkyPixels autodoc carefully and fix it. Hint: You depend on two side-effects, which both are against the programming guidelines.

[edit: more friendly, added hint]