Some numbers

GraphBench 1.00 benchmark comparison
========

All values in activity per second (i.e. higher is better)

A is ‘Risc PC 4.02’
B is ‘Risc PC 5.19’
C is ‘Risc PC 4.39’

A is ‘Risc PC 4.02’
B is ‘Risc PC 5.19’
C is ‘Risc PC 4.39’

I assume it is the exact same machine with different ROM/image ?

Lines 1320 = 100% 2334 = 176% 1392 = 105%
Lines (EOR) 1314 = 100% 2315 = 176% 1387 = 105%
Circles 127 = 100% 96 = 75% 129 = 101%
Circles (EOR) 92 = 100% 35 = 38% 93 = 101%

I don’t get why line EOR works at the same speed, but circle EOR (and also RectFill EOR) is so very much slower. That’s bizarre.

Screen copy 50 = 100% 23 = 46% 50 = 100%
Rectangle copy 183 = 100% 88 = 48% 186 = 101%

Likewise this – surely a Screen copy is just a data read/write from here to there? Ditto a Rect Copy (but it may be slightly more convoluted in dealing with numbers of pixels that don’t fit into straight word reads/writes).

If you have time and/or inclination, some other tests that might be more instructive:

• Time from pressing power button to arriving at fully-booted Desktop.
• Time taken to zip up everything in $.!Boot using the archiver of your choice.
• Time taken to copy a large (~40MiB or more) file from here to there; do it twice and average the result (in case auto-defrag should kick in along the way).
• Time taken to make a PDF of a reasonably large document using the software of your choice. Alternatively, if you have enough paper and ink around, the time between pressing “Print” and the final page landing in your printer’s output tray.
• Time taken to compile something large enough that the time taken is meaningful. ;-)

The software you choose is only dependent upon it being the same software in each case.

This, probably requiring the old contraption known as a stopwatch, will hopefully show some example timings performing real-world tasks. It can also exercise other parts of the HAL and not just the graphics code.
It can also give a feel for the comparative speed between RISC OS 4.xx and RISC OS 5 on the same hardware as it is rather easy to get lost in the realm of “look how awesome this is on a 1.5GHz processor” (very, very!).

But, you know, only if you have time free to do such things…

This test from John Kortink: http://web.inter.nl.net/users/J.Kortink/home/articles/graphbench/index.htm (I only changed the used modes)

I assume it is the exact same machine with different ROM/image ?

yes, a Kinetic Risc PC, both 5.19 and 4.39 softloaded

A Kinetic could give very differing results than a standard StrongARM RiscPC.
On a Kinetic some things are processed using the much faster ‘on Kinetic’ RAM others use ‘motherboard’ RAM.
Wouter: Could you try setting the Kinetic into StrongARM mode and retest?

Retested with a standard StrongARM, no big changes
4.39 changes from 105% at Lines, Lines (EOR) and Font plot to 101%, the rest stays the same.
5.19 a Kinetic is 7% to 26% faster at Lines and Lines (EOR), the rest stays the same.

I had thought that on a Kinetic EORing circles and rectangle fills would be slow as presumably it has to read the old data from VRAM but why EORing lines is faster made no sense to my limited brain!
With a StrongARM giving the similar results I obviously know nothing….

Maybe it has to do with the cache(-size), the cpu has a cache and the VIDC doesn’t.
RISC OS 5 and 4 use different graphic algorithms. If RISC OS 5 makes many cpu to/from memory read and writes instead of a few VIDC to/from memory read and writes RISC OS 4 makes, that would explain it. A simple test like “lines” has a higher probability that the needed data is still in the cache.

Time taken to copy a large (~40MiB or more) file from here to there;

*copy 9pi/img 9pi ~C
File ADFS::HardDisc4.$.install.9pi/img copied as ADFS::HardDisc4.$.install.9pi, 450 Mbytes
1 file copied, total 471859200 bytes )

RISC OS 4.02 (10 Aug 1999) (Error number &F7)
00:09:10.567266

RISC OS 4.04 (22 Jan 2001) (Error number &F7)
00:08:51.222704

RISC OS 4.39 (28 Apr 2004) [Kernel 6.80] (Error number &F7)
00:09:00.790507

RISC OS 5.19 (07 Apr 2013) (Error number &F7)
00:08:55.989867

RISC OS 6.20 (01 Dec 2009) [Kernel 10.62]
00:09:04.298305

Are the graphics benchmark differences to do with whether screen memory is cached?