Benchmarks

A quick test of memcpy shows that on an Iyonix with the cache off it can only do 11 MB/s. Unaligned copies are the same speed. So I think that is in line with the slow RAMFS on an Iyonix.

A pi with the cache off does 104 MB/s for aligned copies and 57MB/s for unaligned.

Time for a new computer I think.

Time for a new computer I think.

Yes ;-)
My PandaES copy with a little bit more then 15MB/s with the fastes card I have (64 GB Patriot EP Series).
My i.MX6 is round about 6 times faster via SATA SSD.

@Raik
What speed do you get on PandaEs and iMX6 for the same operations using RAMfs rather than SDfs? Also what spped on iMX6 for memory to menory copy?

I am getting regular, occasional and repeatable crashes on my PandaBoard ES when running at 350/1500 MHz whereas I get none runnng at 350/1200MHz so I intend to withdraw the benchmarks for Panda running at 1500MHz as ‘unstable’.

A heatsink is really needed for normal operation at 1500 MHz.

My PandaES is working with 1,2GHz. Is a reduced setup. Only a fast SD, Cherry stick for wireless keyboard and mouse, monitor, network and a 3A power supplier.
I have a RISCOSmark compared the new tests with my old Panda settings (PandaXL complete with all e.g. CDVD, USB SSD, cardreader etc.). Thanks to Detlef. If anyone will try… download
I’m not a “benchmark” fan. I rely on my feeling at work.
On Panda I only use SDFS, on i.MX 6 only the SSD via SATA. I have a very small case (no space in the workplace) with USB SlimlineCDVD, SATA SSD… Smaller than Andrews at the show and smaller than the ARMini(X). No fan and so not enough ventilation… not more than 800MHz currently.
It wouldt not be fair if I post any bechmarks. The port is stable (more than the xM one as we start with the BIK/ARMini early 2011) but not ready at this time. It is Andrews job to do this ore give the start signal and Andrews SSD is round about 15% faster with the same settings than my. :-(

@Raik,
What rom do you use please for the iMX6?

I is not a free build. Is a iMX6-rom for the peoples are involved in the project. Date is 2014-11-10 I mean. I’m one of the enthusiasts ;-)

With stability much improved and working native HDMI I’ve added the IGEPv5 benchmark results to the below. It should give a rough idea of the expected speed increase.
The IGEPv5 and Pandaboard ES are both running at 1500Mhz. The Beagleboard xM at 1000MHz and the RPi at 700MHz. (Also a stable overclock at 950MHz). VFP is hardware floating point and fpa is softfloat.

flops
                igepv5    igepv5   pes      pes       xm      xm       rpi 700  rpi 950  rpi 700   rpi 950
                vfp       fpa      fpa      vfp       fpa     vfp      fpa      fpa      vfp       vfp
MFLOPS(1)       514.9710  17.5029  15.5761  389.4106  7.9314  63.4146  4.1086   5.9251   128.0246  183.7405
MFLOPS(2)       404.8694  17.2574  14.2849  284.3301  7.2491  52.1245  3.8734   5.5834    83.0849  119.4389
MFLOPS(3)       629.5435  21.9250  16.9423  320.7002  8.2020  57.0487  4.5887   6.6187    95.5322  137.3158
MFLOPS(4)       810.2957  26.0862  18.9992  341.8342  8.8748  60.7553  5.1591   7.4400   105.0884  151.0961


scimark2

Composite Score 415.79    20.20      16.12    196.65    8.11    37.81    3.73     6.28      30.45     49.13

FFT             392.85     9.77       8.33    200.03    4.42    27.25    2.47     3.66      25.00     40.53
SOR             349.09    35.53      29.66    302.03   14.55    54.25    7.00    10.38      52.82     83.64
MonteCarlo      164.18    12.96       9.40     74.98    4.53    18.39    0.69     3.87      17.08     24.58
Sparse matmult  500.27    22.88      17.00    192.19    8.71    53.89    4.43     6.85      26.77     46.55
LU              672.58    19.84      16.22    214.00    8.33    35.26    4.07     6.65      30.59     50.34


whetstone

MWIPS         1163.527   101.814    80.637  1030.875   42.361 207.512  20.529   30.489    210.954   313.151

