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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 9:47 am

From time to time one finds oneself accidentally using these languages. Then it's time too take a break and remember that whatever it is can be translated into something that performs far better and is far more elegant.
Remind me again what Windows 10 was written in? :lol:

"Google, make me a program that does....."

Is this the longest off topic discussion?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jahboater
Posts: 4474
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 10:13 am

Gavinmc42 wrote:
Sat Jan 12, 2019 9:47 am
Remind me again what Windows 10 was written in? :lol:
About 98% in C, with a little C++ and a tiny amount of C#

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 11:20 am

About 98% in C, with a little C++ and a tiny amount Rhetorical question, i do't reallywantoknowf C#
No Cilk? Windows is doing multicore the hard way?
Rhetoric question, I don't really want to know.
But it does make me think about OS's that are designed from the start for multicore cpu's.

Barrelfish - http://www.barrelfish.org/
http://www.microkernel.info/
Oh dear, a whole new world of learning
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 11:40 am

jahboater wrote:
Sat Jan 12, 2019 10:13 am
Gavinmc42 wrote:
Sat Jan 12, 2019 9:47 am
From time to time one finds oneself accidentally using these languages. Then it's time too take a break and remember that whatever it is can be translated into something that performs far better and is far more elegant.
Remind me again what Windows 10 was written in? :lol:
About 98% in C, with a little C++ and a tiny amount of C#
The three C's: compare with the seven seas. Why avoid COBOL?

Here are some timings (best out of three reported) taken on a Pi Zero using the code currently in the GitHub repository:

Code: Select all

                   BUILD TIME    RUN TIME     TOTAL
serial                7.459       24.195     31.654
fibonacci             5.060       80.946     86.006
fibo_karatsuba       90.853       41.921    132.774

gcc -O3 -o serial parallel.c -lm
gcc -O3 -o fibonacci fibonacci.c -lm
g++ -O3 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lm -lpthread
What I find interesting is that the run time of serial was previously reported as 48 percent slower than fibo_karatsuba on Linux Subsystem for Windows using a particular x86 laptop whereas on the Pi Zero it appears 42 percent faster.
Last edited by ejolson on Sat Jan 12, 2019 11:49 am, edited 1 time in total.

jahboater
Posts: 4474
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 11:48 am

ejolson wrote:
Sat Jan 12, 2019 11:40 am
What I find interesting is that serial was previously reported as 48 percent slower that fibo_karatsuba running under Linux Subsystem for Windows on a particular x86 laptop while on the Pi Zero it appears 42 percent faster. Is this correct?
On the x86 laptop it has 4 cores + hyperthreading (another 4 threads).
The Pi Zero has one single core.

Multi-threading stuff on a single core host wastes time context switching and scheduling, which "serial" doesn't have to do.
And there is no I/O during the calculation. If there was I/O involved (or anything else that could block) then multi-threading might help even on a single core as other runnable tasks could scheduled in while a task blocks, keeping CPU utilization up.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 12:30 pm

jahboater wrote:
Sat Jan 12, 2019 11:48 am
ejolson wrote:
Sat Jan 12, 2019 11:40 am
What I find interesting is that serial was previously reported as 48 percent slower that fibo_karatsuba running under Linux Subsystem for Windows on a particular x86 laptop while on the Pi Zero it appears 42 percent faster. Is this correct?
On the x86 laptop it has 4 cores + hyperthreading (another 4 threads).
The Pi Zero has one single core.

Multi-threading stuff on a single core host wastes time context switching and scheduling, which "serial" doesn't have to do.
And there is no I/O during the calculation. If there was I/O involved (or anything else that could block) then multi-threading might help even on a single core as other runnable tasks could scheduled in while a task blocks, keeping CPU utilization up.
Good catch! I've now commented out the parallel stuff in bint.h as

Code: Select all

        // Do da karatsaba shuffle, yabba dabba do.
