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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 8:19 am

I allowed my PC to upgrade to Windows 10 this week(er, could not figure out how to stop it, apart from postpone) ;)
MS Visual Studio , got the remains of ver 10 ,12 with full 14 and the Community version.
Version 14 is interesting, it has 6 compilers - arm, x86_arm, x86_amd, amd64, amd64_arm, amd_x86 :o

Windows IoT? Will VC compile for Pi's? Usable on Raspbian?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 9:28 am

ejolson wrote:
Fri Jan 25, 2019 1:07 am
While avoiding BASIC may be good, I think the reason most people avoid the Intel C compiler is because gcc is good. Another reason to avoid icc may be the warning
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
which appears on many pages of the documentation. In particular, the Intel C compiler has been observed to select suspiciously non-optimal code paths when running on non-Intel hardware. Price may also be a concern for some people.
Yes, all true.

In addition, GCC supports many many platforms other than x86 (such as RISC-V).

It is tempting to use GCC's useful extensions, simply because GCC is so widely available. Also other tier 1 compilers support most of GCC's extensions.

Support for the latest language standards is also GCC's strong point. There is, for example, experimental support for C++2x.
This is something the Microsoft compiler is (deliberately) bad at, presumably to save development cost.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 9:52 am

ejolson,
As a result, it would be interesting to measure the performance of fibo_karatsuba.cpp compiled with the Microsoft tools to a gcc-compiled version. For comparison purposes, both should be run as native applications to avoid any emulation layers such as Wine or Linux Subsystem for Windows.
Grrr...

Against my better judgement I took you up on that suggestion. I now have some reasons to avoid MS Visual Studio and VC++....

1) Installing Visual Studio has eaten 20 odd GB of my precious SSD space. I did not spot any option to install it elsewhere in the installer.

2) It's a lot of assing around to get a project defined out of the couple of files we have.

3) The resulting fibo, single threaded version, takes all day to run:

Code: Select all

$ time ./x64/Release/fibo_4784969.exe > /dev/null

real    0m5.212s
user    0m0.000s
sys     0m0.000s
[code]
Yes, I have optimizations turned on with /Ox

WTF?

4) I cannot build the mult-core OpenMP version. I get this error:
[code]
Error	C3001	'task': expected an OpenMP directive name	fibo_4784969	c:\users\michael\documents\fibo_4784969\c++\bint.h	330	
Google tells me this is because even Visual Studio 2017 still only supports OpenMP 2.0, while Tasks are an OpenMP 3.0 addition
WTF?

5) Having set the "USE_OMP" definition to build the OpenMP version I cant' find any way to remove that definition.
WTF?

Anyone with more knowledge of Visual Studio and VC++ like to look at this and see what's up with it?

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 9:57 am

Does /O3 work?

I changed to using mingw years ago on Windows and it was like a breath of fresh air ...

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 10:35 am

Is /O3 even a thing? Visual Studio is only offering /O1 and /O2 then /Ox or whatever.

OK, I think I figured it out. I was running from the LSW shell.

When I run it under LSW but don't redirect the output it completes in 1.3 seconds. Most of that is scrolling the output into the terminal window of course.

When I run it form the DOS command line I see that it is computing the result pretty quickly, then starts scrolling it to the screen. Which takes about 20 seconds!

Much the same if I use PowerShell

Anyone know how to discard the output and time thing thing like we do on Linux? Perhaps using PowerShell?

Edit:

I found that under PowerShell there is a neat way to measure execution time:

Code: Select all

PS C:\Users\michael\Documents\fibo_4784969\c++\x64\Release> Measure-Command { .\fibo_4784969.exe }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 866
Ticks             : 8663003
TotalDays         : 1.00266238425926E-05
TotalHours        : 0.000240638972222222
TotalMinutes      : 0.0144383383333333
TotalSeconds      : 0.8663003
TotalMilliseconds : 866.3003
The measure command eats the output in this case.

That is 866ms for VC++ vs the 666ms I achieve with GCC. 30% slower!

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 10:43 am

Heater wrote:
Fri Jan 25, 2019 10:35 am
Anyone know how to discard the output and time thing thing like we do on Linux? Perhaps using PowerShell?
What about the nul device?
>nul
or was it?
>nul:

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 10:55 am

