Benchmarks

@chris: Ah ok :(

Benchmarks updated for newer ROM and faster SD card for Pandaboard ES.

In the table below, the benchmarks are expressed in percentages where 100%=SA202 RiscPC running RISC OS 4.02

Five of the benchmarks were very dependent on the screen mode used and so I have repeated them at different screen resolutions of
800×600 C256, 1024×768 C32k, 1280×1024 C16M and the highest resolution available at 16M:

* – 1920 × 1080 C16M
+ – 1600 × 900 C16M

Benchmarks (updated for newer ROM and faster SD card for Pandaboard ES).

In the table below, the benchmarks are expressed in percentages where 100%=SA202 RiscPC running RISC OS 4.02

I have added the time for a real-world task, which is processor intensive and in BASIC.

BeagleBrd XM 800 MHz

Should we assume the ARmini is the 1GHz version?

And the real world task is?
Comparing Overclocked (Highly overclocked in the case of the Pandaboard)systems with standard clocked systems does rather skew the results!
Also file tests will vary massively if you compare FAT format storage with Filecore format (SCSIFS & SDFS currently has no caching)
The file system tests may also be more of a test of the Mass storage device itself e.g. a USB SSD drive will give different results to USB spinning drive of the same format.

And the real world task is?

Exactly. OvationPro loads and works. Compile jobs are quick. But it can’t cope with even a moderate sized XviD, but reboot is fast enough that forgetting to stack R14 in SVC isn’t a crisis. ;-)

Those are my benchmarks.

(Not sure why this white space appears!)

* – 1680 × 1050 C16M

For the sake of completeness here are figures for RPCEmu running on a Win7/64 PC with a fairly fast processor (Intel Core i7 quad-core 3.4GHz). Screen display is 1824 × 1026 × 16M in both cases. The first percentage is for 089/402, the second for 0810/520 (not completely consistent I know, but the speed difference between 089 and 0810 is not greater than 5% AFAIK).

Processor – Looped instructions (cache) 335% 335%
Memory – Multiple register transfer 6068% 6057%
Rectangle Copy – Graphics acceleration test 1328% 1507%
Icon Plotting – 16 colour sprite with mask 335% 490%
Draw Path – Stroke narrow line 197% 267%
Draw Fill – Plot filled shape 247% 319%
HD Read – Block load 1MB file 693% 3263%
HD Write – Block save 1MB file 832% 2541%
FS Read – Byte stream file in 1184% 1741%
FS Write – Byte stream file out 900% 1747%

The advantage of a full 32-bit OS under emulation is clearly shown, notably in the HD and FS operations.

Benchmarks updated for new Windows7/RISCCube PC with a SSD HDD, which has shown significant performance increases.

In the table below, the benchmarks are expressed in percentages where 100%=SA202 RiscPC running RISC OS 4.02

* – 1680 × 1050 C16M

Benchmarks comparing the same SD card image on a Raspberry Pi Model B (512Mbytes) and a Pandaboard ES, with figures from Virtual Risc PC as well.

In summary, disc read and write using VRPC is unbeatable. Raw power on the Pandaboard is impressive. Processor speed on the Raspberry Pi is equivalent to the fastest VRPC but VRPC still has the edge (over the Pi) for memory access speed.

In the table below, the benchmarks are expressed in percentages where 100%=SA202 RiscPC running RISC OS 4.02

Thanks for the update. Very usefull.
I suggest to give numbers for a (very) stable overcloked Pi (900/300/500/500 or 900/250/450/450?)

Here’s a few benchmarks to give an idea of the relative performance of RISC OS running on OMAP5 (1GHz IGEPV5) compared to OMAP4 (1.5Ghz Pandaboard ES).

I tried running the IGEPV5 at 1.5GHz but RISC OS hangs on boot up. There’s no display support at the moment so everything is run from the supervisor prompt via serial port.

-                                        IGEPV5 1GHz  Pandaboard ES 1.5GHz

