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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:32 am

Heater wrote:
Thu Jan 10, 2019 12:53 am
Pretty much the same performance as GCC:
You used -O2 for GCC and -O3 for Clang.
And the GCC built version was still slightly faster ....

Edit: just saw your last post.
What version of GCC are you using (gcc -v)?
It only fair to use the latest version of both compilers.

I guess your PC is four cores with hyperthreading?
What does nproc say for that?

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:52 am

jahboater,
Maybe -jN doesn't work.
It works.

Initially I made the mistake if running "make -j", That zipped along until it and spawned hundreds of processes, used up all my RAM and died. "make -j 8" worked fine, purring along at about 50% memory usage.

It was building a lot of LLVM stuff for architectures other than x86-64, although not for the clang front end. Also it builds a lot of optional tools one may not need:

Code: Select all

$ llc --version
LLVM (http://llvm.org/):
  LLVM version 8.0.0svn
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: sandybridge

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_be - AArch64 (big endian)
    amdgcn     - AMD GCN GPUs
    arm        - ARM
    arm64      - ARM64 (little endian)
    armeb      - ARM (big endian)
    bpf        - BPF (host endian)
    bpfeb      - BPF (big endian)
    bpfel      - BPF (little endian)
    hexagon    - Hexagon
    lanai      - Lanai
    mips       - MIPS (32-bit big endian)
    mips64     - MIPS (64-bit big endian)
    mips64el   - MIPS (64-bit little endian)
    mipsel     - MIPS (32-bit little endian)
    msp430     - MSP430 [experimental]
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    wasm32     - WebAssembly 32-bit
    wasm64     - WebAssembly 64-bit
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
    xcore      - XCore

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:56 am

jahboater,

I have gcc version 6.3.0 here. nproc says 8, this is a 4 core machine, 2 hyperthreads each.

It would be fair to compare with the latest GCC. But I'm not in the mood for dealing with that.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 8:08 am

Heater wrote:
Thu Jan 10, 2019 7:56 am
jahboater,

I have gcc version 6.3.0 here. nproc says 8, this is a 4 core machine, 2 hyperthreads each.

It would be fair to compare with the latest GCC. But I'm not in the mood for dealing with that.
With 8 threads it should only take ten minutes or so (I would hope) and one command to build GCC, it is trivial by comparison.
20 mins on my four core PC with hyperthreading turned off.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 8:22 am

My Pi3+ Clang build has been running all night and is now swapping madly. Hmm... :(
That's without -j

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 9:11 am

Ages ago I was building Qt5 on some old Pi model. I forget which. Sure it did not have enough RAM and using swap on whatever media I had was impossibly slow. I ended up creating a swap file on the Pi that was actually an NFS mount to a directory on my PC, which was actually RAM based !
Still took all night. But worked well.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 10:09 am

jahboater wrote:
Thu Jan 10, 2019 8:22 am
My Pi3+ Clang build has been running all night and is now swapping madly. Hmm... :(
That's without -j
The build system might see 4 cores and automatically try to build in parallel using all of them without taking into account that there is only 1GB of RAM. Maybe you need to force it to do a serial build. Alternatively, add more complexity to the build system to check for sufficient memory before doing a parallel build and upstream the patches.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 10:21 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!
...
Now to do same on Raspi...
Just make sure you don't drop a clanger :lol:
Signature retired

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 11:27 am

Hey is there a DRAM based USB stick?
Some way to have more fast memory that is not slow flash?
Hmm, a USB3 Super Talent DRAM stick, but we only have USB2 so the speed will be wasted?
Is a USB2 flash stick fast enough for a RAM/Swap drive?

Intel Optane drives?
With USB2 even a spinning drive will be fast enough?
Only the Pi3B+'s have 1GBs Ethernet, network drive?

See this is why I stay away from C and C++ and Linux Kernels and....
Still it is bleeding miracle they compile at all.
I have heard of 8 day compiles on Pi's.

I assume -j2 is 2 parallel processes, -j4 is 4 processes and -j tries as many as it can for Make?
So a Pi3B+ could do 4 processes in parallel, one for each core?

Going to have to learn all my various compilers multi-core options, more RTFM.

Sakaki mentioned something about a change to Firefox compiling
https://glandium.org/blog/?p=3888

Reminds me of the early compiler wars, Watcom ruled.
Now I wonder about compiling on a NVIDIA GPU card.
Hey how does CUDA work?

Don't Arm have their own C Compiler too?
The compiler is based on LLVM and Clang technology. LLVM is a set of open-source components that allow the implementation of optimizing compiler frameworks. Clang is a compiler front end for LLVM, providing support for the C and C++ programming languages.
I know Arm's Compute Library makes use of NEON and Mali's OpenCL, is their C compiler using them as well?
LLVM and OpenCL connects to SPIR-V and then to Vulkan.

It looks like LLVM (CPU) and SPIR-V (GPU) is becoming the glues that connects everything?
Now there is an LLVM backend that targets the new SPIR-V intermediate representation, so any language compiler that targets LLVM should be capable of being used to target OpenCL.
Interesting, Go and Rust have SPIR-V asm/disassemblers

Nice quote
If our experiments ever turn into an actual product, I would have to recommend we write the GPU code in C.
To spare myself and others that dreadful fate, I decided to work towards making Rust’s GPGPU story as good as C’s.
https://bheisler.github.io/post/state-of-gpgpu-in-rust/
I have spent a big part of my life debugging C, I don't want to spend the rest still doing it.

If C compiling is so slow on Pi's but Pi's are cheap can we do distributed Compiling?
https://en.wikipedia.org/wiki/Distcc
Wow it can be done. Make myself a cluster out of all my old Pi's.
Actually Zero's run at 1GHz so are faster than old B's ;)

No mention of Basic in any of the above?
Good enough reason to avoid Basic?
And now that I think about it yet again, C/C++ as well.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 12:42 pm

jahboater,

Silly me. I listen to you...

Over two hours after the first wget, a couple of failed downloads and corrupt tar files, after much compiling, the GCC build failed:

Code: Select all

In file included from /mnt/j/gcc-8.2.0/libstdc++-v3/libsupc++/new:40,
                 from ../../gcc/system.h:236,
                 from ../../gcc/lto/lto.c:22:
/mnt/j/gcc-8.2.0/libstdc++-v3/libsupc++/exception:144:10: fatal error: bits/nested_exception.h: No such file or directory
 #include <bits/nested_exception.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 1:01 pm

Heater wrote:
Thu Jan 10, 2019 12:42 pm
jahboater,

Silly me. I listen to you...

Over two hours after the first wget, a couple of failed downloads and corrupt tar files, after much compiling, the GCC build failed:

Code: Select all

In file included from /mnt/j/gcc-8.2.0/libstdc++-v3/libsupc++/new:40,
                 from ../../gcc/system.h:236,
                 from ../../gcc/lto/lto.c:22:
/mnt/j/gcc-8.2.0/libstdc++-v3/libsupc++/exception:144:10: fatal error: bits/nested_exception.h: No such file or directory
 #include <bits/nested_exception.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Sorry to hear that. I would be very interested if you think there is a bug in the script.
I run it on x64 Linux PC, Pi3 (Raspbian), Odroid C2 (64-bit Ubuntu), Pi Zero. Never a problem. And others on the forum have run it without any reported issues.
The only thing I know of is that it doesn't check the available disk space before starting.
I think it needs about 8GB, but allow 10 or 12GB to be on the safe side. If it runs out of space, the message is unhelpful.
On the PC I run the script in /tmp which is a tmpfs mount.

1) Failed downloads are a problem with your internet connection or your PC ???, I cannot help there.

2) Corrupt tar files I have never seen before, and I have done this countless times. May be your connection again.