//        if ((low1.width > (1<<11)) && (low2.width > (1<<11))) {
//            auto f0 = std::async([low1, low2  ](){return(low1 * low2)  ;});
//            auto f2 = std::async([high1, high2](){return(high1 * high2);});
//            z1 = (low1 + high1) * (low2 + high2);
//            z2 = f2.get();
//            z0 = f0.get();
//        } else {
            z0 = low1 * low2;
            z1 = (low1 + high1) * (low2 + high2);
            z2 = high1 * high2;
//        }
and obtained this revised table

Code: Select all

                   BUILD TIME    RUN TIME     TOTAL
serial                7.459       24.195     31.654
fibonacci             5.060       80.946     86.006
fibo_karatserial     69.363       40.149    109.512

gcc -O3 -o serial parallel.c -lm
gcc -O3 -o fibonacci fibonacci.c -lm
g++ -O3 -o fibo_karatserial fibo_karatsuba.cpp fibo.cpp -lm
Compile time was reduced significantly and run time by about 2 seconds. Luckily, the performance of the C++ code is not less than 50 percent the fastest C code (ignoring the totals), so there is no need to avoid C++ on the Raspberry Pi Zero.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 1:12 pm

Edit: You seem to have a slightly ofl fibo_karatsuba there.

There is no time wasted doing Multi-threading on any machine when fibo_karatsuba is compiled as ejolson shows above.

OpenMP makes no change in the serial code unless the compiler supports it and one enables it with the -fopenmp compiler option.

On top of that fibo_karatsub must be built with -DUSE_OMP in order to make use of the openmp I have in there. This is not really necessary when using OpenMP as there it defines _OPENMP to test with #ifdef, but I also have USE_ASYNC to make use of the C++ std:async threading instead.

Similarly parallel.c will not use any multi-threading without the -fopenmp option. But I think ejolson has changed the algorithms a bit in other ways for the parallel.c version.

Here are the timings for build and run I get on my Pi 3B running the pi64 OS:

Code: Select all

                   BUILD TIME    RUN TIME     TOTAL
fibonacci            1.687         9.375      11.062
parallel             3.943         3.618       7.561      
fibo_karatsuba      17.200         4.536      21.736   


$ time g++ -Wall -Wextra -O3 -o fibonacci fibonacci.c
$ time g++ -Wall -fpermissive -Wextra -O3 -o parallel parallel.c
$ time g++-6 -Wall -Wextra -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
That makes single core fibo_karatsuba 25% slower than the fastest C version on the Pi3.

Which is odd, on my PC without OMP it's the other way around.

It does show up the notoriously slow build times of C++. You won't want to be using it as a scripting language.

We seem to have different file/program names. I used the names that appear in the sources.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 1:31 pm

ejolson,
Why avoid COBOL?
I have never had to avoid COBOL.

It's like avoiding pot holes on the German autobahn. Hard to do because there aren't any to avoid!

Seems it's dangerously easy to run COBOL on Linux now a days. So we will have to start practicing to avoid it as well.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 9:02 pm

Heater wrote:
Sat Jan 12, 2019 1:12 pm
We seem to have different file/program names. I used the names that appear in the sources.
I cloned the whole repository and used whatever was there. The bint.h code seemed to be using the C++ async library by default because it would not link without libpthread until I commented some lines out. From my build commands you will notice that I have kept the source filenames the same but changed the names of the executables to reflect they were compiled without enabling threads or OpenMP.
Heater wrote:Here are the timings for build and run I get on my Pi 3B running the pi64 OS
That's interesting. I had thought the advantage of one program over the other might be a 64-bit versus 32-bit effect. Why are you using a different compiler and only -O2 for the C++ code?
Last edited by ejolson on Sat Jan 12, 2019 9:16 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 9:14 pm

Could you try a "git pull" on your repo?

fibo_karatsuba can be build as serial code, using std::ASYNC or using OpenMP:

$ g++ -Wall -Wextra -std=c++17 -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
$ g++ -Wall -Wextra -DUSE_ASYNC -std=c++17 -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lpthread
$ g++ -Wall -Wextra -DUSE_OMP -fopenmp -std=c++17 -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp

Until this morning the C++ threading headers will still getting pulled in even when not used.

I should add some build instructions. If only to remind myself in the future.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 9:19 pm

