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

Re: Why Avoid BASIC on RPi?

Tue Jan 08, 2019 2:59 pm

ejolson,
expressiveness -
The quality of effectively conveying an algorithm to a CPU or similar computing hardware.


From a clarity and syntax point of view there may be a difference, but from the computer's point of view both expressions express the same thing and in this sense are exactly equally expressive.
Ah yes.

There is that aspect of "expressiveness", who, or what, are we making the expression to? Who is the audience?

I can express my thoughts in English, that means nothing to someone who only speaks Chinese. For them the quality of my ability to express a thought is very poor.

I can express my algorithms in Haskell but that has zero expressiveness to a machine with no Haskell compiler.

I can express my programs in x86 assembler and it means nothing to my Raspberry Pi.

And so on...

That's definition of expressiveness is important, after all we do want our programs to run. Pseudo code will not do.

However, I don't think you actually believe your own definition, or perhaps might like to revise it some how. The most effective way to "convey an algorithm to a CPU" is as a binary executable. A binary blob dropped into memory, a Linux elf, a Windows .exe. I'm guessing you don't want to present your challenge solution in binary! I have had to assemble by hand on paper and create hexadecimal to load to the machine, I think that is a bit to low level too.

I conclude you mean something a bit different. It's clear though that you mean to prioritize expression to the machine more than expression to other programmers.
Haskell is fast with big numbers because GMP is fast.
I would disagree there. Haskell, the language, knows nothing of GMP.

The Glasgow Haskell compiler I am using certainly uses GMP under the hood. But that is an implementation detail. I'm sure it could use some other big maths library. I guessing one could write the entire Haskell compiler in Haskell including big integer support. I have no idea if that is possible or if anyone has done it or if it would perform well. It just seems like it should be so. Perhaps a Haskell guru could chip in here.
To see whether Haskell is useful for efficiently expressing new algorithms, one needs a new algorithm to express.
Yeah, perhaps. The algorithms we have been playing with here were new to me when we started. I guess that put's me in the perfect position to evaluate language expressiveness here :)
Memory in C++ is a leaky abstraction .

User avatar
Paeryn
Posts: 2943
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Why Avoid BASIC on RPi?

Tue Jan 08, 2019 4:19 pm

Heater wrote:
Tue Jan 08, 2019 2:59 pm
Haskell is fast with big numbers because GMP is fast.
I would disagree there. Haskell, the language, knows nothing of GMP.

The Glasgow Haskell compiler I am using certainly uses GMP under the hood. But that is an implementation detail. I'm sure it could use some other big maths library. I guessing one could write the entire Haskell compiler in Haskell including big integer support. I have no idea if that is possible or if anyone has done it or if it would perform well. It just seems like it should be so. Perhaps a Haskell guru could chip in here.
You're right, Haskell doesn't care about how Integers are implemented, just that they are. GHC uses GMP but it could equally use any other library or roll its own, but GMP is well known and fast in most cases. Think of it like C has floats even though the underlying CPU could be integer only (e.g. 68000), you expect in these cases that the compiler will provide the support code to implement floats, you wouldn't have to supply your own.

GHC itself is written in Haskell, some of the run time system is written in C but as far as I'm aware that is all. It has a native code generator but I think that only targets x86 (and probably x64), for other architectures like Arm it generates LLVM code and hands it over to LLVM to create object files and then those to LD to link everything and make the final executable.
She who travels light — forgot something.

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

Re: Why Avoid BASIC on RPi?

Tue Jan 08, 2019 4:43 pm

The list is endless:

CPU's don't understand functions, parameters, return values, local variables, C does.
CPU's don't understand structures or arrays (mostly), C does.
CPU's don't understand complex numbers, C does.

I have yet to find any CPU that deals with complex numbers in hardware. I have sometimes wondered why not? Is there or has there ever been such a CPU?
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Tue Jan 08, 2019 7:16 pm

Is threading under Windows massively slower than threading under Linux?

I ask because I was doing some experiments with threading and the big integer multiply. Which seems to show that using two threads on my 3GHz 8 hyper thread x86 is about twice as slow as using two threads on my 1GHz 4 core Raspberry 3!

