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

Re: Comparing Interpreted Language Speed.

Mon Jul 15, 2019 1:33 pm

hippy wrote:
Mon Jul 15, 2019 10:02 am
ejolson wrote:
Sun Jul 14, 2019 8:53 pm
A simple prime sieve program written in C using the MIT/Cilk parallel programming extensions is here.
Thanks. It seems it would require far too much effort than I am prepared to put in.

I am not sure why such complicated algorithms are needed just for comparing respective speeds of interpretation. Simple test programs which just add numbers, concatenate strings, slice strings, access arrays, call subroutines, read and write files, should give something which allows a basic relative speed comparison to be made.
The reason it is important to compare speeds by using an actual computation with a verifiable result is that a bunch of function calls and arithmetic operations that don't perform such a computation are easily removed by a modern optimizing compiler and likely some interpreters as well.

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

Re: Comparing Interpreted Language Speed.

Mon Jul 15, 2019 2:04 pm

bensimmo,

Boring heh?

OK. I have code here https://www.raspberrypi.org/forums/view ... 5#p1252388 that can toggle a GPIO pin 50 million times per second.

Somewhere around here I have an old Pi model rotating a textured cube amazingly fast. It uses Qt 5 and displays directly to the frame buffer. No X required.
None of this boring single task number crunching.
Both ejolson's C Fibo number crunching and my C++ can use as many tasks on as many cores as you like.

In fact ejolson''s version can spread itself over a cluster of Pis
Last edited by Heater on Mon Jul 15, 2019 4:09 pm, edited 1 time in total.

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

Re: Comparing Interpreted Language Speed.

Mon Jul 15, 2019 2:40 pm

bensimmo wrote:
Mon Jul 15, 2019 1:30 pm
Benchmarks of turning LEDs on and off, how fast they can read square waves of the gpio.

Something a bit more useful to a Pi user?

Creating a rotatable object on screen?

Playing a bit of music?

None of this boring single task number crunching.
May as well just do some Seti@Home or other BOINC projects and make it worthwhile for someone?
Though some have tried, it appears to me that there is no use in using an interpreted language to bit-bang the GPIO lines. That type of low level interface should be done using an assembly or C library, either as a kernel module or as user-space code that makes suitable arrangements with a real-time kernel or at least sets processor affinity and locks memory. Once done, the same library should be usable by all high-level programming languages and consequently there is nothing to compare between languages.

Of course someone has to write the library in the first place. If a kernel module is involved, then C mixed with assembler is pretty much dictated. If done in user space there is more flexibility but very little reason to use anything else, either.

Similar is true when rotating a three-dimensional object: If you aren't using the OpenGL driver, then you are doing it wrong. Again, someone needs to write the driver, but writing OpenGL drivers that run on graphics cards is not a good opportunity for comparing general-purpose programming languages.

hippy
Posts: 5594
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Comparing Interpreted Language Speed.

Mon Jul 15, 2019 4:27 pm

ejolson wrote:
Mon Jul 15, 2019 2:40 pm
Once done, the same library should be usable by all high-level programming languages and consequently there is nothing to compare between languages.
But there is setup time and overhead time in calling the library. In fact that's arguable more useful for speed comparisons, when not knowing if any sluggishness is in the setup, calling or doing. The doing being common is effectively removed from the comparison.

And how things compare, doing it oneself or through calling a library, is useful to know.

The thing is it's comparative data we are after, not necessarily determining which is quickest.

If something is slower but good enough I might choose to still do it the slow way rather than call a library if that library has licensing I would prefer to avoid.

User avatar
bensimmo
Posts: 4125
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: Comparing Interpreted Language Speed.

Mon Jul 15, 2019 4:38 pm

But which language makes rotating an ever increasing 3D Fibonacci curl while strobing an external led and measuring the temperature while making a nice sound scale.

These "interpreted" languages are all built on someone else's code, just because it binds to something to get it done, doesn't mean they'll all be the same speed.
Use it and make nice things on a Pi happen.

Make the program do lots of different things at once.

Then figure out a benchmark?
Speed?

Old gpio speed test
https://codeandlife.com/2012/07/03/benc ... pio-speed/
Ability to actually do it?
Time taken to get it to work?
FPS?


Oh and no I couldn't do it, I'm not good enough.

Also Scratch could do it, the 3D rotation is not great or fast though, but cats do like chasing after things.

User avatar
John_Spikowski
Posts: 1310
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Comparing Interpreted Language Speed.

Mon Jul 15, 2019 5:33 pm

If performance is the goal, why are you even suggesting the task be done with an interpreter?

