29-Mar-2024 14:01 GMT.
UNDER CONSTRUCTION
Anonymous, there are 58 items in your selection [1 - 50] [51 - 58]
[News] New Project Petunia benchmarksANN.lu
Posted on 30-Apr-2002 20:45 GMT by Álmos Rajnai58 comments
View flat
View list
I placed new benchmarks to my web pages from the recent vesion of the dynamic recompiling based M68k emulator for AmigaOS4.

I placed new benchmarks to my web pages from the recent vesion of the dynamic recompiling based M68k emulator for AmigaOS4.
For more check out Project Petunia pages.

New Project Petunia benchmarks : Comment 1 of 58ANN.lu
Posted by Graham on 30-Apr-2002 18:47 GMT
http://amigos.amiga.hu/rachy/petunia.html
Heh, ANN.lu always turns right angle brackets into >, thus messing up links! :)
New Project Petunia benchmarks : Comment 2 of 58ANN.lu
Posted by Graham on 30-Apr-2002 18:55 GMT
Now I have read that, it appears a lowly 604@200 can emulate an '060 at 50MHz with ease, surpassing it in many places, sometimes by a factor of two.
Considering the 600MHz G3 on the AmigaOne has full speed memory and a much more modern architecture, we can expect 68k emulation in the realms of a 150MHz 68060 at the minimum, possibly more like 200MHz given the architectural improvements, and in some applications it will appear to be even faster.
Good stuff.
New Project Petunia benchmarks : Comment 3 of 58ANN.lu
Posted by Álmos Rajnai on 30-Apr-2002 18:59 GMT
Ah, where is the URL? Please, somebody correct it!
New Project Petunia benchmarks : Comment 4 of 58ANN.lu
Posted by SlimJim on 30-Apr-2002 19:53 GMT
Sure looks promising.
.
SlimJim
New Project Petunia benchmarks : Comment 5 of 58ANN.lu
Posted by the man in the shadows on 30-Apr-2002 20:35 GMT
In reply to Comment 1 (Graham):
> Heh, ANN.lu always turns right angle brackets into >, thus messing up
> links! :)
Not really, you typed it in wrong: <a href="http://amigos.amiga.hu/rachy/petunia.html>Project Petunia pages</a> should have been: <A HREF="http://amigos.amiga.hu/rachy/petunia.html>Project Petunia pages</A>
Note the upper case characters. The rule number 5 states: "Linking is done via standard HTML markup, ie. <A href="http://anna.amigazeux.org">ANN</A> will link to ANN." but doesn't take into consideration that it is case sensitive. Perhaps a recomendation to CK to make note of that in the rules. Something like this should suffice:
14. All html markup must be in upper case.
--
Back to the topic at hand... 68K software should all out fly on a G3. Thanks for your efforts in this project.
New Project Petunia benchmarks : Comment 6 of 58ANN.lu
Posted by Graham on 30-Apr-2002 20:50 GMT
In reply to Comment 5 (the man in the shadows):
I didn't submit the news, I just posted the URL from the HTML source that was messed up so that people could actually see the benchmarks before the submission was fixed.
New Project Petunia benchmarks : Comment 7 of 58ANN.lu
Posted by anonymous on 30-Apr-2002 21:03 GMT
So when does this thing get optimized?
New Project Petunia benchmarks : Comment 8 of 58ANN.lu
Posted by Budda on 30-Apr-2002 21:07 GMT
In reply to Comment 5 (the man in the shadows):
Isn't there just a quote missing in the line
<a href="http://amigos.amiga.hu/rachy/petunia.html>Project Petunia pages</a> ????
New Project Petunia benchmarks : Comment 9 of 58ANN.lu
Posted by catohagen on 30-Apr-2002 21:07 GMT
In reply to Comment 7 (anonymous):
when Petunia runs on AmigaOne, maybe optimizing won't be needed :)
New Project Petunia benchmarks : Comment 10 of 58ANN.lu
Posted by Anonymous on 30-Apr-2002 21:55 GMT
In reply to Comment 7 (anonymous):
Do you mean, "please"...
New Project Petunia benchmarks : Comment 11 of 58ANN.lu
Posted by the man in the shadows on 30-Apr-2002 23:44 GMT
In reply to Comment 8 (Budda):
Oops... missed the quote... but the html elements should still be upper case. At least that's what I've found to work best whenever posting to ANN.
New Project Petunia benchmarks : Comment 12 of 58ANN.lu
Posted by acg on 01-May-2002 02:07 GMT
Sounds good. Hope it works very well, and gets more support
especially from Hyperion/AmigaInc.
New Project Petunia benchmarks : Comment 13 of 58ANN.lu
Posted by Don Cox on 01-May-2002 02:08 GMT
In reply to Comment 2 (Graham):
You ought to get nearly half the CPU speed from a JIT emulator, so a
600MHz CPU should give you around a 280MHz 68040.
I get roughly 600-700MHz equivalent on Amithlon - most programs run at
10-12 times the speed of the 68060. Maurizio reports much faster
results from ProStation Audio.
The drawback? It needs a lot of RAM to store converted code. Don't
install less than 512 Megs on your AmigaOne. On Amithlon around 100
Megs goes on the emulator.
New Project Petunia benchmarks : Comment 14 of 58ANN.lu
Posted by Anonymous on 01-May-2002 03:09 GMT
Strange...story appears broken in my browser--an ANN error?
New Project Petunia benchmarks : Comment 15 of 58ANN.lu
Posted by Sjoerd on 01-May-2002 05:11 GMT
Did you look ad the version of 30 april??
V0.34 ?? long way it seems towards version 1.0 which should be in OS4 IMO
Bye,
Sjoerd
New Project Petunia benchmarks : Comment 16 of 58ANN.lu
Posted by anon on 01-May-2002 05:29 GMT
In reply to Comment 9 (catohagen):
This sounds exactly like "lets use windows, I've got a 2ghz cpu here". So, MHz justify unoptimized bloatware?
Anyway, lets wait and see. At least the 68k emulator has a name you can reffer to, which seems to be important for most people ;)
New Project Petunia benchmarks : Comment 17 of 58ANN.lu
Posted by Ben Hermans/Hyperion on 01-May-2002 07:45 GMT
In reply to Comment 2 (Graham):
On a 600 Mhz G3 with on-die L2 cache and a 133 FSB, you can expect much more than a 150-200 Mhz 060.
I would consider a 300 Mhz 060 to be the absolute minimum.
The current benchmarks of Petunia are being held back by several factors even on the current PPC cards:
1. The 68K is still stealing cycles from the PPC just by being "awake". If you put it to sleep completely, this results in substantial performance gains.
2. Dual CPU architecture with context-switches and cache-flushes.
3. WarpOS not Exec SG is used.
All in all I expect the emulator to reach at least 060/50 performance even on the lowest (160 MHz) BlizzardPPC.
New Project Petunia benchmarks : Comment 18 of 58ANN.lu
Posted by Crumb on 01-May-2002 07:59 GMT
wow! it's fast! now the only thing I need is a ppc board ;)
New Project Petunia benchmarks : Comment 19 of 58ANN.lu
Posted by Anonymous on 01-May-2002 09:16 GMT
In reply to Comment 15 (Sjoerd):
I wouldn't read too much into a version number. It can mean whatever the developer wants it to mean really... just have to wait and see,
New Project Petunia benchmarks : Comment 20 of 58ANN.lu
Posted by Graham on 01-May-2002 09:22 GMT
In reply to Comment 17 (Ben Hermans/Hyperion):
I was being conservative of course.
Now when OS4 arrives on the AmigaOne we can do some proper benchmarking of classic 68k applications running on a modern PPC motherboard, I would like to see compared (by the people that do it):
Stock A1200 (with extra RAM, lets be fair here!) for amusement purposes
'030@25MHz (A4000/030)
'040@25MHz (A4000/040)
'060@50MHz (as per accellerators)
Test image processing, 3d rendering, compression/decompression time, RTG capable demos, etc.
Graham
New Project Petunia benchmarks : Comment 21 of 58ANN.lu
Posted by IanG on 01-May-2002 10:05 GMT
Very nice to see such progress on this project. Without meaning any insult to the other excellent work happening for OS4, I feel the 68K emulator is one of the most important parts of the whole, because it will provide the back-compatibility of the existing software. Without a large easily accessable software base a new platform will struggle badly.
Completely irrelevantly, but out of curiosity, I wonder why the TAS and CAS instructions, which are officially not allowed in Amigas, and the rarely-used CMP2, CHK2 implemented, but not the more common 020+ BFTST, BFSET, etc, stuff? (Yet...)
New Project Petunia benchmarks : Comment 22 of 58ANN.lu
Posted by José on 01-May-2002 10:08 GMT
In reply to Comment 17 (Ben Hermans/Hyperion):
If that comes to reallity I might get a Blizzardppc(from someone buying A1 of course:)) while I wait for the socketed A1 version.
New Project Petunia benchmarks : Comment 23 of 58ANN.lu
Posted by NoctReX on 01-May-2002 11:05 GMT
petunia is impressing indeed!
hope with some optimzing it will go even faster than that!
also hope that DIGI Booster Pro will fly on this !
at this moment, on my Athlon XP 1800+ with Amithlon and WinUAE-JIT
the windows redrawing is SLOWWWW!!!
Even my A1200/030@33 beats Amithlon when DIGI Booster draws the Config window...
New Project Petunia benchmarks : Comment 24 of 58ANN.lu
Posted by Don Cox on 01-May-2002 11:17 GMT
In reply to Comment 20 (Graham):
There's a useful Imagine benchmark test project here
http://www.cadtech.demon.co.uk/PPC_graph.htm
This will also test the FPU section of the emulator. Of course, you
use it with the 68k version of Imagine to test the emulator, not with
the PPC rendering engine.
New Project Petunia benchmarks : Comment 25 of 58ANN.lu
Posted by Don Cox on 01-May-2002 11:20 GMT
In reply to Comment 23 (NoctReX):
"also hope that DIGI Booster Pro will fly on this !
at this moment, on my Athlon XP 1800+ with Amithlon and WinUAE-JIT
the windows redrawing is SLOWWWW!!!
Even my A1200/030@33 beats Amithlon when DIGI Booster draws the Config
window... "
That seems to be a P96 problem. AmigaOS 4 uses P96 too. Let's hope
they fix it. Window redrawa are very slow in all programs.
Personally, I would rather have CGFX.
New Project Petunia benchmarks : Comment 26 of 58ANN.lu
Posted by Jon on 01-May-2002 11:56 GMT
In reply to Comment 25 (Don Cox):
Have you guys tried to adjust some priority values? When I use Executive, Digibooster Pro is fast, otherwise it draws windows very slowly.
Too bad I cannot use DBPro at all. At least the demo 2.21 crasher (or hangs) when I try to use 16-bit mode. Don't know what's wrong.
New Project Petunia benchmarks : Comment 27 of 58ANN.lu
Posted by redrumloa on 01-May-2002 12:27 GMT
In reply to Comment 25 (Don Cox):
>That seems to be a P96 problem. AmigaOS 4 uses P96 too. Let's hope
>they fix it. Window redrawa are very slow in all programs.
>Personally, I would rather have CGFX.
P96 problem? I doubt it. It must be the fact Amithlon actually uses linux drivers for gfx cards.
P96 on my Prometheus/Voodoo3 3000 was extremely fast. I never noticed redraws.
New Project Petunia benchmarks : Comment 28 of 58ANN.lu
Posted by Álmos Rajnai on 01-May-2002 12:32 GMT
About version number: it shows the count of the internal beta releases, nothing more. (Especially does not show the distance from the public release version... :)
About bitfield operations: you are right, now I am trying to get them working. In fact, those opcodes are the most complex onces, that is why I left them to the end. (Some of them are working more or less, but I have to work on them yet.)
About optimalization: yes, there is yet some place for it, but most of the slowdown caused by the context-switch (cache invalidation), and it will disappear together with the dual processor system.
New Project Petunia benchmarks : Comment 29 of 58ANN.lu
Posted by tinman on 01-May-2002 13:05 GMT
In reply to Comment 25 (Don Cox):
Sounds like a problem you used to see in WinUAE when using the BlitzBasic debugger. It used to use WaitTOF_ from graphics.library(), and when you have a graphics card driver that does not produce interrupts (such as the WinUAE P96 driver) your system dies on it's feet.
New Project Petunia benchmarks : Comment 30 of 58ANN.lu
Posted by Jacek Piszczek on 01-May-2002 13:21 GMT
In reply to Comment 26 (Jon):
>Too bad I cannot use DBPro at all.
>At least the demo 2.21 crasher (or hangs) when I try to use 16-bit mode.
>Don't know what's wrong.
It's a bug in DBPro. Please note that DB gui isn't 100% gadtools compatible
& the whole program is pure 68k asm. DigiBooster does some forbidden things
both with AHI and AmigaOS (intuition/graphics/gadtools). It's a luck it still
works with AHI5.x
BTW: using a JIT compiler won't sppedup DB, since all cpu-eating stuff is done by AHI,
not DigiBooster.
New Project Petunia benchmarks : Comment 31 of 58ANN.lu
Posted by Christian Kemp on 01-May-2002 14:51 GMT
In reply to Comment 1 (Graham):
Wrong, the HREF had an opening quote, but no closing quote.
New Project Petunia benchmarks : Comment 32 of 58ANN.lu
Posted by DaveW on 01-May-2002 16:26 GMT
Great news, great specs... well done.
New Project Petunia benchmarks : Comment 33 of 58ANN.lu
Posted by Jon on 01-May-2002 18:22 GMT
In reply to Comment 30 (Jacek Piszczek):
So probably the full version won't solve my problem?
It's fun that it works on many other people's machines. Mine is with 040/PPC and OS 3.9.
Too bad that OctaMED SS doesn't support AHI :((((((((((((
New Project Petunia benchmarks : Comment 34 of 58ANN.lu
Posted by Jon on 01-May-2002 18:27 GMT
In reply to Comment 30 (Jacek Piszczek):
Luckily AHI will be PPC version too :)
New Project Petunia benchmarks : Comment 35 of 58ANN.lu
Posted by Bill Hoggett on 01-May-2002 22:00 GMT
In reply to Comment 27 (redrumloa):
>>That seems to be a P96 problem. AmigaOS 4 uses P96 too. Let's
>>hope they fix it. Window redrawa are very slow in all programs.
>>
>>Personally, I would rather have CGFX.
>
>P96 problem? I doubt it. It must be the fact Amithlon actually
>uses linux drivers for gfx cards.
No, because WinUAE wouldn't be affected in that case.
Actually it is a P96 driver problem, and just needs a better driver, which is being worked on for v2.0 of Amithlon.
New Project Petunia benchmarks : Comment 36 of 58ANN.lu
Posted by Dynamic Recompilation, or JIT... on 02-May-2002 05:05 GMT
Just wanted to point out this technology: dynamo. Go here to see about it: http://www.hpl.hp.com/cambridge/projects/Dynamo/ and also here for a quick discusion: http://www.arstechnica.com/reviews/1q00/dynamo/dynamo-1.html.
Basicly, what they are doing is showing that a JIT like system can run code as fast or FASTER than just running it directly. That is, for example, a PPC could run a PPC emulator with JIT and actualy wind up with better performance! This is possible because of many optimizations that can be done only in such an envirionment (IE, stuff a compiler couldnt do).
Now of course, mapping from 68k to PPC is not a one to one match so some efficiency would be lost. But I think if they included technology similar to this dynamo we could get really amazing performance...
New Project Petunia benchmarks : Comment 37 of 58ANN.lu
Posted by kjetil on 02-May-2002 05:10 GMT
In reply to Comment 35 (Bill Hoggett):
IF you do not have Accelerated or supported GFX card in Linux, things like window redrawing goes extremely slow, and if you have problems with the emulation in edition to the badly written ASM code, it all piles up,
PS. ASM code do not mean it’s not system friendly it’s just more likely that the person doing the program has read the Hardware reference manual not the C manual, and Autoexec stuff,
There can be more then one reason for slow performance this is way benchmarks are so silly in a way.
The new OS4.0 will not have 68k Exec it will have ExecSG this means all takes will have 68k API emulation environment to deal with this will in some cases slow thins down in otter case speed thins up with an factor 1000,
New Project Petunia benchmarks : Comment 38 of 58ANN.lu
Posted by Jacek Piszczek on 02-May-2002 05:27 GMT
In reply to Comment 33 (Jon):
>So probably the full version won't solve my problem?
No.
>It's fun that it works on many other people's machines. Mine is with 040/PPC and OS 3.9.
DBPro should work on 8bit screenmodes. It works OK here on BVision.
New Project Petunia benchmarks : Comment 39 of 58ANN.lu
Posted by Jacek Piszczek on 02-May-2002 05:32 GMT
In reply to Comment 34 (Jon):
>Luckily AHI will be PPC version too :)
AHI PPC is available on author's page for over 2 years.
On PPC 603e 175MHz it's possible to listen 20 track DBPro mods
in Paula 48KHz HiFi stereo++ with echo turned on on all tracks :))
New Project Petunia benchmarks : Comment 40 of 58ANN.lu
Posted by Jacek Piszczek on 02-May-2002 05:41 GMT
In reply to Comment 37 (kjetil):
>PS. ASM code do not mean it's not system friendly it's just more
>likely that the person doing the program has read the Hardware
>reference manual not the C manual, and Autoexec stuff,
The problem with DBPro is that the authors IGNORED warnings in AHI autodocs
and did some gadtools tricks in the GUI.
DBPro code is just very lame...
New Project Petunia benchmarks : Comment 41 of 58ANN.lu
Posted by kjetil on 02-May-2002 06:32 GMT
In reply to Comment 40 (Jacek Piszczek):
I’m lame programmer my self, I do not make the best of every line I write,
I do not make sore to limit number of loop’s in sub functions and I do skip reading on the GUI stuff, The idea that my programs going to last more then 1 to 5 years at the most I do think is an good estimate, so way make things perfect, most likely there will be some conception or there will new demands for my program, this means there will be time to change or update it performance wise,
I never written one line in DBPro, and never looked at one ASM line of DBPro so I do not know the state of the program, I have never looked at DBPro as a program, butt in general, I can say, programs are as good at the programmer ides and effort to make the ides come true.
How ever I have looked the Hardware Reference Manual, it’s all about have you address the Amiga hardware, there NO or equivalent to NO talk about API’s and OS stuff, the book explains how easy it’s to make MOVE.M to joystick port or setting up the serial port by using the register.
In facet there are more talk about API’s and OS stuff in the BlitzBasic manual J
And I do believe if you have read the Hardware reference manual before you read the Amiga Programmer Manual, you probably stick to the things you know best hardware, addressing hardware are not always as hard as you my think.
New Project Petunia benchmarks : Comment 42 of 58ANN.lu
Posted by Jon on 02-May-2002 06:44 GMT
In reply to Comment 38 (Jacek Piszczek):
I have tried AGA too. I remember having tried also a different AHI version.
It hangs when I press 16-bit gadget or try to load some Soundstudio/s3m/etc song.
4ch mods work ok I guess.
New Project Petunia benchmarks : Comment 43 of 58ANN.lu
Posted by Jacek Piszczek on 02-May-2002 06:50 GMT
In reply to Comment 41 (kjetil):
Who said DBPro is based on Amiga hw documentation ?? Of course it's based on OS
and OS autodocs, etc. You can't a hw based program that uses AHI, because of
AHI's structure, hooks, functions (DBPro uses the AHI library part).
DBPro doesn't check the mouse buttons with BTST, it uses normal IDCMP flags
of intuition. What I'm saying is that DPPro for example uses AHISF_IMM in
SoundFunc (forbidden in ahidev.guide). I emailed Martin Bloom about this
and he said it was luck DBPro still works.
New Project Petunia benchmarks : Comment 44 of 58ANN.lu
Posted by Anonymous on 02-May-2002 09:45 GMT
In reply to Comment 36 (Dynamic Recompilation, or JIT...):
> Basicly, what they are doing is showing that a JIT like system can run code
> as fast or FASTER than just running it directly. That is, for example, a PPC
> could run a PPC emulator with JIT and actualy wind up with better
> performance! This is possible because of many optimizations that can be done
> only in such an envirionment (IE, stuff a compiler couldnt do).
I think that is unrealistic. A *good* compiler will get most optimisations sorted out, and even unroll loops, remove constant terms etc. By your argument above, all you need to do is run a JIT compiler on the code produced by the JIT compiler for even more performance. And the run it over that again...
New Project Petunia benchmarks : Comment 45 of 58ANN.lu
Posted by kjetil on 02-May-2002 10:07 GMT
In reply to Comment 43 (Jacek Piszczek):
One thing I do not understand about AHI, way do all AHI programs use manual unit numbers,
Way not do AHI unit scan find one free,
Int unit;
While ( fdOpenDevice(“AHI.device”,unit) == 0 );
CloseDevice(fd);
New Project Petunia benchmarks : Comment 46 of 58ANN.lu
Posted by kjetil on 02-May-2002 10:11 GMT
In reply to Comment 45 (kjetil):
Int unit;
Unit0;
While ( fdOpenDevice(“AHI.device”,unit) == 0 ) { unit++; }
CloseDevice(fd);
New Project Petunia benchmarks : Comment 47 of 58ANN.lu
Posted by Martin Blom on 02-May-2002 10:29 GMT
In reply to Comment 45 (kjetil):
AHI units do not become busy when in use.
New Project Petunia benchmarks : Comment 48 of 58ANN.lu
Posted by Graham on 02-May-2002 11:00 GMT
In reply to Comment 44 (Anonymous):
Even the best compiler cannot know how code will run in real life, unless you do some extremely computationally heavy analysis of the generated code.
Fact is, Dynamo made PA-RISC applications run even faster when put through a JIT compiler when running the app. You won't get improvements by putting it through twice - your logic is extremely faulty.
So theoretically, you could get improved PPC performance by having a PPC variant of Dynamo that takes decently generated PPC code (from gcc, not the best compiler in the world) and then further optimises it when running. Hell, it could then save the resulting code back to disk and the next time you can bypass the JIT and just run the enhanced code.
New Project Petunia benchmarks : Comment 49 of 58ANN.lu
Posted by kjetil on 02-May-2002 11:43 GMT
In reply to Comment 47 (Martin Blom):
Way not? Scsi deviece will not open if it don’t exist, so way not.
New Project Petunia benchmarks : Comment 50 of 58ANN.lu
Posted by Martin Blom on 02-May-2002 12:00 GMT
In reply to Comment 49 (kjetil):
How do you mean? A unit (0-3) will not open if the specified hardware is not present or used by another application in exclusive mode, of course. But if the hardware is free, there are no upper limit of the number of applications that can use the unit. The sound of each user will be mixed, or, if the total number of channels is exceeded, sent to void.
Anonymous, there are 58 items in your selection [1 - 50] [51 - 58]
Back to Top