My simple benchmark looks like this:

Code: Select all

bint power(int n)
{
	bint x = bint("1");
	bint ten = bint("10");
	for (int i = 0; i < n; i++) { 
		x = x * ten;
	}
	return x;
}

// Define threaded mul benchmark
static void BM_mulThreaded(benchmark::State& state) {
	int n = state.range(0);
	for (auto _ : state) {
		auto future1 = std::async(power, n);
		auto future2 = std::async(power, n);
		benchmark::DoNotOptimize(res1 = future1.get());
		benchmark::DoNotOptimize(res2 = future2.get());
	}
}
BENCHMARK(BM_mulThreaded)->RangeMultiplier(2)->Range(1<<4, 1<<16)->Unit(benchmark::kMillisecond);

// Define mul benchmark
static void BM_mul(benchmark::State& state) {
	int n = state.range(0);
	for (auto _ : state) {
		benchmark::DoNotOptimize(res1 = power(n));
		benchmark::DoNotOptimize(res2 = power(n));
	}
}
BENCHMARK(BM_mul)->RangeMultiplier(2)->Range(1<<4, 1<<16)->Unit(benchmark::kMillisecond);

BENCHMARK_MAIN();
It just uses a simple function to calculate ever increasing powers of 10.

Here are the results with some annotations of my own:

Code: Select all

x86:

----------------------------------------------------------------
Benchmark                     Time             CPU   Iterations
----------------------------------------------------------------
BM_mulThreaded/16         0.155 ms        0.117 ms         6921      <-- Run time dominated by thread creation etc. c.f. BM_mul/16 below
BM_mulThreaded/32         0.156 ms        0.103 ms         5600
BM_mulThreaded/64         0.158 ms        0.119 ms         4978
BM_mulThreaded/128        0.163 ms        0.106 ms         8960
BM_mulThreaded/256        0.181 ms        0.112 ms         5600      <-- Now run time starts to ramp up with actual work
BM_mulThreaded/512        0.253 ms        0.096 ms         8960 
BM_mulThreaded/1024       0.588 ms        0.131 ms        11200      <-- Now using threads starts to win. c.f. BM_mul/1024 below
BM_mulThreaded/2048        2.35 ms        0.157 ms         4480
BM_mulThreaded/4096        13.3 ms        0.172 ms         1000
BM_mulThreaded/8192        90.2 ms        0.469 ms          100
BM_mulThreaded/16384        671 ms        0.000 ms           10      <-- Something very wrong with google benchmark CPU time here! 
BM_mulThreaded/32768       5149 ms        0.000 ms            1
BM_mulThreaded/65536      40472 ms        0.000 ms            1      <-- Using two threads is twice as fast. c.f. BM_mul/65536 below.
BM_mul/16                 0.002 ms        0.002 ms       320000
BM_mul/32                 0.004 ms        0.004 ms       186667
BM_mul/64                 0.008 ms        0.008 ms        89600
BM_mul/128                0.017 ms        0.017 ms        37333
BM_mul/256                0.050 ms        0.050 ms        10000
BM_mul/512                0.176 ms        0.180 ms         4073
BM_mul/1024               0.752 ms        0.750 ms          896
BM_mul/2048                4.03 ms         4.02 ms          179
BM_mul/4096                25.1 ms         25.7 ms           28
BM_mul/8192                 175 ms          172 ms            4
BM_mul/16384               1298 ms         1312 ms            1
BM_mul/32768              10045 ms        10031 ms            1
BM_mul/65536              78844 ms        78844 ms            1


Rasperry Pi:

----------------------------------------------------------------
Benchmark                     Time             CPU   Iterations
----------------------------------------------------------------
BM_mulThreaded/16         0.088 ms        0.067 ms         9183      <-- Run time dominated by thread creation etc. c.f. BM_mul/16 below
BM_mulThreaded/32         0.094 ms        0.072 ms         9681
BM_mulThreaded/64         0.106 ms        0.071 ms         9852
BM_mulThreaded/128        0.139 ms        0.071 ms         9908      <-- Now run time starts to ramp up with actual work
BM_mulThreaded/256        0.249 ms        0.071 ms        10006      <-- Now using threads starts to win. c.f. BM_mul/256 below
BM_mulThreaded/512        0.699 ms        0.070 ms        10049                   NOTE: Earlier than for Windows above.
BM_mulThreaded/1024        2.93 ms        0.072 ms         1000
BM_mulThreaded/2048        16.7 ms        0.086 ms         1000
BM_mulThreaded/4096         110 ms        0.138 ms          100
BM_mulThreaded/8192         797 ms        0.146 ms           10
BM_mulThreaded/16384       6064 ms        0.187 ms            1
BM_mulThreaded/32768      47486 ms        0.159 ms            1
BM_mulThreaded/65536     376413 ms        0.211 ms            1      <-- Using two threads is twice as fast. c.f. BM_mul/65536 below.
BM_mul/16                 0.012 ms        0.012 ms        56559
BM_mul/32                 0.023 ms        0.023 ms        30157
BM_mul/64                 0.049 ms        0.049 ms        14405
BM_mul/128                0.113 ms        0.113 ms         6169
BM_mul/256                0.331 ms        0.331 ms         2112
BM_mul/512                 1.21 ms         1.21 ms          577
BM_mul/1024                5.65 ms         5.65 ms          124
BM_mul/2048                33.2 ms         33.2 ms           21
BM_mul/4096                 220 ms          220 ms            3
BM_mul/8192                1594 ms         1594 ms            1
BM_mul/16384              12132 ms        12130 ms            1
BM_mul/32768              94904 ms        94897 ms            1
BM_mul/65536             752072 ms       752014 ms            1
This shows that Windows threading is a lot slower than the Pi.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 1:41 am

Heater wrote:
Tue Jan 08, 2019 7:16 pm
Is threading under Windows massively slower than threading under Linux?
In order from fastest to slowest:

1. Linux native threads.
2. Windows native threads.
3. POSIX threads emulated by glibc using Linux native threads.
4. POSIX threads emulated by glibc using Linux native threads which are in turn emulated by Linux subsystem for Windows.

I do not think there is much difference between 1 and 2; however, there is significant difference between 2 and 3 and likely 3 and 4. Historically the Cilk runtime was more efficient on Windows because it directly used Windows native threads whereas on Linux it used POSIX threads.

How effectively a programming language maps algorithms onto the hardware features of a particular computer architecture is greatly influenced by the quality of the complier. One of the reasons C was expressive enough to write an operating system is largely due to the quality of the PDP-11 executables generated by Kernighan and Ritchie's original compiler. It is interesting that the portable C compiler pcc written to replace that compiler never generated such efficient executables. The importance of C for Linux and Unix programming along with a bunch of valuable code written in that language has led to independent well-funded efforts to create good C compilers. The dominance of C and C-like programming languages has also affected the design of the hardware itself. These are some of the reasons why C continues to be liberating as an effective way to convey new algorithms to CPUs and similar hardware.

In a way it is rather boring that special hardware designed to run LISP is no longer manufactured and that there are no efforts to create hardware specifically designed for Haskell. We do, however, have GPUs with highly-optimised half-precision arithmetic useful for deep-learning neural networks and little else.

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 4:46 am

Thing is, I generally find that the Pi runs code ten or so times slower than my Windows machine. This benchmark shows that creating, scheduling and destroying two threads takes twice as long on Windows as the Pi. That is not just some clock relative time that is actual wall clock time. I find it hard to believe Windows is 20 or so times slower normalized for the same clock rate.

Then again the benchmark indicates it takes about 100us to do this on Windows. That's time for a hundred thousand or more instructions, seems very slow. Similarly on the Pi.

Perhaps this is a weird side effect of the benchmark library itself. It's clearly getting CPU time wrong. It drops to zero when that is clearly not possible. I wonder if the benchmark has some confusion when using threads.

Then I was wondering if my using the Linux Subsystem for Windows was slowing things down.

