RISC OS; Pros and Cons

You do have me curious, I am going have to look at the source for BBC BASIC V and see what is making this difference. My RPi is running withe the ARM at 600MHz, and SDRAM at 500MHz. I do not see how the SDRAM speed could make that much of a difference for this though maybe so, I have tried it with the ARM at 550MHz with the same exact results.

David your implementation of Ackermann is using integer variables while pygmy_giant's used floating point. this, I would suggest, would cause a noticeable difference in performance. As you know an integer in BBC BASIC fits neatly in one 32bit register - BBC BASIC V's FP format on the other hand doesn't (it's 40 bit). This would mean the use of slower Floating Point maths operations and also if values are being stacked the floating point values would require twice as many registers to be pushed/popped at each iteration than the Integer one (as the stacking would be occurring into SDRAM then the RAM speed might well have a bearing - possibly more so than the overall processor clock speed which is always greater than the RAM speed in any event).

I think these little differences are instructive as they show how to code for greatest efficiency and how important it is to compare "like with like" - Steve Drain's observations about using an iterative rather than recursive method to achieve the same end as Ackermann probably highlights that choosing the *right* algorithm from the start can be more productive than simply "tweaking" a suboptimal one....

You do have me curious, I am going have to look at the source for BBC BASIC V and see what is making this difference