Heater wrote:
Sat Jan 12, 2019 9:14 pm
Could you try a "git pull" on your repo?

fibo_karatsuba can be build as serial code, using std::ASYNC or using OpenMP:

$ g++ -Wall -Wextra -std=c++17 -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
$ g++ -Wall -Wextra -DUSE_ASYNC -std=c++17 -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lpthread
$ g++ -Wall -Wextra -DUSE_OMP -fopenmp -std=c++17 -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp

Until this morning the C++ threading headers will still getting pulled in even when not used.

I should add some build instructions. If only to remind myself in the future.
I would recommend naming the executables differently to reflect the different build options, otherwise the executables get overwritten.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 9:48 pm

ejolson,
Why are you using a different compiler ...
It's the same compiler. That was a cut and paste command from the PC where I now have now confusion between c++ and the clang++ installation.

Code: Select all

[email protected]:~$ ls -l /usr/bin/gcc
lrwxrwxrwx 1 root root 5 Apr  8  2017 /usr/bin/gcc -> gcc-6
...and only -O2 for the C++ code?
Because -O2 is faster!

Code: Select all

[email protected]:~/fibo_4784969/c++$ g++ -Wall -Wextra  -fopenmp -DUSE_OMP -std=c++17 -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
[email protected]:~/fibo_4784969/c++$ time ./fibo_karatsuba | head -c 32
10727395641800477229364813596225
real    0m1.756s
user    0m5.503s
sys     0m0.082s
[email protected]:~/fibo_4784969/c++$ g++ -Wall -Wextra  -fopenmp -DUSE_OMP -std=c++17 -O3 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
[email protected]:~/fibo_4784969/c++$ time ./fibo_karatsuba | head -c 32
10727395641800477229364813596225
real    0m1.585s
user    0m5.616s
sys     0m0.075s
Oh wait, seems that on the Pi3 using -O3 is faster!

On my PC -O2 is faster, like so:

Code: Select all

$ g++-6 -Wall -Wextra  -fopenmp -DUSE_OMP -std=c++17 -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
$ time ./fibo_karatsuba | head -c 32
10727395641800477229364813596225
real    0m0.232s
user    0m1.297s
sys     0m0.094s
$ g++-6 -Wall -Wextra  -fopenmp -DUSE_OMP -std=c++17 -O3 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
$ time ./fibo_karatsuba | head -c 32
10727395641800477229364813596225
real    0m0.262s
user    0m1.266s
sys     0m0.109s
I would recommend naming the executables differently to reflect the different build options, otherwise the executables get overwritten.
I keep the same name on all versions so as to avoid confusion :)

What I need here is a Make file or something to build these different experiments and build/run/time all the other fibos we have in the repo.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 10:51 pm

This is cool: The "constexpr" feature in recent C++ standards:

In C one might define some constants like so:

Code: Select all

#define DIGITS  9            // Decimal digits in each big integer array element.
#define BASE    1000000000   // The number base of our big integer calculations.
This is not ideal. Change one and you have to change the other correctly to match.

In recent C++ one could use constants expressions instead:

Code: Select all

constexpr int DIGITS = 9;                  // Decimal digits in each big integer array element.
constexpr int BASE = pow(10, DIGITS);      // The number base of our big integer calculations.
That's better. Now one only has to change DIGITS and BASE is recalculated properly. That "pow" is calculated at compile time not run time. DIGITS and BASE are now proper integer numbers. They have a type, they are not just a preprocessor text substitutions.

Except it turns out clang does not like that pow().

Now I find, since C++14 we can do even better. We can define entire, complicated expressions and functions as constant expressions. For example, as clang does not like that use of "pow" we can provide a power function as a constant expression that will be "run" and evaluated at compile time providing us with constants in the executable:

Code: Select all

constexpr double cexp_pow(double base, int exp) {
    if (exp < 0.0) {
        base = 1.0 / base;
        exp = -exp;
    }
    double result = 1.0;
    for (int i = 0; i < exp; ++i) {
        result = result * base;
    }
    return result;
}

constexpr int DIGITS = 9;
constexpr int BASE = cexp_pow(10, DIGITS);
How cool is that?!