-                                        cortex-a15   cortex-a9
povray -w1024 -h768 +a0.3 teapot.pov     12s          12s         time for povray 3.6.1 using hardware vfp

shine test.wav test.mp3                  14s          19s         time to encode 3min track, fixed point mp3 encoder

dhrystones per second                    3120000      4350000

First two RISCOSMark benchmarks:

Processor – Looped instructions (cache)  1415%        1310%

Memory – Multiple register transfer      14382%       7990%

Looks like clock for clock the IGEPV5 is about 50% faster than a Pandaboard ES and anything memory intensive is faster still. Dhrystone is about the same. I assume it’s because it fits in the CPU cache.

Is getting RISC OS to work on OMAP5 looking feasible? Display support etc.? If so, I might get one…

The main reason is the SATA port, so that we can get some faster HDD read/write speeds [150MB/s, 300MB/s or 600MB/s depending whether it is SATA I, II or III] not being dependent on the USB system.

Anyone know what sort of magnitude writing a RISC OS SATA driver is?
e.g. Bigger than USB or WiFi?
Is a linux port on the cards?
Then the big one: Has anyone skilled enough got the time and motivation?

One possible problem is documentation. We have been able to get a lot of the OMAP4 documentation either public or under NDA but there is some HDMI documentation that they so far haven’t let us have:-( The main OMAP5 datasheet is public and we have been able to get the datasheets for the support chips but still needs the missing documentation.

You would hope that the SATA hardware interface had a legacy mode then it may be made to work with existing software.

Even without Sata support, at 1.5 GHz, the speed up could be very interesting. Fingers crossed for audio/video support.

i.MX6 and OMAP5 support are very good news for RISC OS community, even if the Pi stays today the best offer. I hope, that one day some legacy chips (Cortex-A9 and Mali) will be supported too. BananaRISCOS :)

Hi Chris what MLO & u-Boot are you using on your omap5?? i have been testing different builds on omap5 evm with Willi but no usb after booting rom or uImage

In PC world, the SATA chips always have a “legacy IDE mode” which is 100% compatible with the good old way of accessing IDE. You cannot use fancy DMA stuff or command queueing, but RISC OS would not profit from these things anyway.

@David
iMX6 and OMAP5 support (with suitable HAL¹ tweaks for specific boards) actually opens up the potential for a RO laptop. The Sabre Lite dev kit looks to contain everything CJE seem to be trying to put together from bits.²
So, if Chris donated for work on iMX6 HAL work he could make his DIY lappie³ kits with a more powerful processor than planned and at an end user cost that didn’t make peoples eyes water.

¹ That nice three letter acronym again – without the HAL it’s all just wishful thinking. Although JB might be on this track already.
² LVDS as well as HDMI, SATA.
³ Those who look on the appropriate Farnell page will note a matching display that would make a decent tablet… Nah, dreams only

Correction: opens up many many possibilities :)

In PC world, the SATA chips always have a “legacy IDE mode” which is 100% compatible with the good old way of accessing IDE.

Of course if someone added HAL support for AHCI then the SATA in default mode is a possibility.
Oh look perhaps someone thinks it might be a good idea…

I wondered what AHCI was.

“If” RISC OS supported DMA for SATA, would it be possible to have “async” I/O, in theory?
i.e. please write/read this area of memory to disc, then come back and ask how much of it has been done?

I wondered what AHCI was.

Top link is reasonable

“If” RISC OS supported DMA for SATA, would it be possible to have “async” I/O, in theory?
i.e. please write/read this area of memory to disc, then come back and ask how much of it has been done?

Given that the boards with SATA seem to be dual core at least I suppose you could make a case for running a core as a rather over spec intelligent disc i/o controller.

Perhaps we should wait until there is an available HAL for a suitable board before too much wishful thinking.

Given that the boards with SATA seem to be dual core at least I suppose you could make a case for running a core as a rather over spec intelligent disc i/o controller.

That would give more sense to an AMP mode with two sessions of RISC OS running on each cores…