romark v1.01 (Scores relative to a RiscPC SA 202MHz)

                                             IGEPv5     PES      XM     RPI     RPI
Clock Speed (MHz)                              1500    1500    1000     700     950

Processor - Looped instructions (cache)       2122%    1325%    584%    255%    366%
Memory - Multiple register transfer          22624%    7453%   1969%    483%    769%
Rectangle Copy - Graphics acceleration test   1319%     816%    202%    426%    656%
Icon Plotting - 16 colour sprite with mask    1070%     715%    407%    400%    638%
Draw Path - Stroke narrow line                 658%     479%    241%    244%    365%
Draw Fill - Plot filled shape                  550%     348%    198%    245%    387%

More benchmarks on the IGEPv5, compared to the Panda ES both at 1500 Mhz. As stated elsewhere in the Forum the IGEPv5 really likes sorting. Mandelbrots are also better in general only the single precision VFP one doesn’t fly. May be they abandoned optimisation of that and focused only on double precision (though Chris benchmarks show differently), as one could do almost anything single precision with NEON…or it’s just my accidentally weird code ;-)

              Panda  IGEPv5  Diff
               [s]     [s]    [%]
Mandelbrot
----------
FixPointFrac   1,95    1,55    26
FracNEON       0,70    0,50    40
FracVFP        1,82    2,17   -16

Sorting
-------
OS_Heapsort    1,39    0,48   190
Radix ASM1     0,45    0,08   463
Radix ASM2     0,41    0,05   720
Radix Basic    2,96    1,70    74
ArmSort        0,85    0,42   102
QSort n.rec.   0,23    0,22     5
QSort rec.     0,24    0,24     0

Benchmarks showing partial results for ARMX6 and for Pandaboard ES, Beagleboard XM, Raspberry Pi models 1 and 2,Iyonix and Virtual Risc PC. I hope to add results for ARMX6 soon after the South West show. Interestingly the Pi model 2 is only anout 20% faster than the model B+.

In the table below, the benchmarks are expressed in percentages where 100%=SA202 RiscPC running RISC OS 4.02
These benchmarks have been updated and some ‘real-world’ tasks included to give an indication of overall performance.
A ‘mixed memory and processor’ test has been added (this uses the application !CountDn to calculate the 24 million possible arrangements of the 2, 3, 5, 7, 50 and 75 tiles using all possible combinations of arithmetic operator) – the time taken is given in centi-seconds.
An ‘overall performance’ test has been added (this unpacks the ROM source and compiles it) – the time taken is given.
The disc speed tests now also now include a test of RAMFS speed and use an 8Mbyte file for load and save (HD read and HD write) to make sure it is larger than the cache. Disc speed in ‘real-world’ applications is correlated much more with FS read/write (BPUT & BGET) than with HD read/write (LOAD & SAVE).

Benchmarks for Pandaboard ES running at 1500MHz have been withdrawn due to the unstability of that platform at that speed.

Pandaboard ES running at 1500MHz have been withdrawn due to the unstability of that platform at that speed.

Really? With a small heatsink (borrowed from a Pi), it’s absolutely stable for me…

Nota: it would be interesting to test the Panda with an USB 2 SSD drive.

With a small heatsink (borrowed from a Pi), it’s absolutely stable for me…

With no heatsink and in a ventilated metal case but only showing around 56degC when running at 1500MHz, my Pandaboard ES blew up. It is no more. (etc.) Mine was absolutely stable until it blew up and now it is even more stable!

only showing around 56degC when running at 1500MHz, mine blew up.

You were running a 900MHz Pi2 at 1.5GHz? [amendment noted]

Your Panda blew up.

With no heatsink and in a ventilated metal case but only showing around 56degC when running at 1500MHz, my Pandaboard ES blew up.

There are a lot of ‘hot points’ on the OMAP4 SoC. Even at 1.2 GHz, a heatsink is not an option. It’s even worse with OMAP5 :)

Nota. I have here temp between 70°C and 85°C, even at low clock rates. 85° is almost the limit. I suspect that even at 800 MHz, a Pandaboard ES does not last very long.

I suspect that even at 800 MHz, a Pandaboard ES does not last very long.