That is only a simple example but one could imagine pre-calculating all kind of look up tables and such at compile time with such constexpr functions.

Carried to extreme one could write the entire fibo(4784969) as a constexpr that would get run and evaluated at compile time and the result plugged into the executable. Ready to print when you run it in no time at all!

jahboater
Posts: 4474
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 11:22 pm

Heater wrote:
Sat Jan 12, 2019 10:51 pm

In C one might define some constants like so:

Code: Select all

#define DIGITS  9            // Decimal digits in each big integer array element.
#define BASE    1000000000   // The number base of our big integer calculations.
This is not ideal. Change one and you have to change the other correctly to match.

In recent C++ one could use constants expressions instead:

Code: Select all

constexpr int DIGITS = 9;                  // Decimal digits in each big integer array element.
constexpr int BASE = pow(10, DIGITS);      // The number base of our big integer calculations.
In C you can do:-

Code: Select all

#define DIGITS  9
const int BASE = pow( 10, DIGITS );
which achieves what you want, you only have to change DIGITS.

It would be fun to try fibo(4784969) as a constexpr but I think there are some strict rules they have to abide by such as not allocating memory (I think). If it worked, C++17 would be the clear winner performance wise!

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 11:51 pm

Durp, durp, of course!

Which makes me wonder now why clang++ accepts this:

Code: Select all

const int DIGITS = 9;
const bintel_t BASE = pow(10, DIGITS);
But not this:

Code: Select all

constexpr int DIGITS = 9; 
constexpr bintel_t BASE = pow(10, DIGITS);
g++ is happy with both.

This is too small an example, constexpr is all about calculating complex, possibly big things at compile time rather than run time. Thus detecting errors earlier and perhaps saving run time space and time.

Certainly constexpr has a lot of limitations, no way would our fibo work there. Cool none the less.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 1:33 am

jahboater wrote:
Sat Jan 12, 2019 11:22 pm
Heater wrote:
Sat Jan 12, 2019 10:51 pm

In C one might define some constants like so:

Code: Select all

#define DIGITS  9            // Decimal digits in each big integer array element.
#define BASE    1000000000   // The number base of our big integer calculations.
This is not ideal. Change one and you have to change the other correctly to match.

In recent C++ one could use constants expressions instead:

Code: Select all

constexpr int DIGITS = 9;                  // Decimal digits in each big integer array element.
constexpr int BASE = pow(10, DIGITS);      // The number base of our big integer calculations.
In C you can do:-

Code: Select all

#define DIGITS  9
const int BASE = pow( 10, DIGITS );
which achieves what you want, you only have to change DIGITS.

It would be fun to try fibo(4784969) as a constexpr but I think there are some strict rules they have to abide by such as not allocating memory (I think). If it worked, C++17 would be the clear winner performance wise!
I suspect the compile time of constexpr fibo(4784969) would approximate the run time of a BASIC interpreter, which should be avoided. Here is an updated table of timings taken on the Pi Zero:

Code: Select all

Results of code downloaded on January 13, 2019
from https://github.com/ZiCog/fibo_4784969.git

                   BUILD TIME    RUN TIME     TOTAL
serial                7.459       24.195     31.654
fibonacci             5.060       80.946     86.006
fibo_karatserial     56.154       40.090     96.244

gcc -O3 -o serial parallel.c -lm
gcc -O3 -o fibonacci fibonacci.c -lm
g++ -O3 -o fibo_karatserial fibo_karatsuba.cpp fibo.cpp -lm
Compile times for fibo_karatsuba have improved to the point where the total build plus run time is less than 100 seconds.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 2:48 am

ejolson,
I suspect the compile time of constexpr fibo(4784969) would approximate the run time of a BASIC interpreter, which should be avoided.
No doubt.

Still, the shipped binary would be blinding fast and satisfy the rules of the challenge as stated. (Actually the challenge did not mention performance criteria but never mind)

I sense a change of emphasis now that you guys are including build time in the performance metric.

That puts compiled languages on the same footing as interpreted ones. It's a measurement of time from source code to result, no matter what the source language, no matter if compiled or interpreted.

