Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Piru on February 06, 2012, 09:18:05 PM
-
Here are the results from running the FFTDemo (http://www.hd-rec.de/Archive/FFTDemo.lha) on the target systems. It should be noted that MorphOS and AmigaOS 4 use different just-in-time compiler. This clearly has some impact on the results.
(http://sintonen.fi/pics/68kemu_benchmark.png)
PA6T's strong FPU capabilities are clearly visible when comparing the float results to the integer ones.
sources:
PowerBook G4 1.67GHz and Mac mini G4 1.5GHz results are by me.
AmigaOne X1000 PA6T 1.8GHz result (http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=34495&forum=32&start=80&viewmode=flat&order=0#651289)
Sam 440-EP Flex 800MHz result (http://amigadev.amigaworld.net/modules/newbb/viewtopic.php?topic_id=29964&forum=25&start=40&59#576836)
-
this is 68k compatibility test, how about include original systems, and 68k emu on on other systems like winuae/sys_spec. bernd (i didnt know you trust him suddenly) has provided enough comparisons. otherwise it really starts to look like sole os4/mos contest..,
-
this is 68k compatibility test, how about include original systems, and 68k emu on on other systems like winuae/sys_spec. bernd (i didnt know you trust him suddenly) has provided enough comparisons. otherwise it really starts to look like sole os4/mos contest..,
Adding both classic and very fast UAE setup would likely result in unreadable graph. Maybe some sort of logarithmic chart could work.
However, I have no problem with someone creating the charts with this information.
-
unreadable graph? i dont know. all that has been proven by these graphs is that x1k performs about like an g4mac. this will likely remain readable. instead it would be put into wider perscepctive even if th real hardware would prove damn slow and uae damn fast, we would know where x1k and a mac stand in this comparison.
-
@Piru
Don't be so sure. For E-UAE (slightly old build, though) on my 2.66 GHz Core2 Quad:
Settings:
CPU: 68040
Speed: Maximum
Idle on STOP instruction: off
Memory accesses: all direct (using shmmax of 512MB, total emulated memory of 274MB)
Generate CPU flags: only when needed
ICache flush: soft
Compile through unconditional branch: enabled
JIT FPU compiler: enabled
Translation buffer: 8MB
Speed test for FFT + iFFT: (float)
time needed 612ms for 413696 samples, => 7.66410255432128x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer)
time needed 643ms for 413696 samples, => 7.29460477828979x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer handoptimized 68K ASM)
time needed 301ms for 413696 samples, => 15.5828266143798x speed @44100Hz/stereo
Not that much faster, really.
-
unreadable graph?
Yep. I mean say 68020 at 14MHz would result in a huge bar shrinking the others so that it would be impossible to tell differences between them. Even 060@50 is slow enough to result is quite unreadable graph:
(http://sintonen.fi/pics/68kemu_benchmark2.png)
-
The results for 4.1 running on my humble 603 were rather slower...
Speed test for FFT + iFFT: (float)
time needed 22463ms for 413696 samples, => .208806961774826x speed @44100Hz/stereo
13.06x slower than X1000
Speed test for FFT + iFFT: (integer)
time needed 18830ms for 413696 samples, => .249093517661094x speed @44100Hz/stereo
14.76x slower than X1000
Speed test for FFT + iFFT: (integer handoptimized 68K ASM)
time needed 15410ms for 413696 samples, => .304375797510147x speed @44100Hz/stereo
24.98x slower than X1000
I should check what my actual 68040 manages.
-
@Piru
It would be good to have Pegasos 2 scores for OS4 and MorphOS included in those charts.
Andrew Korn ran Fab's video decode benchmark under OS4 on the Pegasos 2 and I think it was something like 20 seconds slower than under MorphOS on the same hardware.
-
Even 060@50 is slow enough to result is quite unreadable graph:
It would be more readable if you could have the values rotated 90 degrees so that they didn't span the widths of multiple bars. I don't mind having to look at them sideways :)
PS: The 060 results seem a bit skewed to me. Isn't it true that the 060 is pretty good at floating point, particularly the sort of multiply accumulate type stuff FFT involves? I would have expected it to score better than it did. Or rather, not expected the integer version to be that much faster than the floating point one. I guess the code slots into both execution units pretty well?
-
Thanks Piru,
I know some people look on these benchmarks as reflecting negatively on the X1000 because Macs under MorphOS are performing comparably or slightly better.
Obviously, they're ignoring the fact that they also show how much better the PA6T is then the low end PPCs that Acube uses.
AOS users now have access to hardware that gives them parity with MorphOS users (and while expensive its new).
We spent months hearing how the PA6T in the X1000 was going to blow us away, while trying to make our own point that existing data didn't support this.
The PA6T is a nice Soc, but its not the ultimate in performance. It is pretty good though and it will finally allow OS4 users to have a strong performing system (rather then the rather weak ones they've been using).
-
Yep. I mean say 68020 at 14MHz would result in a huge bar shrinking the others so that it would be impossible to tell differences between them. Even 060@50 is slow enough to result is quite unreadable graph:
(http://sintonen.fi/pics/68kemu_benchmark2.png)
68060 faster than emulation on sam440 on integer? and only three times slower than x1k??? if thats is truth then the graphs are actually telling something very unexpected??!"!
edit, and on float sam is only 5-6 times faster than my 060? as far as ive checked the 604/150 was already nearly three times as fast running 68k code.
-
It would be more readable if you could have the values rotated 90 degrees so that they didn't span the widths of multiple bars. I don't mind having to look at them sideways :)
(http://sintonen.fi/pics/68kemu_benchmark3.png)
Slightly better.
PS: The 060 results seem a bit skewed to me. Isn't it true that the 060 is pretty good at floating point, particularly the sort of multiply accumulate type stuff FFT involves? I would have expected it to score better than it did. Or rather, not expected the integer version to be that much faster than the floating point one. I guess the code slots into both execution units pretty well?
Perhaps the compiled version runs into unimplemented 88x FPU instruction? Should try to build it with proper compiler for 68060...
-
Perhaps the compiled version runs into unimplemented 88x FPU instruction? Should try to build it with proper compiler for 68060...
It's written in Blitz Basic by the look of things, not sure which 68K FPU targets are supported by it's compiler these days. ISTR none whatsoever, when I last messed with it.
-
right. i dont remember any optimization options in amiblitz either.
-
On my system with WinUAE 2.4.0 PB 15 with a 68020 cpu.
Speed test for FFT + iFFT: (float)
time needed 644ms for 413696 samples, => 7.28327751159668x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer)
time needed 644ms for 413696 samples, => 7.28327751159668x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer handoptimized 68K ASM)
time needed 267ms for 413696 samples, => 17.5671558380127x speed @44100Hz/stereo
-
The 'OS for the People' looks do do well here. And it is running on a 1st class laptop to boot. Let's see a new round of video based benchmarks (on the same laptop). A refresher course in this wouldn't hurt. Last time I checked the 'OS for the People' ran real good in the video department.