Benchmarks

Has there been any benchmarks for USB3?

No. I have just updated the benchmarks for the Raspberry Pi Zero – almost identical to timings for a model A+ (despite the supposed difference in speed from 700MHz to 1000MHz – this seems to be misinformation about the Zero).

Updated benchmarks again for Pi Zero, this time using the correct config.txt commands to make sure it runs at its rated speed of 1000MHz, viz.

/# bootcode.bin commit id 4a66b501473024c143c8c34fb670e009b6a8b8ff
/# fixup.dat    commit id 47bd0f0f46bc053d8e21655e3a69c4a73ae19b41
/# start.elf    commit id 47bd0f0f46bc053d8e21655e3a69c4a73ae19b41
fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=48
init_emmc_clock=100000000
arm_freq=1000
gpu_freq=300
core_freq=400
sdram_freq=450
force_turbo=1
kernel=RISCOS.IMG

Some very strange results there! Up to five faster but also up to six times slower than a Pi2 @ 900MHz.

Only the memory benchmark for the Zero is slower than for the model B2 (and RAMfs write speed) not sure why. The others are all (pretty much) faster or the same. Don’t understand your comment. Have you pressed the refresh key on your browser?.

Only the memory benchmark for the Zero is slower than for the model B2 (and RAMfs write speed) not sure why.

The BCM2836 cache structure is radically different to the BCM2835, in the Zero the core has a 16KB L1 data and 16KB L1 instruction cache, the 128KB L2 cache is tied to the GPU. In the Pi2 each core has a dedicated 32KB L1 data and 32KB L1 instruction cache and there’s a dedicated 512KB L2 cache across all cores, the GPU has a seperate L2 cache.

Benchmarks updated for ARMX6 (10-Jan-2016) rom (audio over HDMI, large screen modes).

May I also suggest an update to the Pi2 benchmarks, bearing in mind that amending Config.txt with specific CPU, core and RAM frequencies makes such a dramatic improvement (cf. this thread https://www.riscosopen.org/forum/forums/1/topics/3803?page=5
)?

RISCOSmark 2.01 (23-Sep-2015) by Richard Spencer 2003
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

Filing system: SDFS:RISCOSpi.$.Public
Graphics Resoloution: 1280x720, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)                   670698     377%
Memory - Multiple register transfer                         7961    4914%
Rectangle Copy - Graphics acceleration test                 1084     447%
Icon Plotting - 16 colour sprite with mask                 12012     600%
Draw Path - Stroke narrow line                              4595     294%
Draw Fill - Plot filled shape                                805      55%
HD Read - Block load 8MB file                              11538     386%
HD Write - Block save 8MB file                             13003     427%
FS Read - Byte stream file in                                397     191%
FS Write - Byte stream file out                              199     103%

Here we are having fun benchmarking the RISCOSpi. During the test, I noticed the second item (memory) is out of alignment with the other results indicated in this thread (4914 vs <2000). I’m using the Pi2. Just curious about it…

RISCOSmark 2.01 (23-Sep-2015) by Richard Spencer 2003
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

Filing system: SDFS:RISCOSpi.$.Public
Graphics Resoloution: 1280x720, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)                   670698     377%
Memory - Multiple register transfer                         7961    4914%
Rectangle Copy - Graphics acceleration test                 1084     447%
Icon Plotting - 16 colour sprite with mask                 12012     600%
Draw Path - Stroke narrow line                              4595     294%
Draw Fill - Plot filled shape                                805      55%
HD Read - Block load 8MB file                              11538     386%
HD Write - Block save 8MB file                             13003     427%
FS Read - Byte stream file in                                397     191%
FS Write - Byte stream file out                              199     103%

Here we are having fun benchmarking the RISCOSpi. During the test, I noticed the second item (memory) is out of alignment with the other results indicated in this thread (4914 vs <2000). I’m using the Pi2. Just curious about it…

