User avatar
scruss
Posts: 2420
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Comparing Interpreted Language Speed.

Fri Jul 19, 2019 12:06 pm

Heater wrote:
Fri Jul 19, 2019 3:34 am
What a charming turn of phrase. Sounds like something Rab C. Nesbitt might say: https://www.youtube.com/watch?v=y33a8pXIy20
Well, he and I are from the same town. Unlike Rab, my head wound healed up long ago.
This is an fascinating result. As far as I can tell Brandy is written in C. As it has come in only 15% slower than the hand crafted assembler it shows that C compilers are pretty damn good, far from as inefficient as many die hard assembler enthusiasts claim.
Yup, I was surprised too. On modern chips, it's typically not worth the effort of getting into assembly language unless it's for enjoyment.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

User avatar
scruss
Posts: 2420
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Comparing Interpreted Language Speed.

Fri Jul 19, 2019 12:23 pm

DavidS wrote:
Fri Jul 19, 2019 4:12 am
Interesting results. Have you tried any of the well known graphics benchmarks (well known on BBC BASIC for RISC OS). I am curious of the results.
No, I don't know of those benchmarks, and I'm not sure if I can run them unchanged in Matrix Brandy.
… there are some differences in a good setup versus a minimal RISC OS setup.
Hey, if the RISC OS folks don't set up their distro for good performance, it's their product to show off. I only use stock settings with my distributions.
For now could you tell me what the run time is on an RPi 3B for FIBO 101000 with your RISC OS setup?

On my RPi 3B+ it is 5.82 in BASIC VI, and 6.80 seconds in BASIC V at stock clocks (in a task window). Compiled is slower (I think because of the limits of ABC with regard to floating point math).
As in: this code, but with
250N=101000
?
Sure, I'll give that a shot this evening. I haven't yet dismantled the RISC OS setup, though I need the space this weekend.

Note, though, that any code that runs the "GET DYNAMIC RANGE" section and tunes the largest integer/carry threshold is not a fair comparison. That code currently fails on Matrix Brandy, so my code has:
8520F0=&7FFFFFFF:F0=INT(F0/2):GOTO 8610:REM F9=1
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

ejolson
Posts: 3424
Joined: Tue Mar 18, 2014 11:47 am

Re: Comparing Interpreted Language Speed.

Fri Jul 19, 2019 2:44 pm

scruss wrote:
Fri Jul 19, 2019 12:23 pm
DavidS wrote:
Fri Jul 19, 2019 4:12 am
Interesting results. Have you tried any of the well known graphics benchmarks (well known on BBC BASIC for RISC OS). I am curious of the results.
No, I don't know of those benchmarks, and I'm not sure if I can run them unchanged in Matrix Brandy.
… there are some differences in a good setup versus a minimal RISC OS setup.
Hey, if the RISC OS folks don't set up their distro for good performance, it's their product to show off. I only use stock settings with my distributions.
For now could you tell me what the run time is on an RPi 3B for FIBO 101000 with your RISC OS setup?

On my RPi 3B+ it is 5.82 in BASIC VI, and 6.80 seconds in BASIC V at stock clocks (in a task window). Compiled is slower (I think because of the limits of ABC with regard to floating point math).
As in: this code, but with
250N=101000
?
Sure, I'll give that a shot this evening. I haven't yet dismantled the RISC OS setup, though I need the space this weekend.

Note, though, that any code that runs the "GET DYNAMIC RANGE" section and tunes the largest integer/carry threshold is not a fair comparison. That code currently fails on Matrix Brandy, so my code has:
8520F0=&7FFFFFFF:F0=INT(F0/2):GOTO 8610:REM F9=1
The value F0=7FFFFFFF is the largest integer that can be held in a 32-bit signed integer variable and designed to overcome the INT bug in certain implementations of BBC Basic. If you are not going to use the extra range of double precision floating point, you would certainly be better off running the integer version of the line-numbered Basic code which is called integer.bas in the repository. Note that integer.bas does not include the floating-point dynamic range tuning code but sets B7, B8 and B9 to reasonable values on line 260. It also relies on the Microsoft Basic implicit type declaration DEFLNG A-Z or DEFINT A-Z, therefore a bunch of explicit percent signs may be needed with BBC Basic.

It is interesting that the floating point routines in the original versions of Microsoft Basic were not written by either Bill Gates or Paul Allen but Monte Davidoff. There is evidence that Davidoff's contribution was more important than the other two for the success of the resulting programming language: Microsoft Basic would not have found its way into so many mathematics and science textbooks without the ability to express things like Newton's method for finding roots of nonlinear algebraic equations and the Simpson's quadrature formula for approximating definite integrals. The tiny and integer Basics written by hobbyists (and Steve Wozniak) didn't have this calculating ability, didn't appeal to such a wide audience and as a result didn't become universally popular.

Due to the code present in textbooks as well as general popularity, BBC Basic attempted to maintain compatibility with Microsoft Basic while adding extensions that supported structured flow-control but not structured data types. Unfortunately, they did not hire Monte Davidoff to do the floating point code. The BBC definition of INT appeared compatible when floating point numbers were five bytes but fell apart completely during the digital apocalypse of the huge Fibonacci challenge.

It seems reasonable to include the option

SYS "Brandy_INTusesFloat",1

in Matrix Brandy Basic to enable a sensible treatment of rounding for floating point numbers.