Since most applications people write are idle most of the time, a C extension typically is more than enough to cover any unique CPU demands.

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

Re: Comparing Interpreted Language Speed.

Mon Jul 15, 2019 11:46 pm

Heater wrote:
Mon Jul 15, 2019 12:40 pm
Wow, thanks for giving that a go. Shame it is being so intransigent.
no probs. It's quite a pretty OS when it gets running. Shame it doesn't speak any file formats that the rest of the world uses.

The other thing I haven't managed to get it to do is time programs. I suspect it'll need to be something in the code itself.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

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

Re: Comparing Interpreted Language Speed.

Tue Jul 16, 2019 12:26 am

scruss wrote:
Mon Jul 15, 2019 11:46 pm
Heater wrote:
Mon Jul 15, 2019 12:40 pm
Wow, thanks for giving that a go. Shame it is being so intransigent.
no probs. It's quite a pretty OS when it gets running. Shame it doesn't speak any file formats that the rest of the world uses.

The other thing I haven't managed to get it to do is time programs. I suspect it'll need to be something in the code itself.
I posted a modified version for Matrix Brandy Basic here.

User avatar
John_Spikowski
Posts: 1310
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Comparing Interpreted Language Speed.

Tue Jul 16, 2019 1:43 am

Though some have tried, it appears to me that there is no use in using an interpreted language to bit-bang the GPIO lines. That type of low level interface should be done using an assembly or C library, either as a kernel module or as user-space code that makes suitable arrangements with a real-time kernel or at least sets processor affinity and locks memory. Once done, the same library should be usable by all high-level programming languages and consequently there is nothing to compare between languages.
I created an extension module wrapper for WiringPi along with two additional functions I wrote in C.

One function builds a string polling the GPIO pin every 5 microseconds. The other converts a 8 bit binary value to an ASCII character.

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

Re: Comparing Interpreted Language Speed.

Tue Jul 16, 2019 3:21 am

ejolson wrote:
Tue Jul 16, 2019 12:26 am
I posted a modified version for Matrix Brandy Basic here.
Still the same problems though: HIMEM issues and other errors. The version that runs on GW-BASIC won't even run under BASIC64 on RISC OS. I'm stumped. I'll have to ask on Stardot.

I am posting this from RISC OS though - even if the edit window is 2 lines by32 chars ...
Last edited by scruss on Tue Jul 16, 2019 11:46 am, edited 1 time in total.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

User avatar
Gavinmc42
Posts: 3438
Joined: Wed Aug 28, 2013 3:31 am

Re: Comparing Interpreted Language Speed.

Tue Jul 16, 2019 4:44 am

Though some have tried, it appears to me that there is no use in using an interpreted language to bit-bang the GPIO lines.
I bitbanged GPIO in micropython for a simple single axis stepper motor driver.
It was not worth the trouble of compiling for a simple application.

Lots of stuff can be done with interpreted code.
Interpreted code is handy, no need for a self hosted compiler and massive dependencies.
Give me standards like C/C++ or at least cross platform support like Python.
Or shell script which needs no installing and works pretty fast on 1GHz machines.
They are also editable when running remotely.

Bit banging GPIO is a good speed test.
I did it years ago on PiCore Linux just to see if it was fast enough, it was.
A few thousand lines of code is a big project for me.
Sometimes 20 lines of Mathematica cannot be equalled for a few hours of coding, which included learning it.

Whatever works and is the quickest to write can be very important.
Easy to maintain and modify helps too over the life of the project.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Comparing Interpreted Language Speed.

Tue Jul 16, 2019 12:05 pm

ejolson wrote:
Tue Jul 16, 2019 12:26 am
I posted a modified version for Matrix Brandy Basic here.
Well, this is fun. Looks like I've found an inconsistency between Matrix Brandy compiled for Raspberry Pi and Matrix Brandy compiled for x86_64. Running that linked code but with an added line 8605 PRINT " *** F0: "; F0:

Raspberry Pi:

Code: Select all

pi@three2:~/Desktop $ sbrandy -size 48000000 classic_small-test.bas
 *** F0: 1.07374182e+09
? 100
354224848179261915075
x86_64:

Code: Select all

scruss@bunny:~/basic$ sbrandy -size 48000000 classic_small-test.bas
 *** F0: -1.07374182e+09

Tried to take square root of a negative number at line 8610
I'll post an issue.

Aside from the Out of range value assigned to HIMEM error on RISC OS, BASIC/BASIC64 fails with

Code: Select all

Invalid arithmetic operation at line 8550
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

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

Re: Comparing Interpreted Language Speed.

Tue Jul 16, 2019 1:59 pm