Never mind – the other results mentioned were for the Pi (not Pi2).

I’m using the Pi2. Just curious about it….

The Processor result you’ve got suggests that the Pi2 is running at approx. 600MHz. You can force it to run at full speed by inserting the following lines in Boot-Loader-Config.txt, after ‘kernel=RISCOS.IMG’:

force_turbo=1
arm_freq=900
core_freq=250
adram_freq=450

This is not overclocking as such; the Pi2 is being made to run at full speed all the time, not at higher-than-full speed. As I understand it, under linux the processor can react to increasing loads by speeding up dynamically, but this feature is not currently available under RISC OS – what you have under RO without the additional lines above is the normal ‘slow speed’ processor state, approximately 600MHz. Disclaimer: there is no guarantee that you are not shortening the Pi’s life by making it run permanently close to its red line! For me, the extra performance is worth it.

You can force it to run at full speed by inserting
the following lines in Boot-Loader-Config.txt, after
‘kernel=RISCOS.IMG’:

force_turbo=1
arm_freq=900
core_freq=250
adram_freq=450

Hi George:
I took your advice, and I have to say it results in a very noticable improvement, as the redo of the benchmark shows…

Test                                                   Benchmark

Processor – Looped instructions (cache)                   998523     561%

Memory – Multiple register transfer                        11683    7211%

Rectangle Copy – Graphics acceleration test                 1213     501%

Icon Plotting – 16 colour sprite with mask                 11084     554%

Draw Path – Stroke narrow line                              3667     235%

Draw Fill – Plot filled shape                                660      45%

HD Read – Block load 8MB file                              10051     337%

HD Write – Block save 8MB file                               595      19%

FS Read – Byte stream file in                                492     237%

FS Write – Byte stream file out                              181      94%

It’s snappier now. Thanks!

Actually, I’ve reverted to the slower speed now. The SoC chip runs with practically no heat when I’m in slow mode. More importantly for me, the 4800 maH battery will last longer! I really don’t find the RISCOS GUI objectionably slow without the extra speed.

Actually, I’ve reverted to the slower speed now.

Fair enough! My Pi2 runs off mains electricity so power consumption is not an issue. On the temparature issue, I did discover an interesting thread here:
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100130
where, amongst other things, one poster suggests the Pi2 chip may be hard-coded to switch off at 85C. – does anyone have any information on this?

There have been some comments that pure benchmarks (like ‘processor’ or ‘memory’) do not reflect ‘real-world’ performance so I have added another ‘real world’ performance item – rendering the ArtWorks Apple. The Risc PC does this 9.06 times per second (using 32k colours, it is about 30% faster in 256 colours) and I have set this speed as ‘100%’. I have then used DrawFile_Render on each platform (at 16M colours) to get a comparative timing. This has now been added to the table.

It is noticeable that native ARM hardware is now faster than any emulation. (Ducks!)

The ROMark programme, updated to do an ‘ArtWorks apple’ test is here

Where do I have to save the ArtWorks Apple to get ROMark 5 to ‘see’ it? At the moment it fails at Test 7 with the error: “File ‘Apple4_d’ not found in line 420” (I’m running ROMark 5 from the same directory as the Apple4_d file, as unzipped).
Secondly, when are we going to have ‘proper’ benchmarks for the Pi2, i.e., when run at its maximum safe speed of 900MHz, rather than the 600MHz default speed? Ronald’s post above shows the kind of improvement available.

“File ‘Apple4_d’ not found in line 420”

The Apple file needs to be in the current directory.

Raspberry Pi Mk2 900MHz
Processor - Looped instructions (cache)     1036505     582%
Memory - Multiple register transfer           14502    8951%
Draw Render - Render draw file                 5408     596%

VRPC iMac
Processor - Looped instructions (cache)      519273     291%
Memory - Multiple register transfer            8849    5462%
Draw Render - Render draw file                 7502     828%

