Follow on to GCC/DDE

I’ve been investigating various approaches to writing RISC OS apps, I’ve done a good chunk of C and BASIC, but of course there are alternatives, however they seem very fringe.

So my list is C (both variants), BASIC, Lua and Charm. Has anybody ever done a comparison of compile times and benchmarked the resulting executables? For the record, I’m a bit of a language guy, with my own personal benchmark suite including my personal productivity with around 30 languages. I use this to decide what to use, on Linux I use Python or Rust depending on the project.

Compiled BASIC looks interesting, but I suspect it might be easier just to use a language that is designed to be compiled to avoid compromise.

Apologies if it seems like I’m spamming the forum, just want to get a cleared idea before embarking on anything heavier.

I’m sure there have been at least one or two cases where people have compared the (runtime) performance of different languages, but I can’t remember where I saw them. However I suspect they’ve mostly focused on only a couple of languages, rather than aiming to cover “everything” like you’re interested in.

Recently I used GCC to benchmark some audio mixing code on a number of different RISC OS machines, and with different compiler settings + source optimisations. So not really what you’re after, but maybe it’ll give you some food for thought: https://www.iconbar.com/articles/Adventures_in_Optimisation_-_Audio_mixing/index1486.html

Hi Jeffrey, I had actually come across that article before and was part of the reason I ported my performance test over to RISC OS (as well as my Master 128 with Pi co-pro). The M128 was insanely slow, with a co-pro was around a 1000 times faster and the Pi itself on RISC OS was many, many times faster again.

I guess I’m somewhat procrastinating, but I have a 30,000 line 2D Java “game” I want to look at partially porting for a bit of fun. It’s just using 32bit sprites with a whole load of floating point stuff for physics and collisions etc.

I could probably do it in BASIC, but I know from Java that I had to do a lot of tweaking and that’s on substantially faster hardware with a JIT. The modern JVM is amazing performance wise, if VERY memory hungry.

C is great, but the whole compile/link cycle can be a little slow sometimes. Java at least was pretty quick to hit Run and see the result.

It inspired me to fire up my old project, I forgot I had done all my own 3D models, explosion sprite strips, etc. I had modelled everything down to upgradeable hardpoints, drones and damage affecting different ship systems in different ways.

No idea if the following links will work, but I’ll stick them here just in case.

https://ibb.co/xY5tXB9
https://ibb.co/R6BRQ4V
https://ibb.co/5rB7JtR
https://ibb.co/DkqvTqH

I really should get it finished. I would like to do it on RISC OS, but we shall see.

I could probably do it in BASIC

Now, would that be BASIC with its own custom FP, BASIC that uses the FPEmulator, or BASIC that uses the hardware VFP? They’re all in there. ;-)

At the moment, the DDE doesn’t support VFP. Your floating point will be assembled as FPA instructions, which are emulated. Yes, it hurts.
I think GCC can output VFP (I don’t use it).

C is great, but the whole compile/link cycle can be a little slow sometimes. Java at least was pretty quick to hit Run and see the result.

Once you have a MakeFile set up to “just build it”, pressing Ctrl-Shift-C in Zap will throw that MakeFile at AMU so it can “just be built”. Let it get on with it in a TaskWindow, it is almost as easy as a nice friendly “Run” button.

The M128 was insanely slow

It was fast in its day. But a 2MHz processor doesn’t get you anywhere these days.

You want slow, try the Electron… ;-)

It took me 30 minutes to get through the broken login system, FFS :-(

Is there a BASIC with VFP? I see threads on it, but figured it was a WIP at best?

BTW, my GCC code compiled for VFP is blazingly fast compared to FPEmulator. Tens of thousands of gouraud shaded, 3d transformed polygons per seconds, with hardly any optimisation done. If targeting modern machines I don’t see the point of doing anything else! However, I would prefer the simplicity of BASIC combined with small snippets of ARM assembler when needed. Productivity counts!

Is there a BASIC with VFP?

Yes – RISC OS 5.24 and later should include it.

*BASIC64 will select either FPA or VFP depending on the hardware. You can also use *BASICFPA and *BASICVFP if you want an explicit version.

I did not know that, I need to go and do some benchmarking now!

Thanks Jeffrey.

PS. I’m a long term Acorn guy, but only recently back into RISC OS since the Pi 1. Still finding my feet!

A quick test:

Normal BASIC V: 1.55 seconds
VFP BASIC VI: 5.11 seconds
FPA BASIC VI: 7.68 seconds

It’s almost entirely floating point calculation with lots of trigonometry. Still feel the VFP version should be faster though?!

Yeah, the VFP version is a bit half-and-half. The FPA instruction set included trig operations, which the FPA version of BASIC64 makes use of. But the VFP instruction set doesn’t include trig operations, so the current VFP version of BASIC takes the easy way out and uses the FPA instructions instead.

Also bear in mind that BASIC V is using 5-byte floats with custom routines. You loose precision but keep a lot of speed. I have a module that allows you to use VFP for trigonometry etc, but there did not seem to be that much demand, so it is not really finished for release.

I was surprised that the routines of your VFP module didn’t found their way into the VFP BASIC.

So, for completeness:

BBC Basic (BASIC): 16.45 seconds
BBC Basic (BASICVFP): 58.4 seconds
BBC Basic (BASICFPA): 87.1 seconds
C (SharedCLibrary): 54.79 seconds (presume this is using the FPEmulator?)
C (float-abi=soft): 21.47 seconds (presume this is using GCC’s software fp?)
C (VFP): 1.15 seconds
C (NEON): 1.11 seconds
C (NEON with unsafe): 1.10 seconds

Confusing results for me, obviously GCC with VFP is the fastest by far.

For reference, a modern PC does it in 0.09 seconds (in C), 0.009 seconds using 8 Ryzen cores (in Rust) and a regular Master 128 in BASIC in around 10-30 hours (estimated based on 1 run, no way I can wait that long!) and ~13 minutes using a PiTubeDirect.

C (SharedCLibrary): 54.79 seconds (presume this is using the FPEmulator?)
C (float-abi=soft): 21.47 seconds (presume this is using GCC’s software fp?)

Correct on both counts.

https://www.iconbar.com/articles/Adventures_in_Optimisation_-_Audio_mixing/index1486.html
Iconbar is offline

It’s working for me.