What I need is some kind soul with MS Windows to try that benchmark. If I understand correctly the Google benchmark library is buildable with MSVC.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 5:12 am

I went looking for better languages for multicore stuff and found Pony.
Pony makes it easy to write fast, safe, efficient, highly concurrent programs.
Will that help my slow, buggy coding style?

Guess what the math example is ;)
https://stdlib.ponylang.io/src/math/fibonacci/

And yes Pony does compile on Raspbian, even on an old model B :o

Is it faster than C?
Is anything faster than C? that's not assembler ;)

It there a multicore aware Basic?

Pony uses LLVM, why not write in LLVM directly? Can you?
.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 5:43 am

Gavinmc42,
...Pony...
Oh my God, YAFL. (I'll leave it to you to decide what "YAFL" means.)

When you have built and run the fibo(4784969) challenge in Pony and presented the results I might add the Pony solution to the challenge repository.
Is it faster than C?
When you have completed the fibo(4784969) in Pony you will have the answer to that.
Is anything faster than C? that's not assembler
Probably not.
It there a multicore aware Basic?
Probably not.
Pony uses LLVM, why not write in LLVM directly? Can you?
Sure. Start here: http://releases.llvm.org/2.6/docs/tutor ... rial1.html

We look forward to your fibo(4784969) challenge entry in LLVM.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 7:00 am

Oh my God, YAFL. (I'll leave it to you to decide what "YAFL" means.)
Took me a nano second to figure that TLA out, that's exactly what I thought when I found Pony :lol:

Won't build on my Gentoo64 yet, it expects LLVM 3.9.1 and I have 7.0.0.
Not supposed to work on Arm32 but it did compile on Raspbian and does seem to run the tests/benchmarks.

For some reason exploring new languages on Pi's does not worry me.
If I breaks it no big deal, swap SD card.

New tools on my work Windows PC, nope it's Windows, yuk.
Ditto for Docker/QEMU, extra layers just confuse me.
Home Linux box again no big deal, I use it as a reference for my Pi's.

LLVM does seem to get everywhere, hmm now 7.0.1, I'm falling behind ;)
Did you guys use GCC or Clang?
Is there a speed difference?
Looks like LLDB needs to go on my list of learning stuff too.

fibo(4784969) is more about algorithms and tricks than language speed now.
Only started Donald Knuth's The Art of Computer Programming Vol4A this week, big read.
But I do understand the point he made in the preface, algorithms are even more important now that we are speed limited.
So much to learn.

Now I am wondering what is the best language for AI/ML/Neural Network coding?
There must be something better than C/C++ on Xilinx's Versal ACAP chip?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jahboater
Posts: 5647
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 7:55 am

Gavinmc42 wrote:
Wed Jan 09, 2019 7:00 am
Did you guys use GCC or Clang?
I use GCC on all my development machines, always the latest version, currently 8.2
Raspbian comes with GCC pre-installed but it is an old, unsupported, version 6.3
Clang may installed if you want to try that with "sudo apt install clang"
Gavinmc42 wrote:
Wed Jan 09, 2019 7:00 am
Is there a speed difference?
Good question. A quick timed run of fibo 4784969 compiled with just "-O3" on the Pi3B+ gives:

Code: Select all

 $ time ./fibo_gcc >/dev/null

real	0m16.893s
user	0m16.850s
sys	0m0.040s
$ time ./fibo_clang >/dev/null

real	0m45.071s
user	0m45.040s
sys	0m0.020s
However that is not the entire story.
GCC is the latest version (8.2) built on the Pi3+ for the Pi3+.
I installed clang on my Pi3+ with apt get for the above test, and as usual, its an old version for an old CPU model:

Code: Select all

clang version 3.8.1-24+rpi1 (tags/RELEASE_381/final)
Target: armv6--linux-gnueabihf
Looking at the assembler output from the two compilers:
gcc 914 instructions, clang 1380 instructions.

It may be possible to get better results from Clang by specifying the target CPU model/architecture. But the man page is unhelpful:

Code: Select all

-arch <architecture>
       Specify the architecture to build for.
A full manual will be on the website.

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 9:00 am

Stuff on Debian based Raspbian can be dated.
3 times slower is horrible ;)

Gentoo64 - GCC 8.2.0, Clang 7.0.0, hmm does LLVM/Clang come as a package deal?
Guess I need to run that fibo code, now ;)