Can't make anything to do with nul work. I just get PowerShell errors.

Interestingly, in PowerShell, if I run ./fibo_4784969.exe it takes about 20 seconds to scroll the output to the terminal. If I use the measure command it does that in about 1 second:

Code: Select all

> Measure-Command { .\fibo_4784969.exe | Out-Host }
....
3407167474856539211500699706378405156269

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 1
Milliseconds      : 140
Ticks             : 11408576
TotalDays         : 1.32043703703704E-05
TotalHours        : 0.000316904888888889
TotalMinutes      : 0.0190142933333333
TotalSeconds      : 1.1408576
TotalMilliseconds : 1140.8576
WTF?

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 11:00 am

On a hunch I found a "nul" thing that works in PowerShell. Like so:

Code: Select all

> Measure-Command { .\fibo_4784969.exe | Out-Null }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 875
Ticks             : 8755122
TotalDays         : 1.01332430555556E-05
TotalHours        : 0.000243197833333333
TotalMinutes      : 0.01459187
TotalSeconds      : 0.8755122
TotalMilliseconds : 875.5122
No help really.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 12:46 pm

For some kind of completeness I built the multi-core fibo_4784969 using std::async with VC++. With results like so:

Code: Select all

> Measure-Command { .\fibo_4784969.exe | Out-Null }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 315
Ticks             : 3158983
TotalDays         : 3.65623032407407E-06
TotalHours        : 8.77495277777778E-05
TotalMinutes      : 0.00526497166666667
TotalSeconds      : 0.3158983
TotalMilliseconds : 315.8983
Same speed as building with GCC under LSW on the same machine:

Code: Select all

$ time ./fibo_karatsuba > /dev/null

real    0m0.316s
user    0m1.250s
sys     0m0.406s
What does it all mean?

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 2:02 pm

Heater wrote:
Fri Jan 25, 2019 12:46 pm
real 0m0.316s
user 0m1.250s
sys 0m0.406s
[/code]
What does it all mean?
I assume you are referring to the user cpu time being greater than the elapsed time.
Some anomaly with WSL?

Are the clocks accessed by clock_gettime() available?
CLOCK_PROCESS_CPUTIME_ID cpu
CLOCK_THREAD_CPUTIME_ID thread specific cpu
CLOCK_REALTIME elapsed
CLOCK_MONOTONIC_RAW safer elapsed

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 2:38 pm

jahboater,
I assume you are referring to the user cpu time being greater than the elapsed time.
Some anomaly with WSL?
No, that is normal.

"user" is the time spent running user space code. When you have multiple cores on the job they can all be accumulating user time at the same time. Hence user > real.

In the same way "top" can show that your machine is using more than 100% CPU time.

What I meant is that our timings are all over the place, from architecture to architecture, machine to machine, compiler to compiler, with OpenMP or std::async.

It's kind of hard to know why and or what to do it about it. For example, why does ejolson report c++ as 20% (or whatever) faster than C on x86 but 20% slower on ARM? If one wanted to balance that out what would one do?

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 5:12 pm

Heater wrote:
Fri Jan 25, 2019 2:38 pm
I assume you are referring to the user cpu time being greater than the elapsed time.
Some anomaly with WSL?
No, that is normal.

"user" is the time spent running user space code. When you have multiple cores on the job they can all be accumulating user time at the same time. Hence user > real.
Doh! of course.
Heater wrote:
Fri Jan 25, 2019 2:38 pm
What I meant is that our timings are all over the place, from architecture to architecture, machine to machine, compiler to compiler, with OpenMP or std::async.

It's kind of hard to know why and or what to do it about it. For example, why does ejolson report c++ as 20% (or whatever) faster than C on x86 but 20% slower on ARM? If one wanted to balance that out what would one do?
Perhaps reduce the variables:-
For example, this is a Raspberry Pi forum, so perhaps limit the tests to that, preferably one single Pi model, running the official OS Raspbian Stretch. (make certain its not randomly throttling).
Go back to the "no extensions" rule. Which eliminates openMP and Silk. The std::async version of C++ is the only version of C++ fibo that need be tested.
Stick to one single compiler for each language (for C/C++ the one supplied with Raspbian, GCC 6.3).

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 5:55 pm