OK then. In some sense that makes Python the performance winner. It can get the result in 5 seconds on a Pi 3 vs 7.5 for the fastest C.

Admittedly it takes Python another 34 seconds to print the result, but perhaps a human readable output is not required. (Again the challenge as stated does not require that.)

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

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 4:17 am

Heater wrote:
Sun Jan 13, 2019 2:48 am
ejolson,
I suspect the compile time of constexpr fibo(4784969) would approximate the run time of a BASIC interpreter, which should be avoided.
No doubt.

Still, the shipped binary would be blinding fast and satisfy the rules of the challenge as stated. (Actually the challenge did not mention performance criteria but never mind)

I sense a change of emphasis now that you guys are including build time in the performance metric.

That puts compiled languages on the same footing as interpreted ones. It's a measurement of time from source code to result, no matter what the source language, no matter if compiled or interpreted.

OK then. In some sense that makes Python the performance winner. It can get the result in 5 seconds on a Pi 3 vs 7.5 for the fastest C.

Admittedly it takes Python another 34 seconds to print the result, but perhaps a human readable output is not required. (Again the challenge as stated does not require that.)
I had originally imagined doing something like

$ sed "s/4784969/7499/g" <fibonacci.c >f7499.c
$ make f7499
$ time ./f7499

to time each Fibonacci number but was astonished when the C++ compile times were greater than the run times.

Since there is no Karatsuba in the Python code, the runtime would unlikely reflect how efficiently new algorithms of similar complexity would perform in Python. The comments in the original C code state
fibonacci.c wrote:This program demonstrates the expressiveness of C as measured by explicitly coding the Karatsuba multiplication algorithm for big-number arithmetic and then using the doubling formulas blah, blah and blah to compute the nth Fibonacci number.
From my point of view the expressivity of a language for conveying an algorithm to a computer can be measured by the speed of the resulting executable. To do this the algorithms of interest have to be written in the language under consideration.

To determine whether a language is digitally liberating or not, I think run time would generally be more relevant than compile plus run time. However, both mono and the JVM employ just-in-time compilation techniques to obtain reasonable performance as does PyPy. In those cases compilation and execution times have already been confounded. Therefore, the question why avoid Visual BASIC on the Raspberry Pi may also need to take compilation times into consideration.

jahboater
Posts: 4474
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 8:37 am

Heater wrote:
Sun Jan 13, 2019 2:48 am
I sense a change of emphasis now that you guys are including build time in the performance metric.
Not for me.

I suppose its different for these fibo programs which are run once and then forgotten, but I normally try to produce useful programs that are run countless times.

As far as possible,I require that the executable contains no instructions that are not directly involved in solving the problem.

To that end, I avoid languages with automatic garbage collection, interpreted languages, even JIT interpreted languages.

Take a look at the system commands on Linux that are run frequently. They are often strung together in large numbers in shell scripts. Most of them are executed millions of times after compilation.
I mean things like:- test, sed, ls, cp, cut, awk, mv etc. They must be fast, and they must be fast to start up.

They are all compiled C programs, a few KB in size (test is 47KB, cp is 148KB, even the powerful language awk is only 630KB).

Imagine how slow shell scripts would run if each little program had to load an interpreter (15MB in the case of Javascript), load the program source, do the translation, do any optimization, as well as solve the problem??
Ridiculous. Utterly ridiculous

Code: Select all

$ time /bin/cp makefile /tmp/t

real	0m0.002s
user	0m0.000s
sys	0m0.000s
Two milliseconds elapsed to copy a 13KB file.
I challenge any fans of Python or Javascript to beat that :)

Compilers have no time limit and have access to the entire source file, even to a degree, other source files (LTO).
They might even have access to profiling feedback.

Obviously interpreters have to limit their optimization because the time required is eating into the total execution time. For long running programs it may be worthwhile, for short programs, it is a disaster. I doubt many (if any) interpreters will examine the entire source to understand how each piece of code is actually used, or even prove its not used at all.

Anything other than solving the problem is an overhead.

A = B + C must be one single machine instruction.
For any interpreted language it will be thousands.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 10:28 am