Wonder if there is OpenGL benchmark for languages?
Been trying to pick a language for messing about with OpenGL(ES) gaming.

Wonder where Free Pascal, Rust, GO and now Pony fit, between GCC and Clang?
Rust and Pony are LLVM based so similar speed to Clang.
Go is also LLVM now?

How to benchmark these without silly fibo code.

Has Basic ever been used as a script language for games?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
davidcoton
Posts: 4892
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK
Contact: Website

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 11:08 am

Gavinmc42 wrote:
Wed Jan 09, 2019 5:12 am
I went looking for better languages for multicore stuff and found Pony.
Pony makes it easy to write fast, safe, efficient, highly concurrent programs.
Just make sure that you use the Pink version on your Pi. :lol:
Signature retired

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 5:21 pm

God damn Windows 10.

So I thought a 3 times slow down when our fibo() is compiled with clang was a bit extreme. I'd better install a current clang and check for myself.

So I checkout the latest clang/llvm sources, and start to build it. Then I go out and take care of business for the day.

On my return, I find Win 10 has logged me out and everything I had running is not running anymore. The clang build is not complete of course. Presumably some Win 10 update has been going on.

This OS is out of my control. It's not an operating system at all. At least not for me, for someone else out there perhaps.

A curse on MS and their malware.

Sorry, rant over.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5647
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 5:30 pm

You can see why Linux dominates the server market!

Is it possible to build and install the latest Clang version on Raspbian?

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 5:50 pm

I don't see why not.

Just follow the instructions here: https://clang.llvm.org/get_started.html

Be sure you have file system space enough.

Might be easier and quicker than doing it on Win 10
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5647
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 5:59 pm

Heater wrote:
Wed Jan 09, 2019 5:50 pm
I don't see why not.

Just follow the instructions here: https://clang.llvm.org/get_started.html

Be sure you have file system space enough.

Might be easier and quicker than doing it on Win 10
I'll have a go when its finished building Python 3.7.2 ...

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 9:36 pm

Code: Select all

[ 92%] Linking CXX executable ../../../../../../bin/clangd
/usr/bin/ld: final link failed: No space left on device
Grrr....
Memory in C++ is a leaky abstraction .

User avatar
Paeryn
Posts: 2943
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 10:02 pm

Heater wrote:
Wed Jan 09, 2019 9:36 pm

Code: Select all

[ 92%] Linking CXX executable ../../../../../../bin/clangd
/usr/bin/ld: final link failed: No space left on device
Grrr....
Did you configure it for release mode? By default clang/llvm builds in debug mode and the files it creates are humongous (talking GBytes).
She who travels light — forgot something.

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 10:19 pm

No idea. Just following the instructions I linked above. No mention of release mode or any other mode there.

But of course, they have this other "Getting Started" page here: https://llvm.org/docs/GettingStarted.html which does talk about release types.

Grrr....
Memory in C++ is a leaky abstraction .

User avatar
Paeryn
Posts: 2943
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 10:46 pm

Heater wrote:
Wed Jan 09, 2019 10:19 pm
No idea. Just following the instructions I linked above. No mention of release mode or any other mode there.

But of course, they have this other "Getting Started" page here: https://llvm.org/docs/GettingStarted.html which does talk about release types.

Grrr....
It does, in step 7, though it doesn't tell you how to choose release (like the llvm page does)...
clang - getting started wrote: Build LLVM and Clang:
mkdir build (in-tree build is not supported)
cd build
cmake -G "Unix Makefiles" ../llvm
make
This builds both LLVM and Clang for debug mode.
It defaults to debug because it is assumed that if you are compiling them then you are doing so as developers. End users are not the target audience of the source code, they expect that those will use distro supplied packages.
She who travels light — forgot something.

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

Re: Why Avoid BASIC on RPi?

Wed Jan 09, 2019 11:26 pm