Heater wrote:
Fri Jan 25, 2019 12:46 pm
For some kind of completeness I built the multi-core fibo_4784969 using std::async with VC++. With results like so:

Code: Select all

> Measure-Command { .\fibo_4784969.exe | Out-Null }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 315
Ticks             : 3158983
TotalDays         : 3.65623032407407E-06
TotalHours        : 8.77495277777778E-05
TotalMinutes      : 0.00526497166666667
TotalSeconds      : 0.3158983
TotalMilliseconds : 315.8983
Same speed as building with GCC under LSW on the same machine:

Code: Select all

$ time ./fibo_karatsuba > /dev/null

real    0m0.316s
user    0m1.250s
sys     0m0.406s
What does it all mean?
There is an amazing coincidence: The run times are the same to within a millisecond. Does it mean that std::async is so efficient on Windows that it makes up for the 30% slower single-core performance of Visual C++?

Alternatively, one might marvel how glibc emulates POSIX threads using Linux native threads which are in turn emulated by Linux Subsystem for Windows in such a way that squanders a 30% lead in single core performance after parallelizing to only a couple cores. It makes one think Dave Cutler had SMP performance in mind when he designed the first versions of Windows NT.

The Fibonacci code would be significantly more interesting if the development of processors from Digital Equipment Corporation, Data General and Sun Microsystems had continued. It would also have been nice if Hewlett Packard hadn't partnered with Intel to sink with Itanium but instead continued to evolve Spectrum RISC in a way similar to IBM's Power architecture.

When people are tired of melting down, maybe the ShenWei SW26010 will be commoditised for the purpose of revealing secrets about the Fibonacci code. If anyone has access to one of these 256-core CPUs it would be interesting to know how parallel.c and fibo_karatsuba.cpp scale and which one achieves higher performance.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 25, 2019 7:14 pm

jahboater wrote:
Fri Jan 25, 2019 5:12 pm
Perhaps reduce the variables:-
For example, this is a Raspberry Pi forum, so perhaps limit the tests to that, preferably one single Pi model, running the official OS Raspbian Stretch. (make certain its not randomly throttling).
Go back to the "no extensions" rule. Which eliminates openMP and Silk. The std::async version of C++ is the only version of C++ fibo that need be tested.
Stick to one single compiler for each language (for C/C++ the one supplied with Raspbian, GCC 6.3).
Since the Pi Zero comes free with a magazine subscription, it makes a natural choice as an easily available computer to use for a standard means of comparison. Unfortunately, the relative speeds of the parallel.c and fibo_karatsuba.cpp switch depending on which computer architecture is used: The C code is 40% faster than the C++ code when running on the Zero; the C++ code is 40% faster than the C code when running on Xeon. Similar, but lesser differences occur when comparing a 64-bit Cortex-A53 to an Intel i5 processor.

What's further interesting is that both codes implement the same algorithms: Karatsuba multiplication with identical doubling formulas to compute Fibonacci numbers. The only differences are in the details of the addition, subtraction and O(n^2) multiplication routines as well as the way memory is allocated. One conjecture is that the hardware features which cause the Meltdown and Spectre side-channel security problems are the same features which allow the Intel architecture to run the C++ code so quickly. This makes one wonder which program runs faster on 486 and early Pentium processors. Less historical would be comparisons made using the most recent versions of ARM, MIPS, Power, SPARC and ShenWei processors. Alas, none of those come free with a magazine.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 26, 2019 4:51 am

Last Christmas I practiced a tried and tested method of shopping for computers: Walk into the store and buy the cheapest available. As the shop didn't sell Raspberry Pi, this resulted in a notebook computer equipped with 4GB RAM, 1TB HD and a dual-core AMD A6-9225 CPU for about 7 times more. The timings for the C and C++ Fibonacci codes are as follows:

Code: Select all