scruss wrote:
Tue Jul 16, 2019 12:05 pm
ejolson wrote:
Tue Jul 16, 2019 12:26 am
I posted a modified version for Matrix Brandy Basic here.
Well, this is fun. Looks like I've found an inconsistency between Matrix Brandy compiled for Raspberry Pi and Matrix Brandy compiled for x86_64. Running that linked code but with an added line 8605 PRINT " *** F0: "; F0:

Raspberry Pi:

Code: Select all

pi@three2:~/Desktop $ sbrandy -size 48000000 classic_small-test.bas
 *** F0: 1.07374182e+09
? 100
354224848179261915075
x86_64:

Code: Select all

scruss@bunny:~/basic$ sbrandy -size 48000000 classic_small-test.bas
 *** F0: -1.07374182e+09

Tried to take square root of a negative number at line 8610
I'll post an issue.

Aside from the Out of range value assigned to HIMEM error on RISC OS, BASIC/BASIC64 fails with

Code: Select all

Invalid arithmetic operation at line 8550
I may have to rethink the code that automatically detects the precision of the floating point. What happens if you set F0 to the correct value where needed and continue on? Alternatively, set B7, B8 and B9 by hand to sensible values at the beginning of the program and skip that subroutine entirely.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Comparing Interpreted Language Speed.

Wed Jul 17, 2019 5:29 am

scruss wrote:
Tue Jul 16, 2019 12:05 pm
Aside from the Out of range value assigned to HIMEM error on RISC OS, ...
Well just comment out that assignment and make sure that the next slot is large enough for the required DIM's.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Comparing Interpreted Language Speed.

Thu Jul 18, 2019 12:00 am

DavidS wrote:
Wed Jul 17, 2019 5:29 am
Well just comment out that assignment and make sure that the next slot is large enough for the required DIM's.
Um, both you and Soruk use the term next slot, and I have no idea what it could mean.
Slots are where you put interface cards in my world.
Can you please explain? I've used RISC OS for a total of about 3 hours in my life, so I have no idea of the jargon.

And I'm guessing BASICVFP (or BASIC64) is preferable to plain ol BASIC?

Looking at ejolson's classic code, it looks like the BASIC interpreter with the widest ints will likely always win, as wide integers mean fewer entries in the bignum array, and fewer entries mean far fewer interpreted operations.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Comparing Interpreted Language Speed.

Thu Jul 18, 2019 2:38 am

scruss wrote:
Thu Jul 18, 2019 12:00 am
DavidS wrote:
Wed Jul 17, 2019 5:29 am
Well just comment out that assignment and make sure that the next slot is large enough for the required DIM's.
Um, both you and Soruk use the term next slot, and I have no idea what it could mean.
Slots are where you put interface cards in my world.
Can you please explain? I've used RISC OS for a total of about 3 hours in my life, so I have no idea of the jargon.
In RISC OS the next program to be started will be allocated a continous are of memory defined by the next slot (it is a slot [section] of memory). And as that program does not allocate a dynamic area (an area of memory seperate from the continuous initial allocation) it needs to have enough memory available in its initial slot.

And I'm guessing BASICVFP (or BASIC64) is preferable to plain ol BASIC?
BASICVFP/BASIC64 is a version of BBC BASIC that uses 64-bit floating point values. And on systems that have VFP/NEON it uses the VFP unit for floating point (a lot faster than the FPE [Floating Point Emulator]).

The BASIC64 (and BASICVFP) are BBC BASIC VI

BASIC V (normal BASIC command) is faster for integer only applications, by a notable amount.
Looking at ejolson's classic code, it looks like the BASIC interpreter with the widest ints will likely always win, as wide integers mean fewer entries in the bignum array, and fewer entries mean far fewer interpreted operations.
It would seem that way. Though yet it apears (so far) that BBC BASIC V will win in this case, as it is integer and significantly enough faster than the others.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Comparing Interpreted Language Speed.

Thu Jul 18, 2019 3:06 am

Is it so that after all this time and debate we still don't have an execution time for the Big Fibo code BBC BASIC on RISC OS?

I keep coming across hints that somebody has actually managed to get it to run. So far I have not seen any results posted. Did I miss it?

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

Re: Comparing Interpreted Language Speed.

Thu Jul 18, 2019 11:14 am

Heater wrote:
Thu Jul 18, 2019 3:06 am
Is it so that after all this time and debate we still don't have an execution time for the Big Fibo code BBC BASIC on RISC OS?
It's been running on a Raspberry Pi 3 for just over an hour. No result yet …