Paeryn,
It defaults to debug because it is assumed that if you are compiling them then you are doing so as developers. End users are not the target audience of the source code, they expect that those will use distro supplied packages.
That makes sense.

But I want a new clang not an old one that comes with apt-get.

Having built kernels, compilers, applications, in fact entire Linux systems since 1998 I'm not about to let building clang defeat me.

There is always a little fight with configs, dependencies and so on...
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 12:53 am

Fourteen hours later, after disk full, out of memory and many beers, we have...clang!

Code: Select all

$ /usr/local/bin/clang++ -v
clang version 8.0.0 (trunk 350699)
Target: x86_64-unknown-linux-gnu
...
$ /usr/local/bin/clang++ -std=c++17 -Wall -Wextra -O3 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
$ time ./fibo_karatsuba | tail -c 32
4856539211500699706378405156269

real    0m0.676s
user    0m0.594s
sys     0m0.063s
Pretty much the same performance as GCC:

Code: Select all

$ g++ -std=c++17 -Wall -Wextra -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp
$ time ./fibo_karatsuba | tail -c 32
4856539211500699706378405156269

real    0m0.601s
user    0m0.484s
sys     0m0.094s
Which is what I expected. It's a bit annoying that clang does not like my constexpr:

Code: Select all

constexpr bintel_t BASE = pow(10, DIGITS);
Thanks for your help Paeryn.

Now to do same on Raspi...
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 2:51 am

Clang 8.0 is still a bit slower?
-O3 and -O2 options, do they make any difference?

Compiling C compilers, yep nearly as much fun as compiling kernels.
Cross compiling even more fun.
C compilers defaulting to debug mode, is that not assuming C always needs debugging :lol:

There is a good reason I don't use Windows at home any more, I like to think I am in control.
With Windows 10 you know you are not in control, it has a mind of it's own :lol:
I feel Windows started becoming sentient around version 8 and not in a nice way.
Pony makes it easy to write fast, safe, efficient, highly concurrent programs.

Just make sure that you use the Pink version on your Pi. :lol:
Of course what other colour would it be?
Mind you, if Pony is using old 3.9.1 LLVM will it be slower?

It is kind of fun that PI's are so borderline useful as PC's we get to worry about compiler speeds now.
It has been decades since I had to worry about that.
Or do I just wait for Pi4 which I'm told will be cool and probably much faster.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jahboater
Posts: 5647
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:28 am

Heater wrote:
Thu Jan 10, 2019 12:53 am
Fourteen hours later, after disk full, out of memory and many beers, we have...clang!
My Pi build is taking ages because I forgot to use "-j4" for the make. Maybe -jN doesn't work.

I must say, the GCC build is simpler, uses standard software tools, is easier to configure, produces a release build by default, and is much quicker (about 4.5 hours on a Pi3B+ and about 20mins on my PC). For Clang I have to install subversion and cmake first.
My script for GCC is:-

Code: Select all

#!/bin/bash

#
#  This is the new GCC version to install.
#
VERSION=8.2.0

#
#  For the Pi or any computer with less than 2GB of memory.
#
if [ -f /etc/dphys-swapfile ]; then
  sudo sed -i 's/^CONF_SWAPSIZE=[0-9]*$/CONF_SWAPSIZE=1024/' /etc/dphys-swapfile
  sudo /etc/init.d/dphys-swapfile restart
fi

if [ -d gcc-$VERSION ]; then
  cd gcc-$VERSION
  rm -rf obj
else
  wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-$VERSION/gcc-$VERSION.tar.xz
  tar xf gcc-$VERSION.tar.xz
  cd gcc-$VERSION
  contrib/download_prerequisites
fi
mkdir -p obj
cd obj

#
#  Now run the ./configure which MUST be checked/edited beforehand.
#  Uncomment the section below depending on your platform.  You may build
#  on a Pi3 for a target Pi Zero by uncommenting the Pi Zero section.
#  To alter the target directory set --prefix=<dir>
#