$ make
/usr/local/gcc-8.2/bin/gcc -O3 -march=native -mtune=native -fopenmp -o parallel fibo_4784969/c/parallel.c -lm
/usr/local/gcc-8.2/bin/g++ -O3 -march=native -mtune=native -DUSE_OMP -fopenmp -std=c++17 -o fibo_karatomp \
    fibo_4784969/c++/fibo_karatsuba.cpp fibo_4784969/c++/fibo.cpp -lm
$ time ./parallel >/dev/null

real    0m0.603s
user    0m1.172s
sys 0m0.004s
$ time ./fibo_karatomp >/dev/null

real    0m0.475s
user    0m0.872s
sys 0m0.004s
The conclusion is that the C++ code runs 27 percent faster than the C code on the A6-9225.

This is not surprising, because fibo_karatsuba.cpp has proven to be faster on all other x86-architecture machines tested so far. I wonder if there is any Intel-compatible computer where parallel.c runs faster or any ARM-based computer where fibo_karatsuba.cpp is faster.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 26, 2019 7:18 am

ejolson,

I'm still wondering why you are seeing the C++ so much faster than the C on Intel. Here on my LSW they are neck and neck, if anything I would say parallel.c was a tad faster on average:

Code: Select all

$ gcc -O3 -march=native -mtune=native -fopenmp -o parallel fibo_4784969/c/parallel.c -lm
$ g++ -O3 -march=native -mtune=native -DUSE_OMP -fopenmp -std=c++17 -o fibo_karatomp  fibo_4784969/c++/fibo_karatsuba.cpp fibo_4784969/c++/fibo.cpp -lm

$ time ./parallel >/dev/null
Using 8 cores.

real    0m0.232s
user    0m1.203s
sys     0m0.078s

$ time ./fibo_karatomp >/dev/null

real    0m0.238s
user    0m1.203s
sys     0m0.125s
I have to fire up a real Debian and check again.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 26, 2019 3:03 pm

ejolson,
There is an amazing coincidence: The run times are the same to within a millisecond. Does it mean that std::async is so efficient on Windows that it makes up for the 30% slower single-core performance of Visual C++?
Quite a coincidence. But those times jump all around +/-10% or more. Without doing repeated runs and looking at mins or means or whatever it does not show much difference. I have no idea what is going on w.r.t single/multi-core times there.
The Fibonacci code would be significantly more interesting if the development of processors from Digital Equipment Corporation, Data General and Sun Microsystems had continued. It would also have been nice if Hewlett Packard hadn't partnered with Intel to sink with Itanium but instead continued to evolve Spectrum RISC in a way similar to IBM's Power architecture.
That would have been interesting indeed. Even more perplexing than the results we for the few platforms we have now!

A devious mind might suspect that Intel pushed out the sinking ship "Itanic" specifically to take down the competitors that jumped on board.

But wait, we have a new and different architecture. At some point I want to this to run on RISC V on my FPGA board...
Since the Pi Zero comes free with a magazine subscription, it makes a natural choice as an easily available computer to use for a standard means of comparison.
That does not work for me. I have never seen a Pi Zero in the flesh, nor a MagPi magazine.

What is that 8 core ARM SBC you have been using anyway ?
This makes one wonder which program runs faster on 486 and early Pentium processors...
Sadly I did not keep my 100MHz AMD 486. It was great for it's day.
Maybe it is time to begin the challenge of which programming language is best suited for creating a graphical networked version of the classic Star Trader game.
Interesting idea. I have no idea how well BASIC compares to Scratch, I have never seen a scratch. I recall that years ago my 12 year old son was totally engrossed in creating games in some game creation system or other. I was happy about that, it was programming rather than just playing. Mind you he was also totally taken with how Python could do huge integer arithmetic...

Looking at the Star Trader source I see that it is huge. We would have a hard time defining the challenge in the first place. Then, it's a lot of work for anyone to take on just for a little language comparison challenge.

Don't forget the fibo challenge was not really about Fibonacci, high performance/parallel computing or even performance at all. It was just a just an off-the-cuff challenge to do in BASIC what can be done in 10 mins in other languages.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 26, 2019 6:24 pm

Heater wrote:
Sat Jan 26, 2019 3:03 pm
What is that 8 core ARM SBC you have been using anyway?
I've been using the NanoPC-T3 based on the Nexell S5P6818 octa-core SOC. It is nice for parallel processing because all eight cores are identical (no big.LITTLE) and they scale rather well.