jahboater wrote:
Sun Jan 13, 2019 8:37 am
Heater wrote:
Sun Jan 13, 2019 2:48 am
I sense a change of emphasis now that you guys are including build time in the performance metric.
I suppose its different for these fibo programs which are run once and then forgotten, but I normally try to produce useful programs that are run countless times.
On the other hand, I've been running these useless fibo programs countless times.

I created a script to add volatility to the C intermediate files so the gcc optimizer doesn't clobber things and create a segmentation fault in the resulting executable. After completing a preliminary version of the compille using

fbc -O 3 -R -v -Wc -Wextra -lang qb integer.bas 2>warning.txt

I run the script

Code: Select all

#!/bin/bash
cp integer.c integervol.c
{
    for line in `grep clobber <warning.txt | cut -d: -f2`
    do
        echo ${line}s/int32/volatile int32/
    done
    echo w
    echo q
} | ed integervol.c
to add the volatility and then recompile the output integervol.c using the same commands as would have been used for the original. The result is slower build times because the compile has to be done twice and a 2.5-fold run time improvement over classic.bas as summarized in the following table:

Code: Select all

Pi Zero timings of code downloaded January 12, 2019
from https://github.com/ZiCog/fibo_4784969.git

                   BUILD TIME    RUN TIME     TOTAL
serial                7.459       24.195     31.654
fibonacci             5.060       80.946     86.006
fibo_karatserial     56.154       40.090     96.244
integervol           17.886       87.556    105.442
classic              10.851      217.004    227.855

gcc -O3 -o serial parallel.c -lm
gcc -O3 -o fibonacci fibonacci.c -lm
g++ -O3 -o fibo_karatserial fibo_karatsuba.cpp fibo.cpp -lm
fbc -O 3 -lang qb classic.bas
fbc -O 3 -R -v -Wc -Wextra -lang qb integer.bas 2>warning.txt
./addvolatile
gcc -march=armv6 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O3 -fno-strict-aliasing -frounding-math -fno-math-errno -fwrapv -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables "integervol.c" -o "integervol.asm"
as --strip-local-absolute "integervol.asm" -o "integervol.o"
ld -m armelf_linux_eabi -o "integervol" -dynamic-linker /lib/ld-linux-armhf.so.3 "/usr/local/fbc-300/bin/../lib/freebasic/linux-arm/fbextra.x" -s -L "/usr/local/fbc-300/bin/../lib/freebasic/linux-arm" -L "." -L "/usr/lib/gcc/arm-linux-gnueabihf/6" "/usr/lib/gcc/arm-linux-gnueabihf/6/../../../arm-linux-gnueabihf/crt1.o" "/usr/lib/gcc/arm-linux-gnueabihf/6/../../../arm-linux-gnueabihf/crti.o" "/usr/lib/gcc/arm-linux-gnueabihf/6/crtbegin.o" "/usr/local/fbc-300/bin/../lib/freebasic/linux-arm/fbrt0.o" "integervol.o" "-(" -lfb -ltinfo -lm -ldl -lpthread -lgcc -lgcc_eh -lc "-)" "/usr/lib/gcc/arm-linux-gnueabihf/6/crtend.o" "/usr/lib/gcc/arm-linux-gnueabihf/6/../../../arm-linux-gnueabihf/crtn.o"
The performance of integer.bas would have been 92 percent the best performing code back when fibonacci.c was the fastest program; however, now it achieves only 28 percent. Is this a reason to avoid BASIC?
Last edited by ejolson on Sun Jan 13, 2019 10:58 am, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 10:57 am

ejolson,
...was astonished when the C++ compile times were greater than the run times.
C++ can be annoyingly slow to compile. Especially when one is riffing on some new idea, the compile, edit, run development loop can get tedious. Make files and such ease that burden for large, multi-file projects. I think the trick to a rapid dev cycle with c++ is to avoid the std::, that pulls in all kind of header files and template instantiation takes forever. After all the Arduino guys get on quite quickly. Also switching off optimization during development is much faster.