3) Sorry, my bad, I forgot to say that I distribute the script with the config set for the Pi3 (it is a Raspberry Pi forum after all).
Its a trivial edit for an x64 PC (uncomment the x64 line and comment out the Pi3 lines), the comments in the script should be self explanatory, if not I would appreciate any comments you have, given your first class command of english!
But here is the same script pre-configured for an x64 Linux build.

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
Edit: I just ran the script on my PC and it works fine.
The download is not corrupt.
Are you sure some bits are not getting lost in the forest? :)
The tar file is 61MB but the script also later downloads the source of GMP and MPFR.
Last edited by jahboater on Thu Jan 10, 2019 1:40 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 1:40 pm

jahboater,
1) Failed downloads is a problem with your internet connection or your PC ???, I cannot help there.

2) Corrupt tar files I have never seen before, and I have done this countless times. May be your connection again.
It's odd. My internet connection flies along at over 65Mbps. I have downloaded, built and installed hundreds of things before with rarely any complaint from wget, I don't recall ever seeing corrupt downloaded files. I think they were just cut short for some reason.
3) Sorry, my bad, I forgot to say that I distribute the script with the config set for the Pi3
No worries, I spotted that and adjusted it accordingly.

Anyway, on a whim I simply ran "make -j `nproc`" again. Strangely enough this time it ran to completion with no error.