I've found an Intel-compatibile CPU which runs the C code 44 percent faster than the C++ code: an original 32-bit 1.4-GHz AMD Athlon. Results are

Code: Select all

$ /usr/local/gcc-6.5/bin/gcc -O3 -march=native -mtune=native -o serial fibo_4784969/c/parallel.c -lm
$ /usr/local/gcc-6.5/bin/g++ -O3 -march=native -mtune=native -std=c++17 -o fibo_karatser fibo_4784969/c++/fibo_karatsuba.cpp fibo_4784969/c++/fibo.cpp -lm
$ time ./fibo_karatser >/dev/null

real    0m7.096s
user    0m7.064s
sys 0m0.024s
$ time ./serial >/dev/null

real    0m4.906s
user    0m4.892s
sys 0m0.008s
So as not to confound effects, it is worth mentioning that by coincidence all machines where the C code is faster were tested using a version-6.x gcc compiler while all the machines where C++ was faster used a version-8.x compiler. After building a 32-bit version-8.2 compiler I'll rerun the tests and report any changes. This should determine whether hardware or the compiler is the deciding factor.

Maybe Star Trader should start a new thread under Other Projects rather than a continuation of this off-topic thread, especially as the conclusion is likely to favour the use of Basic on the Raspberry Pi rather than avoid it, or not. Are you sure Star Trader is more lines than the C++ Fibonacci code?

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

Re: Why Avoid BASIC on RPi?

Sat Jan 26, 2019 10:48 pm

ejolson,
Maybe Star Trader should start a new thread under Other Projects rather than a continuation of this off-topic thread,...
I would say yes to that. I have long thought the fibo_4784969 should have been forked into it's own thread as it grew in scope so much. Some how that never happened.
...especially as the conclusion is likely to favour the use of Basic on the Raspberry Pi rather than avoid it...
That's a big assumption given all the other ways one can create a game with graphics and networking now a days.
...or not.
Exactly.
Are you sure Star Trader is more lines than the C++ Fibonacci code?
Ah, hemm, ... no idea. Things did get rather out of hand. As I said above somewhere. Certainly the challenge can be specified in far less space.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 27, 2019 7:31 pm

ejolson wrote:
Sat Jan 26, 2019 6:24 pm
After building a 32-bit version-8.2 compiler I'll rerun the tests and report any changes. This should determine whether hardware or the compiler is the deciding factor.
The C code is 82 percent faster than the C++ code when using gcc version 8.2 on the Athlon 1400 processor. I hadn't expected that. Specifically we have

Code: Select all

$ /usr/local/gcc-8.2/bin/gcc -O3 -march=native -mtune=native -o serial fibo_4784969/c/parallel.c -lm
$ /usr/local/gcc-8.2/bin/g++ -O3 -march=native -mtune=native -std=c++17 -o fibo_karatser fibo_4784969/c++/fibo_karatsuba.cpp fibo_4784969/c++/fibo.cpp -lm
$ time ./fibo_karatser >/dev/null

real    0m7.065s
user    0m7.028s
sys 0m0.032s
$ time ./serial >/dev/null

real    0m3.865s
user    0m3.848s
sys 0m0.012s
While the results are strange, it is satisfying to see that both the C and C++ codes run faster with gcc version 8.2 than the version-6.5 compiler. In summary the times in seconds are

Code: Select all

32-BIT 1400-MHZ AMD ATHLON GCC VERSION COMPARISON
  
                       GCC 6.5   GCC 8.2   Ratio
parallel.c              4.906     3.865    1.269
fibo_karatsuba.cpp      7.096     7.065    1.004
Therefore, the C code is faster than the C++ code on the Athlon 1400. The results make me want to try gcc version 8.2 on the Pi Zero to see if there is a similar difference between compiler versions.

What remains, aside from avoiding BASIC, is to find an ARM processor (if such a processor exists) on which the C++ code runs faster than the C code.
Last edited by ejolson on Sun Jan 27, 2019 8:11 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 27, 2019 8:09 pm

Wow, that's pretty dramatic.

I'm sure that is trying to tell me something deep. I have no idea what it might be exactly.

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

