What would a comparison of computers be without benchmarks? As always, choosing suitable benchmarks is a hard task. I have tried to use real-world benchmarks that take long enough to give meaningful results when being hand-timed.
Naturally, all benchmark results were obtained using the same configuration and software version. Unless noted otherwise, tests were done in a 1600x1200@TrueColour (60 Hz) screenmode. Selected tests on the Omega were done in 640x480@16 colours (60 Hz) to show the impact of the Omega's shared memory architecture.
More machines will be added soon - especially my Dell 1 GHz Pentium III-Laptop running Virtual Risc PC.
If anyone wants to check the results on their own machine, or test other interesting machines or specific configurations - just ask and I will provide you with all the necessary files and instructions.
Note: because of a severe lack of time I can't currently provide the benchmark files along with the necessary descriptions to other people. The first few tests from other people have shown that my definitions and instructions are severely lacking in detail, so reproducable results cannot be guaranteed - more work is necessary. There might also be copyright issues associated with my test files, so I will instead produce similar, freely available files and retest. All this requires free time that I currently don't have - in the meantime, I can currently only assure that the results are 100% objective and reproducable.
Note: two results in the Omega column, seperated by /, mean that the same test was done two times with different screen resolutions: first result is in 1600x1200@TrueColour, second result is in 640x480@16 colours. Both with 60 Hz frame rate (LCD, you know). If there is only one result, the test was conducted in the 1600x1200 resolution.
Note #2: the Creator and PackDir benchmarks run under Aemulor on the IYONIX pc.
IYONIX | Omega | Risc PC 1 | Risc PC 2 | Risc PC 3 | Risc PC 4 | |
---|---|---|---|---|---|---|
AWViewer | 6s | 10s | 26s | - | 26s | - |
ChangeFSI | 19s | 40s | 62s | 62s | 64s | 64s |
DPlngScan 1 | 3s | 8s | 10s | 10s | 11s | 11s |
DPlngScan 2 | 5s | 10s | 12s | 12s | 13s | 13s |
DPlngScan 3 | 6s | 25s | 29s | 29s | 31s | 31s |
SparkFS 1 | 29s | 129s/112s | 89s | 89s | 98s | 98s |
SparkFS 2 | 2s | 4s | 7s | 7s | 7s | 7s |
PostScript PDF | 39min | 202min | - | - | - | - |
Filer-Copy | 30s | 104s | - | - | - | - |
Insignia | 7s | 15s | 20s | 20s | 22s | 22s |
Creator | 383s | 785s | 493s | 493s | 511s | 511s |
PackDir 1 | 5s | 12s/9s | 8s | 8s | 8s | 8s |
PackDir 2 | 15s | 46s/38s | 23s | 23s | 23s | 23s |
As can easily be seen, the IYONIX pc offers a massive speed advantage over both the trusty old Risc PC machines and the Omega as well. Surprisingly, the few tests done with Aemulor show the same picture: while this could be expected from the Creator benchmark (because it is very disc-intensive, where the IYONIX pc has clear advantages at the moment), the PackDir one is really surprising. I have to admit that I have no idea why even a Risc PC can out-perform an Omega here. But the Aemulor results illustrate nicely what performance can be achieved with the emulation technique used and the delegation of OS calls to the full speed of RISC OS 5 running on an XScale.
The AWRender benchmark shows that the Omega is actually faster than the IYONIX pc when accessing screen memory: the speed advantage of the IYONIX pc is less than the expected 2× minimum from the other tests.
Many tests, including the PostScript to PDF conversion, the Creator conversion and the SparkFS compression, are quite disc-intensive. Once a UDMA implementation becomes available for the Omega, these will have to be retested to see how much the Omega can catch up.
To show the impact of the Omega's shared memory architecture, some processor-intensive tests have been conducted in two vastly different screen modes (which therefore also have vastly different bandwidth usage). The Omega was normally used in a true-colour screen mode of 1600×1200 resolution at 60Hz, but for these more demanding tests it was switched down to a 16-colour 640×480 mode at 60Hz. It is surprising to see that even the comparatively bandwidth-saving StrongARM is slowed down by as much as 20% when using the large screen mode. Hopefully MicroDigital will optimize its FPGA programming to mitigate these problems; it remains to be seen how successful such efforts can be, however, as the fundamental problem will not go away.
Home | © 2003 Steffen Huber, steffen@huber-net.de |