I don't see any difference in executable speed for fib() though:

Code: Select all

$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --enable-languages=c,c++ --enable-checking=no
Thread model: posix
gcc version 8.2.0 (GCC)
$
$ /usr/local/bin/g++ -O2 -o bench-gcc bench.cpp fibo.cpp -lbenchmark -lpthread
$ ./bench-gcc
2019-01-10 15:21:52
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        583 ms          594 ms            1
On the downside my old g++ command does not work anymore:

Code: Select all

$ g++ -O2 -o bench-gcc bench.cpp fibo.cpp -lbenchmark -lpthread
g++: error trying to exec 'cc1plus': execvp: No such file or directory
g++: error trying to exec 'cc1plus': execvp: No such file or directory
I notice things were getting installed to /usr/bin as well as /usr/local/bin, which I was not expecting. That may be an omission in the script.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 1:46 pm

Glad you got it working!

The old compiler should be accessible with gcc-6 and g++-6
(for version 6.3 on the Pi).
"gcc-6 -O3 fibo.c -o fibo" and "gcc -O3 fibo.c -o fibo" both work for me.
Looks like your $PATH is different from mine:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

The install directory is set with the usual "--prefix" configure option.
I have never tried setting it as the default seemed to work.

By the way, don't try running the script on a Pi Zero - it works fine but takes about 50 hours!
Instead set the config for the Pi0, do the build on a 3B+, tar up and copy the finished build tree to the Pi Zero and then do the install.

You now have full support for C++17 among other things .....

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 2:04 pm

jahboater,

Ah yes, g++-6 works, thanks.

I'll fix up my "g++" later if I ever need it.

I was looking for the "--prefix", after I got it to build, that is usually the one and only thing I set when building stuff.

No zeros around here I'm afraid.

It's hard work...all this avoiding BASIC business :)

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 2:12 pm

Heater wrote:
Thu Jan 10, 2019 2:04 pm
It's hard work...all this avoiding BASIC business :)
:)

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 2:19 pm

jahboater,
You now have full support for C++17 among other things .....
Yeah... I'm not really up to date with the C++17 standard. Despite having watched a bunch of recent cppcon presentations on YouTube. I thought I was being advanced rvalue refs and move semantics, but that goes back to C++11.

Any ideas if there are any C++17 features I could take advantage of in my bint class?

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 2:30 pm

jahboater,

I found this c++17 "check list":

https://www.codingame.com/playgrounds/2 ... d-bindings

1) STRUCTURED BINDINGS - Na, no tuples and such around here.

2) INIT STATEMENT FOR IF/SWITCH - Not sure I even like that one.

3) INLINE VARIABLES - No sure where I could use that.

4) CONSTEXPR IF - Cool, sounds like a neat way to get rid of #ifdef..

Code: Select all

if constexpr(cond)
     statement1; // Discarded if cond is false
else
     statement2; // Discarded if cond is true
5) FOLD EXPRESSIONS - Nope.

6) TEMPLATE ARGUMENT DEDUCTION FOR CLASS TEMPLATES - Yuk, templates.

7) DECLARING NON-TYPE TEMPLATE PARAMETERS WITH AUTO - Yuk, templates.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 2:36 pm

Heater wrote:
Thu Jan 10, 2019 2:30 pm
2) INIT STATEMENT FOR IF/SWITCH - Not sure I even like that one.
We had for years "for( int i = xxx; ........"
now we have "if( int i = xxxx; ..." and "switch( int i = xxx; ..." .
Seems kind of symmetrical.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 2:53 pm

It does seem to be more symmetrical.

But I thought raw for loops like that were discouraged now a days and we were supposed to move towards range based iteration or whatever, sounds like a step backwards.

I guess it helps with things like:

Code: Select all

if (status = doSomething() == OK) {
    ...
} 
Which I always thought looked a bit suspect. Now we can have:

Code: Select all

if (auto status = doSomething(); status == OK)    
    // on success  
else   
    // on false... 
What I'd like is some way to express that thing I do where smaller big integers are stored in the bint structure on the stack but bigger ones get stored in allocated memory on the heap. What I have now seems a bit clunky. There must be a better way to do that.

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:01 pm