Re: Why Avoid BASIC on RPi?

Sun Jan 27, 2019 8:31 pm

Heater wrote:
Sun Jan 27, 2019 8:09 pm
Wow, that's pretty dramatic.

I'm sure that is trying to tell me something deep. I have no idea what it might be exactly.
I'm pretty impressed that the newest version of gcc improves performance by 27 percent over version 6.5 on CPUs that are 20 years old. One wouldn't think such old hardware is even tested for regressions anymore, but there it is. I guess the optimizer has become quite general.

It is tempting to go back in time to the historical 2.x, 3.x and 4.x series gcc compilers and see how they compare; however, maybe it is better to make a modern graphical networked Star-Trader game. That would provide a different perspective about why to avoid BASIC and might encourage renewed participation in this thread, or definitively end it.

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

Re: Why Avoid BASIC on RPi?

Mon Jan 28, 2019 8:32 pm

ejolson wrote:
Sun Jan 27, 2019 8:31 pm
It is tempting to go back in time to the historical 2.x, 3.x and 4.x series gcc compilers and see how they compare
I have encountered a missing headers error when trying to build gcc version 2.95.3 on a fairly recent Debian distribution. Specifically, I have

Code: Select all

In file included from /usr/include/stdlib.h:25,
                 from ../../gcc-2.95.3/gcc/libgcc2.c:41:
/usr/include/features.h:323: bits/predefs.h: No such file or directory
/usr/include/features.h:356: sys/cdefs.h: No such file or directory
/usr/include/features.h:388: gnu/stubs.h: No such file or directory
In file included from ../../gcc-2.95.3/gcc/libgcc2.c:41:
/usr/include/stdlib.h:42: bits/waitflags.h: No such file or directory
/usr/include/stdlib.h:43: bits/waitstatus.h: No such file or directory
/usr/include/stdlib.h:320: sys/types.h: No such file or directory
In file included from ../../gcc-2.95.3/gcc/libgcc2.c:42:
/usr/include/unistd.h:203: bits/posix_opt.h: No such file or directory
/usr/include/unistd.h:207: bits/environments.h: No such file or directory
/usr/include/unistd.h:218: bits/types.h: No such file or directory
In file included from ../../gcc-2.95.3/gcc/libgcc2.c:42:
/usr/include/unistd.h:606: bits/confname.h: No such file or directory
make[1]: *** [libgcc2.a] Error 1
which seems to result from a few files being moved to /usr/include/i386-linux-gnu that used to be elsewhere. This is probably not too hard to remedy. Does anyone know the official best-practices way?

Maybe avoiding older versions of gcc is as important as avoiding BASIC.

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

Re: Why Avoid BASIC on RPi?

Tue Jan 29, 2019 7:06 am

Not an answer, but FYI there are some older versions of GCC available in the repositories:-

Code: Select all

pi@pi3:~ $ apt-cache search gcc | grep "gcc-.*GNU.*compiler$"
gcc-4.4 - GNU C compiler
gcc-4.6 - GNU C compiler
gcc-4.7 - GNU C compiler
gcc-4.8 - GNU C compiler
gcc-4.9 - GNU C compiler
gcc-5 - GNU C compiler
gcc-6 - GNU C compiler
They don't go back very far, but easier than trying to build them.

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

Re: Why Avoid BASIC on RPi?

Tue Jan 29, 2019 7:47 am

Wow, GCC 2.95.3 dates back to March 16, 2001.

I have no idea about "best practices" for resolving such header problems. What you are trying to do there is something akin to building a cross compiler. A feat that I have only managed to pull off a couple of times when I really had to (and someone was paying).

Aren't some of those headers machine and/or kernel specific (../bits/...)? I seem to recall having to have the appropriate kernel header files installed to build libgcc. Do you have kernel header files installed?

https://gcc.gnu.org/onlinedocs/libstdc+ ... ation.html

I'd be tempted to boot up a 2001 vintage Linux distribution in a virtual machine and use the GCC in there.

After all that the C++ code will not compile there as it uses C++11 features. Still it would be interesting to see how C/C++ optimization has improved over the years.

Return to “Off topic discussion”