An alternative approach, that would mask the problem in a way similar to how things worked when floating point was five bytes, would be to use only 64-bit integer variables on versions of Basic in which floating point is double-precision. As the rest of the world (except for Raspberry Pi) has moved to 64-bit on the desktop, that would be a reasonable way, from my point of view, to preserve the traditional simplicity of Basic as technology evolves.

User avatar
scruss
Posts: 2420
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Comparing Interpreted Language Speed.

Fri Jul 19, 2019 4:29 pm

ejolson wrote:
Fri Jul 19, 2019 2:44 pm
… If you are not going to use the extra range of double precision floating point, you would certainly be better off running the integer version of the line-numbered Basic code which is called integer.bas in the repository.

It also relies on the Microsoft Basic implicit type declaration DEFLNG A-Z or DEFINT A-Z, therefore a bunch of explicit percent signs may be needed with BBC Basic.
Sure, I'll give integer.bas a shot. In addition to the %s and log→LN, the integer division operator in BBC BASIC is DIV rather than ‘\’
It is interesting that the floating point routines in the original versions of Microsoft Basic were not written by either Bill Gates or Paul Allen but Monte Davidoff.
Yes, it appears that working floating point eluded Gates and Allen until Davidoff (Gates's room-mate at Harvard) stepped up. BASIC isn't BASIC without floating point. How else could we have played the 101 BASIC Computer Games?
The tiny and integer Basics written by hobbyists (and Steve Wozniak) didn't have this calculating ability, didn't appeal to such a wide audience and as a result didn't become universally popular.
If anyone knew the limitations of floating point on 8-bit hardware, though, it would have been Steve Wozniak: he co-wrote the Rankin/Wozniak Floating Point Routines for the 6502. Apple Integer BASIC was written so Woz could play Breakout ("Little Brick Out", in the original intro tapes) at adequate speed in software rather than in the original hardware. There wasn't enough RAM in the first Apples to have floating-point BASIC, so Woz's Integer BASIC had to do.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

User avatar
scruss
Posts: 2420
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Comparing Interpreted Language Speed.

Sun Jul 21, 2019 4:09 pm

Okay, so this happened:

Code: Select all

 Big BBC BASIC Integer Fibonacci test
 scruss                        2019-07-20

 Fibonacci(101000)

 OS                Interpreter          Run Time / s  Rank Relative Speed Note
 ================  ===================  ============  ==== ============== ====
 RISC OS           BASIC V                       6.3    1            100%
 RISC OS           BASIC64                       6.4    2            101% [1]
 Raspbian          Matrix Brandy                 8.6    3            136%
 Raspbian          Brandy BASIC                 10.0    4            158% [2]
 Raspbian          BBC BASIC SDL                37.8    5            596%

 Fibonacci(4784969)

 OS                Interpreter          Run Time / s  Rank Relative Speed Note
 ================  ===================  ============  ==== ============== ====
 RISC OS           BASIC V                    2978.6    1            100% [3]
 RISC OS           BASIC V                    3282.5    2            110% [1]
 RISC OS           BASIC64                    3351.9    3            113% [1]
 Raspbian          Matrix Brandy              4085.5    4            137% [4]
 Raspbian          Matrix Brandy              4092.4    5            137%
 Raspbian          BBC BASIC SDL             16166.1    6            543%

 Notes:
 [1] run in TaskWindow. Text output seems very slow
 [2] from Raspbian repo
 [3] run in full-screen ShellCLI
 [4] with “SYS "Brandy_INTusesFloat",1” option

 Hardware:
 Raspberry Pi 3B, stock processor settings with fan to keep CPU ≤ 45 °C

 Software:
 Raspbian: Buster, updated to current
 RISC OS: current from www.riscosopen.org, ARM 7 Strict mode
 Matrix Brandy (sbrandy): current from github.com/stardot/MatrixBrandy
 BBC BASIC SDL: current from www.bbcbasic.co.uk/bbcsdl/

 Source:
 https://gist.github.com/scruss/f6d7c356d2d7d9e324adb1cac1eff949#file-integer_bbc-bas

‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

User avatar
John Spikowski
Posts: 41
Joined: Sat Jul 20, 2019 5:34 pm
Location: Anacortes, WA USA
Contact: Website

Re: Comparing Interpreted Language Speed.

Mon Jul 22, 2019 4:02 pm

Can't wait to see how ScriptBasic compares on RISC OS.

Thanks @scruss for your efforts!

Soruk
Posts: 21
Joined: Thu Jun 20, 2019 11:25 am

Re: Comparing Interpreted Language Speed.

Wed Jul 24, 2019 9:01 pm

Just stumbled on this thread - and I'm very pleasantly surprised how well Matrix Brandy is stacking up compared to the ARM assembly-coded RISC OS BASICs! Of course it will be a bit slower (and I'm certainly nothing like the genius of Sophie Wilson!!!)

For BBC BASIC64 and Matrix Brandy, you can try setting F0 to 2^53 in line 8550 - that's the largest int that can be accurately held in a 64-bit float. After halving, it'll be equal to 2^52.

Heater
Posts: 13119
Joined: Tue Jul 17, 2012 3:02 pm

Re: Comparing Interpreted Language Speed.

Wed Jul 31, 2019 10:54 pm

If anyone is still interested in comparing Interpreted language speed there is a good comparison of many of the big names here:

https://www.raspberrypi.org/forums/view ... 5#p1510350

Perhaps enthusiasts of other interpreters would like to pitch in there with solutions to the anagram problem.

Return to “General programming discussion”