(it's been an immense amount of work to get it going even on a Raspberry Pi 3 and I don't think I have the energy to run it on a Zero, as may be expected by some people here. Having to rig up a keyboard mouse monitor usb stick and fan to a tiny zero is just too much work, but I will post what code worked here and anyone else can take up the challenge. I warn you: it's not fun.)
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

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

Re: Comparing Interpreted Language Speed.

Thu Jul 18, 2019 11:23 am

A tense moment....

Pi 3 is fine. I have no zeros around here.

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

Re: Comparing Interpreted Language Speed.

Thu Jul 18, 2019 1:06 pm

Okay, so: this code — Classic2 — run under RISC OS on a Raspberry Pi 3 gave the following times:

BASIC: 3778 s

BASIC64: 3240 s

The Raspberry Pi 3 had a fan playing on it all the time - it is unlikely to have throttled.

I'm currently running this code — Classic2_brandy — on the same Raspberry Pi 3 under Raspbian Buster and Soruk's most recent git push of stardot/MatrixBrandy: Fork of Brandy BASIC V for Linux. More later, including trying BBCSDL
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

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

Re: Comparing Interpreted Language Speed.

Thu Jul 18, 2019 1:48 pm

What, no screen shot of this momentous occasion ?

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Comparing Interpreted Language Speed.

Thu Jul 18, 2019 3:59 pm

Heater wrote:
Thu Jul 18, 2019 3:06 am
Is it so that after all this time and debate we still don't have an execution time for the Big Fibo code BBC BASIC on RISC OS?

I keep coming across hints that somebody has actually managed to get it to run. So far I have not seen any results posted. Did I miss it?
Sorry about that, I thought I had posted a run time on the RPi 1B+ at 1000MHz ARM (other clocks stock). I do not wish to rerun at the moment, as have other things to do, maybe later.

Scruss gave RPi 3B results though
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Comparing Interpreted Language Speed.

Fri Jul 19, 2019 12:58 am

Heater wrote:
Thu Jul 18, 2019 1:48 pm
What, no screen shot of this momentous occasion ?
You can, frankly, away an' run up ma humph. Even if I did know how to take screenshots on RISC OS, I was just running in the full-screen console thing. There's no GUI to do anything to, and no other tasks around to grab a picture. You have to even choose how much memory your program needs in RISC OS!

So I ran the code under Matrix Brandy under Raspbian Buster on the same board, and the results were pleasantly close:
  • Matrix Brandy / Raspbian: 3800 s (100%)
  • BBC BASIC V / RISC OS: 3778 s (99%)
  • BBC BASIC VI / RISC OS: 3240 s (85%)
So while BBC BASIC is fast, for me it's not fast enough to give up the convenience of Linux.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

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

Re: Comparing Interpreted Language Speed.

Fri Jul 19, 2019 3:34 am

scruss,
You can, frankly, away an' run up ma humph.
What a charming turn of phrase. Sounds like something Rab C. Nesbitt might say: https://www.youtube.com/watch?v=y33a8pXIy20
Under the circumstances I can quite sympathize. You have done you part for the Fibo Challenge, far above and beyond the call of duty.

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.

Once again demonstrating the futility of writing large programs in assembler.

Also bear in mind that BBC BASIC was written by a genius. So we could expect C to match the efforts of the average assembler programmer.

DavisS should find this interesting...

Thanks again for you great efforts here.
Last edited by Heater on Fri Jul 19, 2019 5:23 am, edited 1 time in total.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Comparing Interpreted Language Speed.

Fri Jul 19, 2019 4:12 am

scruss wrote:
Fri Jul 19, 2019 12:58 am
Heater wrote:
Thu Jul 18, 2019 1:48 pm
What, no screen shot of this momentous occasion ?
You can, frankly, away an' run up ma humph. Even if I did know how to take screenshots on RISC OS, I was just running in the full-screen console thing. There's no GUI to do anything to, and no other tasks around to grab a picture. You have to even choose how much memory your program needs in RISC OS!

So I ran the code under Matrix Brandy under Raspbian Buster on the same board, and the results were pleasantly close:
  • Matrix Brandy / Raspbian: 3800 s (100%)
  • BBC BASIC V / RISC OS: 3778 s (99%)
  • BBC BASIC VI / RISC OS: 3240 s (85%)
So while BBC BASIC is fast, for me it's not fast enough to give up the convenience of Linux.
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.

When I go to bed I think I will be starting a run of this insane Fibo program to see how it does (already have the obey file setup to automate running it in BASIC VI, BASIC V and compiled with ABC, so the standard ways on RISC OS). Will be interesting to see the results, as there are some differences in a good setup versus a minimal RISC OS setup.

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).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Return to “General programming discussion”