Heater wrote:
Thu Jan 10, 2019 2:04 pm
It's hard work...all this avoiding BASIC business :)
Back to BBC BASIC then. Following up on various bits discussed here I now calculate the fibonacci in about 2:15 minutes with RISC OS on an iMX processor at 1.2GHz. It is of the order of twice that on a Raspberry PI Zero, and the time to print a head and tail is as much again. This is using the Numbers module, so the program is doing little more than acting as a dispatcher to the machine code routines therein. It has been quite satisfying coding the algorithms economically and it leaves me in a position to substitute some pure BASIC calculations. ;-)

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:11 pm

Steve Drain wrote:
Thu Jan 10, 2019 7:01 pm

Back to BBC BASIC then. Following up on various bits discussed here I now calculate the fibonacci in about 2:15 minutes with RISC OS on an iMX processor at 1.2GHz.
I thought BBC Basic was interpreted. If so that is very fast indeed! Impressive.
The compiled C version time is 1m39 sec on the Pi Zero including the printout.

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:16 pm

jahboater wrote:
Thu Jan 10, 2019 7:11 pm
I thought BBC Basic was interpreted. If so that is very fast indeed!
I refer back to my earlier explanation of RISC OS modules as operating system extensions. The Numbers module has the calculation code and does all the hard lifting. My program is in BASIC, but not as you might imagine.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:31 pm

Steve Drain,

That is interesting. I never knew RISC OS had such a big numbers module built in before you mentioned it. Care to present the code here?

I'm puzzling how this fits with the agreed aims of the fibo(4784969) challenge.

On the one hand one could say it does not qualify as using such an OS module is not any kind of standard BASIC.

On the other hand, if that OS module comes as standard with the OS and that is "RISC OS BASIC", or whatever it is called, then it qualifies.

On the third hand we could say that you have written you solution in "RISC OS"!

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:36 pm

Gavinmc42 wrote:
Thu Jan 10, 2019 11:27 am
Reminds me of the early compiler wars, Watcom ruled.
Now I wonder about compiling on a NVIDIA GPU card.
Hey how does CUDA work?
According to
Wikipedia wrote:Waterloo BASIC programming language was one of the earliest Watcom products and predates the existence of the company. During 1978 to 1979 Waterloo BASIC was developed targeting the IBM Series/1. In 1979 the system was ported to VM/CMS running on the IBM 370, 3030, and 4300 computers...
I had the opportunity to avoid Waterloo BASIC but ended up using it under VM/CMS. I can't remember what the code did, but only that it was very slow in comparison to FortranG and VSPascal on the same system. I also remember being astonished at the uses of a virtual punch card reader.

A couple years ago a student I was working with developed a fast O(N(logN)^2) gridless tree-based algorithm for matching points in point-cloud data. After what we thought was fairly careful tuning, it didn't take many Intel CPUs to outperform current P100 and V100 GPUs when constructing the trees using the recursive boxing part of the algorithm. However, after the tree had been built, the matching phase went much faster on the GPU. One of the take away messages was that algorithms involving sorting and constructing trees seem difficult to efficiently parallelize on a GPU.

As compilers spend a noticeable amount of time sorting and constructing trees, a GPU seems like a difficult fit, especially as compilers typically don't use any parallel floating point arithmetic while they are running.
Last edited by ejolson on Thu Jan 10, 2019 7:48 pm, edited 2 times in total.

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

Re: Why Avoid BASIC on RPi?

Thu Jan 10, 2019 7:47 pm

Heater wrote:
Thu Jan 10, 2019 7:31 pm
Steve Drain,

That is interesting. I never knew RISC OS had such a big numbers module built in before you mentioned it. Care to present the code here?

I'm puzzling how this fits with the agreed aims of the fibo(4784969) challenge.

On the one hand one could say it does not qualify as using such an OS module is not any kind of standard BASIC.

On the other hand, if that OS module comes as standard with the OS and that is "RISC OS BASIC", or whatever it is called, then it qualifies.

On the third hand we could say that you have written you solution in "RISC OS"!
Without seeing the code, I suspect it reasonably reflects the RISCOS BASIC programming environment as typically used. In comparison to how the current Linux programming environment is used, this would be similar to writing your own implementation of the doubling formulas to compute Fibonacci numbers with GMP doing the big-number arithmetic either behind the scenes or explicitly. I'm looking forward to seeing details of the code.

Return to “Off topic discussion”