That’s not so good for a piece of kit rated 1.2GHz. Heck, these chips are fitted in mobile phones – not much space there for air circulation.

Each time someone tried to use it, there were overheating issues. Last time it was with an Archos tablet.
But it seems to be only hot spots on the chip, so a passive heatsink should do the job.

We’ve had no failures of our PandaROs. Mine is running at 250/1200MHz all day everyday. Heatsink fitted but no fan.

The same here. That’s why I suspect hot spots on the chip. Design problems that make the board sinking/burning if no heatsink. Mine works at 250/1200 or 250/1500 all day. No problem, even if I would like a kind of security measures in the flexdriver (temp to high > switch from 1500 to 1200 MHz). TI is not very good with heat problems.

That’s not so good for a piece of kit rated 1.2GHz.

Don’t assume that it is rated to run at that clock frequency continuously.

Kindle Fire HD also uses TI OMAP4, and I haven’t heard of many problems there.

I wonder if part (possibly a large part) of this issue, if there is one, might be the fact that whilst linux offers dynamic clock-speed variation and temperature sensing, RO doesn’t: with the latter, whatever clock rate is selected applies full-time. Maybe this stresses critical SoC components beyond the expected limits (since presumably they’re designed mostly for linux/linux clone usage).

RISC OS does have SmartReflex – i.e. voltage tuning and switching between fast and slow speed when idling. Don’t think it forces slow when hot though.

Kindle Fire HD also uses TI OMAP4, and I haven’t heard of many problems there.

Yes, but perhaps with a heatsink, or with software underclocking :)

Don’t think it forces slow when hot though.

I don’t think so too.

Anyway, conclusion is that OMAP has a limited lifetime, but – IMHO – it can works at 1500 MHz the same way it will at 1200 MHz (with a heatsink). So it’s not fair not to keep 1500 MHz tests.

I know that my Panda will not work more than 2 or 3 years, but it worked full time (as a server) at 1500 MHz for one year. Not that bad.

since presumably they’re designed mostly for linux/linux clone usage

Probably true. There are so many disk access under Linux that the processor is used at 100% only part of the time. On the other hand, RISC OS can stress the processor full time. For example, since there is no clocked interrupts, you make loops to emulate an ‘every’ command… and the processor works at full speed all the time. RISC OS is a bit too much 8bit’ish sometimes :)

Benchmarks showing ARMX6, Pandaboard ES, Beagleboard XM, Raspberry Pi models 1 and 2, Iyonix and Virtual Risc PC are shown in the table below. Although the benchmarks are expressed in percentages (where 100%=SA202 RiscPC running RISC OS 4.02), actual performance figures for a Risc PC are also shown to allow more direct comparision.

These benchmarks have been updated and some ‘real-world’ tasks included to give an indication of overall performance. A ‘mixed memory and processor’ test has been added (this uses the application !CountDn to calculate the 24 million possible arrangements of the 2, 3, 5, 7, 50 and 75 tiles using all possible combinations of arithmetic operator) – the time taken is given in centi-seconds and allows a comparison for computational tasks that make few disc accesses.

An ‘overall performance’ test has been added (this unpacks the ROM source and compiles it) – the time taken is given for each. This allows more disc-intensive computational tasks to be compared. The fastest time so far is on the Pandaboard using a 500Mbyte RAMFS drive: unpacking takes 41s and compiling takes 4min54sec. Comparison with ARMX6 is not currently possible: the maximum RAMFS size is determined at ROM compile time as it is hard-coded and the ARMx6 RAMFS size limit is currently 128Mbytes.

The disc speed tests now also now include a test of RAMFS speed and use an 8Mbyte file for load and save (HD read and HD write) to make sure it is larger than the cache. Disc speed in ‘real-world’ applications is correlated much more strongly with FS read/write (BPUT & BGET) than with HD read/write (LOAD & SAVE).

Benchmarks for Pandaboard ES running at 1500MHz have been withdrawn due to the unstability/limited lifetime of that platform at that speed.
Note: timings for the Compute Module are very similar to those for the model B+, reading/writing to eMMC being 10Mbytes/s.

Chris, would it be possible to have a later version of the ROM for the Pandaboard.
The reason I mention it, is that I think it’s slower now after the cache controller additions.