Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => General Internet News => Topic started by: rachy on August 18, 2003, 11:24:41 AM
-
I published new benchmarks on my web pages from the recent vesion of the dynamic recompiling based M68k emulator for AmigaOS4.
This version is already converted to AmigaOS4, and running on the native PowerPC system.
Petunia homepage (http://amigos.amiga.hu/rachy/petunia.html)
-
One comment: Wow ! :)
-
Oh boy oh boy oh boy!!!!
-
This version is already converted to AmigaOS4, and running on the native PowerPC system.
Is this to interpreted as "the integration of the emulator is
complete"?
.
SlimJim
-
No, the actual integration is primarily the work of a different developer.
The concept is however finalised and implementation can begin now that Petunia is running on OS 4 using an application launcher.
-
Faaaaaast 8-)
-
It's easy to amuse Natives .. :-D
-
It's easy to amuse Natives
But harder to please amiga owners. :-)
-
Looking good so far.
-
Amigamad:
True.. so true ... :-)
-
sweet :-)
-
Great, great!
Tcho,
Glames
-
MorphOS 1.4 JIT on 603/240 system is several times faster than the Petunia on 604/180.
c2ptest is over 3.5 times faster, mandel over 2.5, demoeffect over 1.5 times faster.
Remember that CSPPC has twice as fast memory bus, too. The Petunia page describes the A4000 CSPPC test machine to run OS 4.0, so there is no more WarpOS overhead in the results(?).
So does this mean Trance is much faster, or did I miss something?
-
@ Piru
MorphOS 1.4 JIT on 603/240 system is several times faster than the Petunia on 604/180.
Does MorphOS 1.4 run on anything else than the Pegasos??
If not, then why do you troll?
-
Just wait until the entire graphics subsystem runs PPC native and then compare again.
-
>Does MorphOS 1.4 run on anything else than the
>Pegasos??
Yes it also runs on Piru's BPPC, hence how he got the benchmark results. Duh!
-
Maybe someone could re-code the apps he's using to benchmark Petunia so that they don't render anything, just do the calculations (so we can factor out the graphics subsystem).
As it is these Petunia benchmarks are disappointingly slow... I was expecting much more, given all the hype that has been spread about it over the last year or so. :-(
-
Just wait until the entire graphics subsystem runs PPC native and then compare again.
Excuse my ignorance but isn't the graphics subsystem JITted aswell?
And even if it wasn't:
mandel does no OS calls in innerloop. It has 4 exec calls, 2 intuition calls and 200 graphics calls.
c2ptest does no OS calls in innerloop. It has 4 exec calls, and two intuition calls. It does open graphics.library but does nothing with it.
demoeffect does no OS calls in innerloop. For CGFX it has 14 exec calls, 3 dos calls, 1 cybergraphics call, 2 intuition calls and 2 timer.device calls.
Could you please explain how graphics subsystem being 68k can have such an impact on the results?
[EDIT: Added exact number of OS calls]
-
@hnl_dk
@ Piru
MorphOS 1.4 JIT on 603/240 system is several times faster than the Petunia on 604/180.
Does MorphOS 1.4 run on anything else than the Pegasos??
Yes. It runs on CyberStorm PPC and Blizzard PPC boards. I performed the tests on my A1200+BPPC system.
If not, then why do you troll?
I don't.
-
@ Piru
Thanks for the clarification :-D
About the graphics subsystem ... IIRC one of the Friedens told some time ago that the 68k system components use the interpreted emulation ... Petunia is for aplications only ... but I might be wrong ;-)
-
About the graphics subsystem ... IIRC one of the Friedens told some time ago that the 68k system components use the interpreted emulation ... Petunia is for aplications only ... but I might be wrong
I read that somewhere too. Didn't that have something to do with reliability?
-
Edit by Kees - Please solve this matter in private.
-
Edit by Kees - Please solve this matter in private.
-
Edit by Kees - Please solve this matter in private.
-
HyperionMP:
Scroll up, and what you see?
"AmigaOS4 Petunia benchmarks"
It's not equivalent to "Piru's BPPC"
So, do you have anything to say about the subject?
(Of course, no-one prevents you from starting other thread with that "other" subject...)
-
great work ... but i think morphos jit is faster (?)
besides all this : have you seen the stats button at the bottom of the page ? press it and wonder about the 18th :-D
-
BenH. I really don't know what's been going on between you two in past
(and I really don't want to hear all gross details).. I just have to
say this is quite strange place and time to do any collecting of old
debts. You both must have each others E-mail addresses (or at least
able to get one ) not to mention post regularly to various boards.
Besides this must be real old stuff cause Piru has been on
mos-development quite a while?
So why here and now? Is this just normal
evasive-truth-avoidance-routine ... :-?
-
>So why here and now? Is this just normal
>evasive-truth-avoidance-routine
Afraid not, it was the knee jerk reaction of somebody who was stupid enough to trust somebody and was ripped off by the person for more than 1000 euros.
-
more than 060 50Mhz in a "poor" 604 180Mhz? And you say slow? Shut up piru.
-
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...)
-
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).
-
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.
-
Well.. I guess it doesn't matter if you want to call Petunia "slow" or
Trance "fast". :-)
-
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.
-
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 ;)
-
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.
-
>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.
-
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.
-
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]