Page 2 of 3

Re: Comparing Interpreted Language Speed.

Posted: Mon Jul 15, 2019 1:33 pm
by ejolson
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.

Re: Comparing Interpreted Language Speed.

Posted: Mon Jul 15, 2019 2:04 pm
by Heater
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

Re: Comparing Interpreted Language Speed.

Posted: Mon Jul 15, 2019 2:40 pm
by ejolson
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.

Re: Comparing Interpreted Language Speed.

Posted: Mon Jul 15, 2019 4:27 pm
by hippy
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.

Re: Comparing Interpreted Language Speed.

Posted: Mon Jul 15, 2019 4:38 pm
by bensimmo
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.

Re: Comparing Interpreted Language Speed.

Posted: Mon Jul 15, 2019 5:33 pm
by John_Spikowski
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.

Re: Comparing Interpreted Language Speed.

Posted: Mon Jul 15, 2019 11:46 pm
by scruss
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.

Re: Comparing Interpreted Language Speed.

Posted: Tue Jul 16, 2019 12:26 am
by ejolson
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.

Re: Comparing Interpreted Language Speed.

Posted: Tue Jul 16, 2019 1:43 am
by John_Spikowski
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.

Re: Comparing Interpreted Language Speed.

Posted: Tue Jul 16, 2019 3:21 am
by scruss
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 ...

Re: Comparing Interpreted Language Speed.

Posted: Tue Jul 16, 2019 4:44 am
by Gavinmc42
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.

Re: Comparing Interpreted Language Speed.

Posted: Tue Jul 16, 2019 12:05 pm
by scruss
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

Re: Comparing Interpreted Language Speed.

Posted: Tue Jul 16, 2019 1:59 pm
by ejolson
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.

Re: Comparing Interpreted Language Speed.

Posted: Wed Jul 17, 2019 5:29 am
by DavidS
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.

Re: Comparing Interpreted Language Speed.

Posted: Thu Jul 18, 2019 12:00 am
by scruss
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.

Re: Comparing Interpreted Language Speed.

Posted: Thu Jul 18, 2019 2:38 am
by DavidS
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.

Re: Comparing Interpreted Language Speed.

Posted: Thu Jul 18, 2019 3:06 am
by Heater
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?

Re: Comparing Interpreted Language Speed.

Posted: Thu Jul 18, 2019 11:14 am
by scruss
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.)

Re: Comparing Interpreted Language Speed.

Posted: Thu Jul 18, 2019 11:23 am
by Heater
A tense moment....

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

Re: Comparing Interpreted Language Speed.

Posted: Thu Jul 18, 2019 1:06 pm
by scruss
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

Re: Comparing Interpreted Language Speed.

Posted: Thu Jul 18, 2019 1:48 pm
by Heater
What, no screen shot of this momentous occasion ?

Re: Comparing Interpreted Language Speed.

Posted: Thu Jul 18, 2019 3:59 pm
by DavidS
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

Re: Comparing Interpreted Language Speed.

Posted: Fri Jul 19, 2019 12:58 am
by scruss
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.

Re: Comparing Interpreted Language Speed.

Posted: Fri Jul 19, 2019 3:34 am
by Heater
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.

Re: Comparing Interpreted Language Speed.

Posted: Fri Jul 19, 2019 4:12 am
by DavidS
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).