There seems something weird with the benchmark. The apple rendering figure for Raspberry Pi 900MHz Model B2 RC14 doesn’t make sense. The 700MHz Pi B1+ is 222% the speed for a RiscPC at FullHD resolution. The Pi Zero clocking 1GHz is 300% the speed of a RiscPC at FullHD. Yet the 900MHz Pi B2 (at FullHD) is barely faster than a RiscPC at only 137%.
Why this anomaly? I’d have expected something in the ballpark of 270-280%.

Also, I wonder if you should configure the machines to 1024×768 (and optionally at 32Kcols) because you aren’t comparing like with like. If we’re rendering full screen, the difference between the base RiscPC (786,432 pixels) and the other machines (all FullHD, 2,073,600) is 1,287,168. Or a little over two and a half times more pixels. Would the new devices be able to render the drawing significantly faster at a matching screen resolution?

Now that I know how to run the Drawfile test, I have done so; this Pi2 scored 234% on each of 3 tests, clocked at 900/450/450 (cpu/core/ram). Screen res is 1920 × 1080 × 16M. I’m running RC14, non-zero page.

While considerably better than the 137% in the official benchmark, the difference with David’s results are nonetheless intriguing: my Pi2 is giving identical cpu and memory values to his, but roughly half the Drawfile rendering speed. Could SD card speed be implicated here?

I have repeated the benchmarks for the model 2 B (at 1000MHz) and the model B+ (at 850MHz).

the difference with David’s results are nonetheless intriguing:

My results above were with a high vector ROM and a SCSI SSD.

A bit more intrigue then, below the test is repeated with high and low late 2015 ROMs :-

MOS Utilities 5.23 (01 Dec 2015)
Version number: RISC OS 5.23
Build date    : Tue,22 Dec 2015.16:29:26
Vectors at 0 : Size 256bytes
Processor - Looped instructions (cache)       984352     553%
Memory - Multiple register transfer            13854    8551%
Draw Render - Render draw file                  4305     475%


MOS Utilities 5.23 (01 Dec 2015)
Version number: RISC OS 5.23
Build date    : Sun,20 Dec 2015.04:24:00
Vectors at FFFF0000 : Size 256bytes
Processor - Looped instructions (cache)      1036152     582%
Memory - Multiple register transfer            14237    8788%
Draw Render - Render draw file                  5413     597%

In general the low vector ROM is 6% slower than the high vector ROM but some tests do vary from that.

I have noted that the tests at 1000MHz with the model 2 B Pi run more slowly than the previous 900MHz tests with the older firmware. The newer firmware will default to 600MHz unless you set the turbo mode (which I have done) but will also go to slow mode if the chip overheats. The chip seems rather hot at 1000MHz and I suspect it has slowed down at some point in the tests. By the time I do the ROM unpack and compile it is significantly slower than before. Compiling and unpacking to RAMfs runs full speed though (i.e. faster than before).

The newer firmware

Dated?

The chip seems rather hot at 1000MHz

ISTR the little leaflet that came with my Pi specifically warned against /over/clocking (rightly or wrongly, I’ve taken this to mean anything up to 900MHz is OK…).

ISTR the little leaflet that came with my Pi specifically warned against /over/clocking (rightly or wrongly, I’ve taken this to mean anything up to 900MHz is OK…).

They used to, but then about two years ago came to the conclusion that you couldn’t damage the hardware by over clocking (I think it crashes before doing damage) and stopped saying it voided the warranty.
I believe over volting does still void the warranty.

Benchmarks updated for the Pi model 3. Some software won’t run on the model 3 – Netsurf, LANMAN98 and !UnTarBZ2 for example, so not all benchmarks are filled in.

The CONFIG/TXT I used is:

fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
#gpu_freq=300
#arm_control=0x1000
avoid_warnings=2
force_turbo=1
arm_freq=1200
core_freq=450
sdram_freq=450
kernel=RISCOS.IMG