Which is why when I want to play with a new idea I might first write it in a language that has a very fast edit, run development cycle. For this reason my first fibo doubling and karatsuba attempts were in Javascript. I wanted to quickly check that I understood the algorithms correctly and could make it work.

Typically the C/C++ programs I write have run times far longer than their compile times, months, years, they are embedded systems or server side processes. In which case the performance of C/C++ is important, as might be small memory foot print and such.
To determine whether a language is digitally liberating or not, I think run time would generally be more relevant than compile plus run time.
Historically the reverse is true.

Back in the depths of time it could take all night for students to get their initial attempts at programming compiled. That was certainly the case for me in university, punch program source onto cards, give cards to mainframe operators, wait til next morning for the print out. This is no way to get students excited about programming and a very slow learning process.

One solution at that time was the invention of BASIC. Sure the run time of the interpreted BASIC programs was a lot slower than the run time of the compiled ALGOL I was writing, for example, but the whole edit/run cycle was massively faster. Students could be engaged with this.

We see the same play out today. Beginners don't need the tedium of C++ compilation or the syntactic complexity of C/C++ etc. They need something simple and basic. Luckily today we have great options for this, Python, Javascript, and so on.

jahboater
Posts: 4474
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 11:05 am

Heater wrote:
Sun Jan 13, 2019 10:57 am
Which is why when I want to play with a new idea I might first write it in a language that has a very fast edit, run development cycle. For this reason my first fibo doubling and karatsuba attempts were in Javascript. I wanted to quickly check that I understood the algorithms correctly and could make it work.
Yes, I can see the use of interpreted languages for a feasability study or prototype, but ..................

Code: Select all

$ time gcc fibo.c -o fibo     

real	0m0.107s
user	0m0.080s
sys	0m0.016s
$ wc fibo.c
 341 1418 7125 fibo.c
On my PC it takes several times as long as that just to start node up.
So I would posit that C has "a very fast edit, run development cycle" ?

I see the Python folks are addressing this:
Python3.5 was 4.3MB
Python3.7 is 27KB !!!
Probably most of the work is now done in dll's.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 11:32 am

jahboater,
On my PC it takes several times as long as that just to start node up.
Something is wrong then:

Code: Select all

$ cat hello.c
#include <stdio.h>

int main (int argc, char* argv[]) {
    printf("Hello world\n");
    return 0;
}
$ time gcc-6 -Wall -Wextra -O3 -o hello hello.c ; ./hello

real    0m0.183s
user    0m0.016s
sys     0m0.094s
Hello world
$
$ cat hello.js
console.log('Hello world')
$ time node hello.js
Hello world

real    0m0.177s
user    0m0.063s
sys     0m0.109s
So I would posit that C has "a very fast edit, run development cycle" ?
Seems to be so now a days. At least for small programs. It certainly was not the case in years gone by, compiling anything with anything was a lot slower than talking to a BASIC interpreter.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 11:49 am

ejolson,
I created a script to add volatility to the C intermediate files so the gcc optimizer doesn't clobber things and create a segmentation fault in the resulting executable...
Ouch, what?!!

C/C++ optimizers do not "clobber" anything unless what what they are compiling makes use of some undefined behavior of the language (Barring compiler bugs). Use of undefined behavior means that anything can happen.

What you are saying is that the FreeBASIC code generator is buggy and it's generated C code is not guaranteed to run on all platforms with all standards compliant compilers, even with optimizations off.

Ideally it would be better to have the FreeBASIC devs fix these bugs rather than hack it with workarounds.

Personally I'd rather skip the middleman and write in C directly. I don't need any more bugs than I have already introduced by a code generator, especially when it serves no useful purpose.

jahboater
Posts: 4474
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sun Jan 13, 2019 12:35 pm

Heater wrote:
Sun Jan 13, 2019 11:49 am
What you are saying is that the FreeBASIC code generator is buggy and it's generated C code is not guaranteed to run on all platforms with all standards compliant compilers, even with optimizations off.
Its the use of setjmp/longjmp to implement gosub in basic.
Last edited by jahboater on Sun Jan 13, 2019 12:54 pm, edited 1 time in total.

Return to “Off topic discussion”