Iyo/RPi benchmark conundrum

In Archive 23/4 I wrote an article about Charm and included some benchmarks comparing C, Charm, RiscLua and Basic on the Iyonix with two test programs. One, FNCALL, did 10,000,000 function calls, the other, SIEVE, used Eratosthenes’ sieve to generate the first 1000 primes a 1000 times. I have now run these (without recompilation) on the RPi for comparison. Most of the results show the speedup one might expect – spectacularly so in the case of SIEVE in C and Charm where the time drops from 37 centiseconds to 7 and from 36 to 13 respectively. But there was an anomaly: for SIEVE in Basic the time rose from 1113 centiseconds to 1123.
It occurred to me that this might have something to do with the use of floating point numbers, so I wrote a RiscLua test program that multiplied 2.5 with 3.5 10,000 times: on the Iyonix this took 38 centiseconds, but on the RPi it took 72 – nearly twice the time. I note that the FPEmulator module is in the RISC OS distribution for the RPi. Am I right in thinking that FP instructions compiled on the Iyonix will use soft floats, i.e. the FPEmulator, on the RPi, but not hard floats. Can I presume that the shared C-library on the RPi has been recompiled to use hard floats? What about Basic?
If I compile a C program with the ROOL C/C++ Norcroft compiler on the RPi will it use hard or soft floats? How do I tell GCC 4.1.2 to use hard floats on the RPi?

Note: I’ve not tested this on RISCOS yet – but on Raspbian, passing -mfloat-abi=hard to gcc did the trick. For soft floats, it’s -mfloat-abi=softfp

Like I say, I’ve not tried either of these on RISCOS yet. I used both methods a few months ago calculating pi on a pi to see the effects of different ways of handling floating point stuff. Not surprisingly, it made a big difference.

Firstly, please forgive my hopeless newbie-ness. I’ve only been using gcc on RISC OS for 2 days. And anyway, what I know about gcc could be written on the inside of the ear of a small mouse.

Since typing the above reply, I dug out my old pi_css5 test program that I used originally, and played with it. Firstly, tried compiling with -mfloat-abi=softfp:

*make gcc -Wall -pedantic -O -fomit-frame-pointer -funroll-loops -march=armv6 -mfloat-abi=softfp -c pi_fftcs.c -o pi_fftcs.o pi_fftcs.c:1: sorry, unimplemented: arm-unknown-riscos and -mfloat-abi=softfp make: *** [pi_fftcs.o] Error 1

mmm, not exactly what I was looking for. So, let’s try -mfloat-abi=hard:

*make gcc -Wall -pedantic -O -fomit-frame-pointer -funroll-loops -march=armv6 -mfloat-abi=hard -c pi_fftcs.c -o pi_fftcs.o gcc -Wall -pedantic -O -fomit-frame-pointer -funroll-loops -march=armv6 -mfloat-abi=hard -c fftsg_h.c -o fftsg_h.o gcc -Wall -pedantic -O -fomit-frame-pointer -funroll-loops -march=armv6 -mfloat-abi=hard pi_fftcs.o fftsg_h.o -lm -static -o pi_css5 /SDFS::RISCOSpi.$/Apps/Development/!GCC/bin/ld: error: pi_fftcs.o uses hardware FP, whereas pi_css5 uses software FP /SDFS::RISCOSpi.$/Apps/Development/!GCC/bin/ld: failed to merge target specific data of file pi_fftcs.o /SDFS::RISCOSpi.$/Apps/Development/!GCC/bin/ld: error: fftsg_h.o uses hardware FP, whereas pi_css5 uses software FP /SDFS::RISCOSpi.$/Apps/Development/!GCC/bin/ld: failed to merge target specific data of file fftsg_h.o collect2: ld returned 1 exit status make: *** [pi_css5] Error 1

Better, but still nothing I can really do anything with. So, in the end I just removed the -mfloat parameter, and let gcc get on with the floats itself. The program compiles OK, but is desperately slow to execute. By way of comparison, using -mfloat-abi=hard on Raspbian Wheezy calculates 131072 digits of pi in ~7 secs. On RISC OS with gcc handling the floats, it’s ~80 secs. Which isn’t surprising really, but I’d like to be able to pass the floats off to the hardware rather than emulating them in software.

The version of gcc you’re using doesn’t support producing hardware floating point binaries. It uses the old fpa softfloat library which as you’ve noticed is very slow.
There is a version of gcc 4.7.3 that can utilise the vfp in the raspberry pi but it’s not released yet. You have to build it yourself from source.

pi_css5 131072 takes 1 second on a Pandaboard @1.6GHz and 5.22 seconds on a Raspberry Pi @950MHz.

Ah, thanks for confirming that. I also learned to RTFM¹ which led me to the fact that -mfloat-abi=hard and =mfloat-abi=softfp were never going to work anyway… Hey ho. Learn something new every day :)

¹ http://www.riscos.info/index.php/GCCSDK_Development

Ta,