# Pi3+, Pi3, and new Pi2
../configure --enable-languages=c,c++ --with-cpu=cortex-a53 \
  --with-fpu=neon-fp-armv8 --with-float=hard --build=arm-linux-gnueabihf \
  --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-checking=no

# Pi Zero's
#../configure --enable-languages=c,c++ --with-cpu=arm1176jzf-s \
#  --with-fpu=vfp --with-float=hard --build=arm-linux-gnueabihf \
#  --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-checking=no

# x86_64
#../configure --disable-multilib --enable-languages=c,c++ --enable-checking=no

# Odroid-C2 Aarch64
#../configure --enable-languages=c,c++ --with-cpu=cortex-a53 --enable-checking=no

# Old Pi2
#../configure --enable-languages=c,c++ --with-cpu=cortex-a7 \
#  --with-fpu=neon-vfpv4 --with-float=hard --build=arm-linux-gnueabihf \
#  --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-checking=no

#
#  Now build GCC which will take a long time.  This could range from
#  4.5 hours on a Pi3B+ up to about 50 hours on a Pi Zero.  It can be
#  left to complete overnight (or over the weekend for a Pi Zero :-)
#  The most likely causes of failure are lack of disk space, lack of
#  swap space or memory, or the wrong configure section uncommented.
#  The new compiler is placed in /usr/local/bin, the existing compiler remains
#  in /usr/bin and may be used by giving its version gcc-6 (say).
#
if make -j `nproc`
then
  echo
  read -p "Do you wish to install the new GCC (y/n)? " yn
  case $yn in
   [Yy]* ) sudo make install ;;
	   * ) exit ;;
  esac
fi

#
# An alternative way of adding swap
#
#sudo dd if=/dev/zero of=/swapfile1GB bs=1G count=1
#sudo chmod 0600 /swapfile1GB
#sudo mkswap /swapfile1GB
#sudo swapon /swapfile1GB
Just make sure you have 8-10 GB of free disk space, and it runs without user intervention. When the build is complete, and if it succeeded, it asks if you want to install it. It automatically uses the optimal number of CPU cores.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:31 am

Gavinmc42,
Clang 8.0 is still a bit slower?
-O3 and -O2 options, do they make any difference?
GCC at -O2 seems to have a slight edge here. There is enough variation in results on each run that I'm going to call it a draw.

Here are the Google benchmark results:

Code: Select all

$ g++ -O2 -o bench-gcc bench.cpp fibo.cpp -lbenchmark -lpthread
$ ./bench-gcc
2019-01-10 09:26:14
Running ./bench-gcc
Run on (8 X 3401 MHz CPU s)
Load Average: 0.52, 0.58, 0.59
---------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
---------------------------------------------------------------------
BM_fiboEjOlsonNew/4784969        599 ms          562 ms            1
$ g++ -O3 -o bench-gcc bench.cpp fibo.cpp -lbenchmark -lpthread
$ ./bench-gcc
2019-01-10 09:26:27
Running ./bench-gcc
Run on (8 X 3401 MHz CPU s)
Load Average: 0.52, 0.58, 0.59
---------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
---------------------------------------------------------------------
BM_fiboEjOlsonNew/4784969        648 ms          641 ms            1

$ /usr/local/bin/clang++ -O2 -o bench-clang bench.cpp fibo.cpp -lbenchmark -lpthread
$ ./bench-clang
2019-01-10 09:24:49
Running ./bench-clang
Run on (8 X 3401 MHz CPU s)
Load Average: 0.52, 0.58, 0.59
---------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
---------------------------------------------------------------------
BM_fiboEjOlsonNew/4784969        632 ms          625 ms            1
$
$ /usr/local/bin/clang++ -O3 -o bench-clang bench.cpp fibo.cpp -lbenchmark -lpthread
$ ./bench-clang
2019-01-10 09:25:02
Running ./bench-clang
Run on (8 X 3401 MHz CPU s)
Load Average: 0.52, 0.58, 0.59
---------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
---------------------------------------------------------------------
BM_fiboEjOlsonNew/4784969        636 ms          641 ms            1
Memory in C++ is a leaky abstraction .

Return to “Off topic discussion”