Good luck with that. You might like to look at the BASIC StrongHelp manual (http://www.kappa.me.uk/basic.htm) that I maintain, which has a lot of detail about how BASIC works and uses the stack.

David your implementation of Ackermann is using integer variables while pygmy_giant's used floating point. this, I would suggest, would cause a noticeable difference in performance.

Yes it will. In addition to the points you made, BASIC V stores its 40-bit values byte aligned, so that involves unaligned loads and saves. Sophie Wilson used a clever bit of code to do this, but it is nevertheless a bottleneck. In general I reckon floating point operations are about 25% slower than integer.
I have just tried using the 64-bit version, BASIC VI. On the Pi I think this uses the floating point processor and comes in at 1.15 sec, compared to 1.20, for my last bit of code. This is not so with old machines using the Floating Point Emulator (FPE) which is slooow.

choosing the *right* algorithm from the start can be more productive than simply "tweaking" a suboptimal one....

There have been many BASIC libraries over the years that have relied on crunching applications to improve their speed, but have some horribly slow algorithms in the first place. Fortunately, BASIC V is inherently fast enough to diguise this, and after all, most of the time in the Desktop is spent waiting for user input.
[plug]Of course, the answer is a judiciously constructed keyword. My Basalt module (http://www.kappa.me.uk/basalt.htm) extends BASIC V in a large number of ways and is not far off the speed of native BASIC. Other solutions are also available.[/plug]

I have just tried using the 64-bit version, BASIC VI. On the Pi I think this uses the floating point processor and comes in at 1.15 sec, compared to 1.20, for my last bit of code.

Where can I get BASIC VI for my Pi ?

Basalt - 'hand crafted machine code' eh? - ah regex - fun!

@Steve: Thanks for the additional background information and the links.

I'll download the BASALT zip (and manual) and give it a try, thanks again.

Hey look - robot using RISC OS and BASIC: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=32145&p=276855&hilit=robot#p276855

A page or so back pygmy_giant asked about the performance differences between RISC OS Squeak and linux Squeak; I forgot to answer.

I'd be stunned if there was much difference overall - after all it's the same C code that makes up almost all of the virtual machine. The platform related code that handles input events, copying the display pixels to the actual display, socket & file handling code are all fairly different, as you'd expect. The other big difference is the C compiler and I'm quite certain that in some places NorCroft will be slower than gcc and in some places faster.

On linux the VM will be interrupted at times to run some other program or one of them eeeeeevilll demons that spawn-of-satan-unix uses. On the other hand the RISC OS VM will be interrupted to do a wimp-poll, by assorted interrupt handlers deep in the bowels of RISC OS and possibly the need for a cup of tea (being British). I'm fairly sure I need to find a clean way to slow down the rate at which wimp-polls are done; 12000 per second is a bit much.

As mentioned before, it all comes down to what you measure and how, and what you think that means. Similarly, I'm working on improvements for both OSs as fast as I can, commensurate with making a living and staying subscribed to the 'food on the table club'.

Hey look - robot using RISC OS and BASIC: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=32145&p=276855&hilit=robot#p276855

Thanks for that pygmy_giant, looks like a very interesting project (and more than proves that RISC OS and BBC BASIC V is up to the task of robotic control).

Thanks for Ackermann 's because I'd never even heard of it. What puzzles me most about it is why DavidS's raspi significantly outperforms mine when Ackermanning. Are you sneakily underclocking something DavidS? S'bliddy clever!

Ackermann's as benchmark reflects stack efficacy? Riscos performs how well in that respect to other OS? It does seem best though, in programming terms, to curb recursion when possible.

You do have me curious, I am going have to look at the source for BBC BASIC V and see what is making this difference. My RPi is running withe the ARM at 600MHz, and SDRAM at 500MHz. I do not see how the SDRAM speed could make that much of a difference for this though maybe so, I have tried it with the ARM at 550MHz with the same exact results.

Well, here's 'my' Ackermann - 2.11 seconds (lol) on a stock Pi and 1.52 seconds with all the stops nearly all the way out.. (stock meaning default configuration file)

[REM <---------------------------->
REM < Ackermann benchmark >
REM < reflects stack efficiency >
REM < lower is better >
REM < -------------------------- >
REM < 2.11 seconds on stock rpi >
REM <============================>

REM Turn en error reporting
ON ERROR REPORT:PRINT " at line ";ERL:END

REM Variable/Constant declarations
Zero%=0:YLimit%=3:XLimit%=7:O1%=1:MOne%=-1:Centi%=100

REM Hide text cursor
OFF
REM Hide mousepointer
MOUSE OFF
REM Display title
PRINT"ACKERMANN TEST"
PRINT"Started.."
REM Initialise timer
TIME=FALSE
REM execute inner and outer loops
FORY%=Zero%TOYLimit%
FORX%=Zero%TOXLimit%
REM Output result of Ackermann function
PRINT FNA(Y%,X%);
REM Inner loop return..
NEXT
REM Carriage return
PRINT
REM Outer loop return..
NEXT
REM Display benchmark in seconds
PRINT"DONE IN ";TIME/Centi%;" SECONDS"
REM Re-enable text cursor
ON
REM Re-enable mouse pointer
MOUSE ON
REM Exit interpreter
END

DEFFNA(M%,N%)
IFM%ANDN%>FALSE:=FNA(M%+MOne%,FNA(M%,N%+MOne%))
IFM%=FALSE:=N%+O1%
IFN%=FALSE:=FNA(M%+MOne%,O1%)

REM 2.15 seconds at stock speed on virgin load
REM 2.04 seconds with core clocked to 480
REM Overclocking GPU by 100 to 350 had no effect here - well, maybe .02 secs.
REM Overclocked SDRAM to 512 and that did help - 1.99 seconds
REM RAM now at 600 1.98 seconds
REM Upping voltage slightly - say 4
REM upped core to 488 - o.k. 1.98 seconds
REM Boosted processor speed to 900 now 1.52 seconds

REM Some optimisation reduced time taken at stock speed to 2.11 seconds using the default configuration file

[/code]

Hmm.. for no reason that I can deduce my rpi now runs Ackermann's in 1.37 seconds when overclocked. All I did was watch a movie so I thought Aha! I'll boot the system again and I'll be back where I was.. but no..

@Markodius:
I wonder if the version of the ROOL Rom makes any difference? I do not know of any recent changes that could effect the speed of BBC BASIC, though I always run a ROM that is no more than 3 days old. Also I do have the CPU configuration set to native with aligment exceptions dissabled.

Also I just reran the Ackermann test program as I posted previously, with the default configuration (no overclocking at all, fresh boot) and it ran in 2.08 seconds on my RPi configured as follows:

Default CONFIG.TXT
CPU confiuration set to "ARMv7 fast mode ('alignment exceprions off')"
Default screen settings (X1920 Y1080 C16M EX1 EY1 F30)
Default set of modules loaded (including the original USB components).
BootFX unpluged.
RISC OS 5.19 from this last Friday.

The Ackermann test whas run singel taskng (did not use a task window). And that shold take care of every difference of my configuration.

I feel I must raise a couple of quibbles with your code, because others may be watching. [quote="Markodius"]

Code: Select all

TIME=FALSE
...
PRINT"DONE IN ";TIME/Centi%;" SECONDS"


Please do not do timing that way if you have any other programs running. The TIME pseudo-variable uses a system timer, so if you change it you might be affecting a program that relies on it. Something like this works fine:

Code: Select all

T%=TIME
...
PRINT"DONE IN ";(TIME-T%)/Centi%;" SECONDS"


As a matter of style is also better to follow NEXT with its control variable and BASIC V runs marginally faster if you do. I suspect you have done a lot of programming on the BBC Micro, where your code would be the best way to do things.

As a matter of style is also better to follow NEXT with its control variable and BASIC V runs marginally faster if you do.

Yikes! Markodius wasn't the only one who thought that, I'd been deliberately leaving them off because I was under the impression that if the control variable was present after the NEXT it was checked by BBC BASIC (to make sure it matched the one in the FOR) and so was slower.

Oh hum, it'll take me a little time to get used to it - but guess I start decorating my NEXTs with control variables from here on out.

Given that active FOR loops are stored on the BASIC stack, closing the innermost one should be faster than searching for one by variable. Furthermore, I can not find any situation where this is not the case.

Given that active FOR loops are stored on the BASIC stack, closing the innermost one should be faster than searching for one by variable. Furthermore, I can not find any situation where this is not the case.

I looked this up in the BASIC StrongHelp manual that I maintain myself and found that I am wrong.

I will have done the analysis of this a decade ago, but somehow the contrary idea got into my head. Mea culpa.

I still think that it is better to include the variable, stylewise.

Guess who spent an hour this morning working through a very large BBC Basic programme modifying all the "NEXT" statements to add the variable names used in the "FOR" loops

Oh well, at least its easy to get back to where I started this morning...

Ralph

What I meant about 'real world task' was that given a known idiom that can be implemented on any machine, then it can only be other factors that that impact the performance. The bubble sort is ideal as it's simple to see how it functions and therefore can be used on just about any machine with any language available for the machine. Most of the other 'tests' I've seen fall at this hurdle (although I've yet to investigate the Ackermann test). It also useful because you can check a number of things this way, it's not always how quickly the machine finished the task in some instances (try programming a bubble sort on a 1K Sinclair ZX81, actually easier than you think as it was a symbolic BASIC, but you quickly learn that it's not all about what you read in the 'Best practice' manual )

'Adequate' is better than 'perfect' as 'perfect' implies wasted effort.

I used to work in a target driven call centre and asked my line manager if I could be 'Mediocrity Champion' - didn't work there long

Also I just reran the Ackermann test program as I posted previously, with the default configuration (no overclocking at all, fresh boot) and it ran in 2.08 seconds on my RPi configured as follows:

Default CONFIG.TXT
CPU confiuration set to "ARMv7 fast mode ('alignment exceprions off')"
Default screen settings (X1920 Y1080 C16M EX1 EY1 F30)
Default set of modules loaded (including the original USB components).
BootFX unpluged.
RISC OS 5.19 from this last Friday.

The Ackermann test whas run singel taskng (did not use a task window). And that shold take care of every difference of my configuration.

Thanks DavidS. That's close enough for jazz So mi Pi is as good as anyone elses! Yes! I'm guessing that the ROM version could influence benchmarks. You brave soul!

I feel I must raise a couple of quibbles with your code, because others may be watching.

Code: Select all

TIME=FALSE
...
PRINT"DONE IN ";TIME/Centi%;" SECONDS"


Please do not do timing that way if you have any other programs running. The TIME pseudo-variable uses a system timer, so if you change it you might be affecting a program that relies on it. Something like this works fine:

Code: Select all

T%=TIME
...
PRINT"DONE IN ";(TIME-T%)/Centi%;" SECONDS"


As a matter of style is also better to follow NEXT with its control variable and BASIC V runs marginally faster if you do. I suspect you have done a lot of programming on the BBC Micro, where your code would be the best way to do things.

Shadowing the timer requires variable creation - as that is not required to make the benchmark operate correctly and benchmarks are run in exclusive mode on clean systems it is the 'proper' way to do it but I agree it would be bad programming practice outside of benchmarking.

For what it's worth I disagree concerning the qualification of 'for loop' terminii, it's slower. As a matter of style, yes, it's clearer but only deeply nested loops should require qualification for the purposes of legibility.

Yes Steve! I learned BASIC on the Beeb. Halcyon days spent wondering why nothing worked as I thought it would! lol.. Sorry for my excursions.. these days I only seem to be able to hold about a page of code in my bonce before losing focus.

Guess who spent an hour this morning working through a very large BBC Basic programme modifying all the "NEXT" statements to add the variable names used in the "FOR" loops

Oh well, at least its easy to get back to where I started this morning...

Ralph

Ouch! Sorry. There isn't very much in it if there is anything significant going on inside the loop. I believe that it always best to use the variables, because it aids readabilty, especially if someone else is going to read or edit the program. Optimisations such as this are best left to specialised crunching applications that can provide a runtime from a well formatted source.

I will have done the analysis of this a decade ago, but somehow the contrary idea got into my head. Mea culpa.

Wouldn't worry about it Steve - these things happen - no harm done (I can leave the blasted control variables out if I like YAH HAY !!!!). Sorry I better tone that down "yah hay".

As to your point about including the control variable for style reasons - perhaps. I must admit out of force of habit I would be inclined to leave them off primarily because (i). The language allows it (ii). That frequently I wouldn't be using a nested (or deeply nested) FOR..NEXT so including the control variable doesn't actually add any clarity (as it was perfectly clear before...).

The counter argument (with which ok I'd have some sympathy) is for a learner it emphasises that a specific variable is changed by the loop - so for pedagogical reasons it wouldn't be a bad idea for people to learn to use them. Also if the loop were a long one (which should never happen because we'd refactor the inner code right ? ) then a NEXT with the control variable might act as an aide memoir for the programmer

Hey SteveDrain. sorry chap - I posted without reading your latest post. If you've ever tried to program in Python then you really appreciate descriptive terminii. No endif/block/select/end while or any bloody thing. Just white space! Very Monty.

We are showing a huge Pro:
THIS THREAD HAS COVERED A LOT OF GROUND ABOUT RISC OS, AND BBC BASIC. Would this happen with as much detail on any other "Modern" OS?

Thanks DavidS. That's close enough for jazz So mi Pi is as good as anyone elses! Yes! I'm guessing that the ROM version could influence benchmarks. You brave soul!

I do not know about that. I just want to make sure that the changes I make do not break with the changes that others are making. And something has broken in the current development ROM .

While it does not seem to effect anything of my code, it does effect the usability, it is something with the font management (all charactors are displayed as 1 pixel high half of the boots, the other half all unicode characters are 1 pixel high). Though I can not find any recent changes in the CVS log that could effect this part of the system.

That is bad news DavidS. The fact that it is not strictly repeatable seems to indicate a variance in the way data is being read. Has the default SD read speed been increased/altered?