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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 10:20 am

jahboater,
I presume you are using a 64-bit release of Linux Mint?
No. I don't even know what Linux Mint is. Never seen one.

All my experiments here have been done either on my Win 10 PC under the Linux Subsystem for Windows which happens to be running Debian or on my Pi 3 that is running pi64 by Bamarni: https://github.com/bamarni/pi64

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 10:40 am

Steve Drain,
If I presented code in this modified BASIC language, as with Haskell, would it be a solution to the challenge?
I don't see anything "as with Haskell" about this idea. One does not need to modify the Haskell language to solve the problem as stated, Haskell has big integer support built in, bog standard Haskell will do.

That is a good question mind. If one has a programming language that is expressive enough to enable it's own syntax and semantics to be changed on the fly, if using that you can morph it into a very clear and concise implementation of an algorithm I guess it is a contender.
Another line is that the bignum routines that have been shown here for C and C++ are essentially composed of multiple loops. This is ripe fodder for assembly,
My claim is that this is not true. One could read the C or C++ source code and create from it your ones implementation in assembler, my claim is two fold:

a) The resulting assembler program will not be very expressive of the algorithms used. It would be hard work to read it and see what the idea is.

b) The resulting assembler program will be slower than what we get from the C/C++ compilers.

Until such time as someone steps up to the plate and writes a fibo(4784969) solution in assembler we will not know for sure. There was one volunteer but he backed out.
I am with DavidS on this, that writing these loop routines in assembler is not far short in expressivenes to the complex C++ class routines.
You have your work cut out then. We look forward to seeing your assembler solution so that we can can compare...

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 10:53 am

All my experiments here have been done either on my Win 10 PC under the Linux Subsystem for Windows which happens to be running Debian
Blimey, lucky they work at all.

Linux Mint is the OS for those that hate the MS enforced look that started with Windows8 and that Ubuntu copied.
It is for those who like to pretend they control their PC, Mint is the cool OS.
You don't have to fight it to get stuff done and it is not in your face with what it thinks you need.
I would be a fanboy of Mint except it is too plain to get very excited about :D
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 11:15 am

Heater wrote:
Fri Jan 11, 2019 12:28 am
A speed up of almost exactly 2. Not so impressive for an 4 core, 8 hyper thread, machine. But compares favorably with the parallel C version:
The serial code started with was 48 percent faster, but the resulting parallel code is 20 percent slower. I appreciate your optimism, but in what way is this favourable?

What happens if you include the parallel.h header, use the spawn and sync macros from there and compile with -fopenmp instead?
Last edited by ejolson on Fri Jan 11, 2019 11:29 am, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 11:23 am

Gavinmc42 wrote:
Fri Jan 11, 2019 10:53 am
All my experiments here have been done either on my Win 10 PC under the Linux Subsystem for Windows which happens to be running Debian
Blimey, lucky they work at all.

Linux Mint is the OS for those that hate the MS enforced look that started with Windows8 and that Ubuntu copied.
It is for those who like to pretend they control their PC, Mint is the cool OS.
You don't have to fight it to get stuff done and it is not in your face with what it thinks you need.
I would be a fanboy of Mint except it is too plain to get very excited about :D
From what I can tell Mint is essentially Debian with green theming, newer packages and slower security responses.

I've got the Mint Mate flavor installed on the Ryzen desktop in my office and we're using it on the server the graduates students access over remote desktop. The server works great; however, the desktop has occasional problems apparently with the graphics driver (even with a 4.19.x kernel) that are probably not Mint related.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 11:54 am

Gavinmc42,
Blimey, lucky they work at all.
The Linux Subsystem for Windows is the best feature Microsoft ever added to any operating system, ever. It has proved to be very robust and is the only reason I'm still using this Win 10 machine.

The LSW does have some annoying limitations though. For example it's not possible to get core dumps and gprof does not work. Presumably because there is no actual Linux kernel under there to support that. Now, if only MS would replace their Windows kernel with Linux they could fix that :)
Linux Mint is the OS for those that hate the MS enforced look that started with Windows8 and that Ubuntu copied.
It is for those who like to pretend they control their PC...
You are preaching to the converted there brother.

I deleted Win 95 from my PC in 1998 and this was a Linux only household from then on. Not even dual boot. It all started with a boxed set of RedHat CDs and soon settled on Debian. Along the way were some trials of Gentoo and such. To this day I don't understand why we have Ubuntu, which has always been troublesome in every place I have seen using it.

It's only a couple of years ago that my boss at the time twisted my arm, bought me an MS Surface Pro 4, and got me using Win 10 for some in house applications. At the same time my trusty Linux PC died. Then this Win 10 PC came my way. To my shame I have been too lazy to resurrect a Linux PC here so far. Although I have a couple of industrial boxes running Debian here but their performance is not hot.
Mint is the cool OS
Nah, Debian with KDE is the cool OS :)

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 12:09 pm

Heater wrote:
Fri Jan 11, 2019 11:54 am
The Linux Subsystem for Windows is the best feature Microsoft ever added to any operating system, ever. It has proved to be very robust and is the only reason I'm still using this Win 10 machine.
I have heard similar things said many times.

Is it not sad that the best feature of an OS is the fact that it can run a competing OS ??

Mint, in its early days, rose to popularity because it came with all the useful codecs pre-installed and working.

I have used Mint for years without any problems. Occasionally I change the desktop to provide some variety!

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 12:30 pm

Yep Mint's preinstalled stuff that just works :D
Apart from the kid's game box the others are Mint.
Probably should upgrade from 18.3 to the new 19.1, just because it looks even nicer.
But I might wait until the Linux Kernel 5.? version

Finally got my Gentoo64 Pi setup for C coding and found some time.

zicog github code
gcc 8.2.0-rc4 - fibonacci.c results

real 0m40.209s
user 0m40.164s
sys 0m0.028s

clang 7.0.0 pops up and error for sqrt and log10?
The c++ code does not compile :(

How did this get off track onto compiling on PC's?
No PC's are the same.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 1:55 pm

Heater wrote:
Fri Jan 11, 2019 10:40 am
Steve Drain,
If I presented code in this modified BASIC language, as with Haskell, would it be a solution to the challenge?
I don't see anything "as with Haskell" about this idea. One does not need to modify the Haskell language to solve the problem as stated, Haskell has big integer support built in, bog standard Haskell will do.
For me having an official committee-approved standard is not as important as a high-quality well-supported widely-available set of software tools which implement the language. Without such tools no standards document is of any use except as an example of what went wrong. On the other hand, popular programming tools set defacto standards all the time.

The difficulty with RISC OS these days is a small user base and very little help from industry to support new hardware. One reason for this is the dominance of Linux. Since so much corporate money already goes to Linux, there is little interest in other operating systems. It also helps that Linux development has been properly managed and performance focused from the start.

In the same way that Linux has dominated operating systems over the years, so has the GNU compiler collection dominated programming languages. Nobody runs gcc or g++ in any of modes that strictly enforce the C and C++ standards, instead they use GNU enhanced versions of those standards. Use of those GNU extensions have subsequently become so common that clang and the Intel C compiler both support most all of them. I'm not sure about the Microsoft Visual Studio, but it's possible that it supports clang and gcc as compiler options.

Although gcc attracts a significant amount of support from industry, there is still plenty of support for LLVM and new languages such as Kotlin, Swift, Go and Rust. However, except for Microsoft, those corporate dollars avoid BASIC. Unfortunately, Microsoft has just announced Visual BASIC will no longer maintain feature parity with C# on the .net platform.

Although the title of the thread is why avoid BASIC on the Raspberry Pi, the original intent was to demonstrate that BASIC is a good language rather than come up with a list of faults. If indeed, as others have claimed, it is possible to evaluate the expressiveness of a language independent of the quality of the compiler, the fact that FreeBASIC has all the features of C except complex numbers and many additional built-in features as well would then imply that FreeBASIC is at least as expressive as C.

My point of view is that expressivity depends very much on the compiler and how efficiently it maps onto the hardware features of the processor. For example, if the optimiser is poor or broken, the compiler is much less expressive. Without such considerations, every implementation of a Turing-complete programming language would appear equally useful.

If performance of the programming language doesn't matter, then you are likely solving a problem which is trivial for today's computers. While there is nothing wrong with that, greater benefits may result from taking better advantage of the technology available. From this point of view, I have suggested any programming language which can not express complicated algorithms in a way that results in at least 50 percent the performance of the best engineering effort is not efficient enough to liberate the person who learns that language from the servitude of using only built-in features and standard subroutine libraries.

Implicit from your approach is the understanding that different programming languages are better suited for different things. Indeed, if learning BBC BASIC on its own is not digitally liberating, then maybe learning BBC BASIC along with ARM assembly language would be. The usefulness of this approach is evident by the large number of software projects that visibly combine different languages to create one program. At the same time, learning multiple languages can be intimidating for the beginner and generally makes the software harder to build and maintain.

In my opinion, BBC BASIC with inline assembler, while not just BASIC, is a common enough combination to be considered. In general I think it reasonable and interesting to consider the expressiveness of various language combinations such as Python with C, Pascal with assembler, and Scratch with Python. While this doesn't answer the question why avoid BASIC, any combination that does not achieve 50 percent the performance of the best engineering effort might also be a good idea to avoid.
Last edited by ejolson on Fri Jan 11, 2019 4:34 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 2:09 pm

Gavinmc42,
clang 7.0.0 pops up and error for sqrt and log10?
Sounds like you need the "-lm" option to link the maths library. Put it at the end of the compile command.

It would help if you would post the actual compile command and the resulting error message.
The c++ code does not compile
I noticed that my clang does not like the statement:

Code: Select all

constexpr bintel_t BASE = pow(10, DIGITS);
I think this is down to the fact that "constexpr" is a recent addition to the C++ standard and actual compiler support has not caught up yet.

I have checked in a version that does not use that. That should build fine.
How did this get off track onto compiling on PC's?
No PC's are the same.
True. It helps a lot to use standardized languages that are well supported on many platforms though.

User avatar
bensimmo
Posts: 3581
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 2:37 pm

Off track...

The same way you are running C++ and C code etc in a BASIC topic.
But then it is "avoiding BASIC", so perfectly on topic ;-)

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 3:25 pm

ejolson,

I agree, standards that exist in isolation are no use. Standards need ongoing support of the community of users, vendors, etc. Standards should emerge from the best practices of those users. Standards are an agreement among those users on how to inter-operate. Examples of useless, "dead", standards that nobody cares about are ANSI BASIC, ISO 7185 standard for Pascal, CORBA. Examples of live, vibrant standards, are C, C++, Javascript and there are others all be it without "officialness" of ISO or ANSI.
In C++, for example, the standard ends up documenting language and library features that are first implemented by GCC or Boost and such and then proven in the field for a long while.

I agree, high-quality well-supported widely-available set of software tools which implement the language are vital. Whatever humble code I write needs to be usable on as many platforms as possible, from Windows, Mac and Linux PC's to various embedded devices. Even things that don't exist, like the forthcomming RISC V. This is mostly for my personal benefit, often important to my employer(s) some times even useful to strangers out there I don't even know.

RISC OS is not on the radar. It has no users, no useful software support and no compelling features over many more common systems.

The title of the thread is why avoid BASIC on the Raspberry Pi. I think that question has been answered satisfactorily in many ways by many people here now.
Without such considerations, every implementation of a touring-complete programming language would appear equally useful.
I think not. (Did you mean Turing complete?). Many languages are Turing complete, that does not make them convenient for humans to write programs in. See, Brainfuck, Postscript, Forth for examples.

All in all I'm with you, at the end of the day performance matters.
Indeed, if learning BBC BASIC on its own is not digitally liberating, then maybe learning BBC BASIC along with ARM assembly language would be.
Strangely enough, back in tech school in 1973 we were introduced to programming with BASIC. We also then had to learn assembler. It was after a year of this that I realized BASIC was kind of pointless. I was liberated :)

FreeBASIC and other BASIC strains may well have the control and data structures of languages inspired by ALGOL and hence be as expressive as for example C. I don't care. They are no longer BASIC. They have no reason to exist, after all we already have Pascal and C and such.

Why was BASIC created? As far as I can tell for two main reasons:

1) To provide a system whereby many students could get access to a big expensive computer at the same time. Very important in an educational setting.

2) To provide a language that was simple enough that any high school kid with a bit of algebra under his belt would very quickly understand it and make use of it, even if they were not studying CompSci.

As such I think we can all agree it achieved it's goals very well.

Why did BASIC become so big in the late 1970's/ early 1980's? As far as I can tell for two main reasons:

1) It provided a system where by owners of the new fangled "home computers" could actually get their machines to do something.

2) It provided a language that was simple enough that any high school kid with a bit of algebra under his belt would very quickly understand it and make use of it, even if they were not studying CompSci.

Hmm... 1) and 2) here seem very similar to 1) and 2) above.

What about BASIC today?

Well, reason 1) for it's existence has gone away. Computers are very cheap and everywhere. They come with all kind of languages. Getting access to a computer is not a problem.

Reason 2) has gone away. There are many languages now that serve as good introductions to programming, provide that instant feed back a student needs, and are generally far better than BASIC.

Given your criteria of "50% of the performance of best industry practice" I would be interested to see which of the languages we have seen here are acceptable to you and which are not. And perhaps how you rate some languages we have not seen here.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 4:50 pm

ejolson,
What happens if you include the parallel.h header, use the spawn and sync macros from there and compile with -fopenmp instead?
I did not use your parallel.h but rather used OMP directly in my karatsuba multiply, replacing my use of the C++ std::async to create threads.

The code looks like this (please advise if that is not the best use of OMP):

Code: Select all

        if ((low1.width > (1<<11)) && (low2.width > (1<<11))) { 
            omp_set_num_threads(4);
            #pragma omp parallel
            {
                #pragma omp single
                {
                    #pragma omp task default(shared)
                    z0 = low1 * low2;

                    #pragma omp task default(shared)
                    z1 = (low1 + high1) * (low2 + high2);

                    #pragma omp task default(shared)
                    z2 = high1 * high2;
                }
                #pragma omp taskwait
            }
The results when run under Google benchmark are below. In these runs we see std::async gives us a speed up of about 3.

Using openmp is a speed up of about 2.5. I limited the number of OMP threads to 4 as I have four cores. Setting it 8 to use the 8 hyper threads made it slower.

When it comes to running the actual fibo program one of the best times I have seen is using C++ std::async:

Code: Select all

$ /usr/local/bin/clang++ -Wall -Wextra -DUSE_ASYNC  -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lpthread
$ time ./fibo_karatsuba | tail  -c 32
4856539211500699706378405156269

real    0m0.275s
user    0m1.219s
sys     0m0.250s
Which is pretty much the same a parallel.c at 0m0.258s

Nothing is cut and dried here as the timings vary quite a bit from run to run. But certainly neither of us are getting a four times speed up over the fastest C/C++ solution so far.

Serial on x86 PC.

Code: Select all

$ ./bench
2019-01-11 18:22:28
Running ./bench
Run on (8 X 3401 MHz CPU s)
Load Average: 0.52, 0.58, 0.59
---------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
---------------------------------------------------------------------
BM_fiboEjOlsonNew/4784969        622 ms          625 ms            1
Using C++ std::async on x86 PC:

Code: Select all

$ ./bench
2019-01-11 18:20:39
Running ./bench
Run on (8 X 3401 MHz CPU s)
Load Average: 0.52, 0.58, 0.59
---------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
---------------------------------------------------------------------
BM_fiboEjOlsonNew/4784969        196 ms         76.4 ms            9
Using OMP on x86 PC (nproc = 4):

Code: Select all

$ ./bench
2019-01-11 18:19:21
Running ./bench
Run on (8 X 3401 MHz CPU s)
Load Average: 0.52, 0.58, 0.59
---------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
---------------------------------------------------------------------
BM_fiboEjOlsonNew/4784969        250 ms          250 ms            3

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 5:45 pm

Heater wrote:
Fri Jan 11, 2019 3:25 pm
Well, reason 1) for it's existence has gone away. Computers are very cheap and everywhere. They come with all kind of languages. Getting access to a computer is not a problem.

Reason 2) has gone away. There are many languages now that serve as good introductions to programming, provide that instant feed back a student needs, and are generally far better than BASIC.
I don't see much wrong with the names BBC BASIC, FreeBASIC, Quick Basic or Visual BASIC. The differences between these versions of BASIC are not much different than the differences between versions of Fortran, Pascal, C or C++ over the years. The currently fashionable teaching languages Python and Scratch have been around for a much shorter period of time and already have incompatible versions. Is node.js the same language as the original JavaScript? If I decided that the first version of a language was the only version, this would appear a reason to avoid most of them and a bit like attacking a straw man.

Thanks to their former CEO Microsoft is easy to ridicule, but they also employed a lot of talented people to work on BASIC. The result is not the same language as implemented by the interpreter written by the unfortunate Mrs Verda Spell of Beaumont Texas. However, unlike Borland who threw Pascal out with the bath water and goofily called it Delphi, Microsoft retained the name recognition and called it Visual BASIC. In either case, focusing on programmer productivity while retaining the traditional priority of easy-to-learn is not something to be avoided.

We use C++ for our two-semester introduction-to-programming courses here. Since we're avoiding BASIC, what would you recommend as a good introductory programming language?

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 5:58 pm

ejolson wrote:
Fri Jan 11, 2019 5:45 pm
We use C++ for our two-semester introduction-to-programming courses here. Since we're avoiding BASIC, what would you recommend as a good introductory programming language?
Perhaps take a look at D.
Like C++ it is a large and powerful language so that many programming paradigm's and language features can be introduced later.
But it has a cleaner syntax than C++ that isn't totally reliant on colons and angle brackets.

Its been around for a few years now.
GCC version 9 will support it (soon to be released), LLVM does now, and the Digital Mars compiler is very good (dmd).

Just because a language is large, doesn't mean it isn't suitable for an introductory course, beginners need only use a subset.
Last edited by jahboater on Fri Jan 11, 2019 6:05 pm, edited 3 times in total.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 5:59 pm

Heater wrote:
Fri Jan 11, 2019 4:50 pm
The code looks like this (please advise if that is not the best use of OMP):
It doesn't look right to me. I think it will work better if you move this bit

Code: Select all

            omp_set_num_threads(4);
            #pragma omp parallel
            {
                #pragma omp single
                {
place it in the main routine similar to where in parallel.c this code is placed and change the 4 back to 8. In particular, you don't want to create a new pool of worker threads at each step in the recursion because (as observed) that would be nearly as inefficient as the C++ stuff.
Last edited by ejolson on Fri Jan 11, 2019 6:15 pm, edited 4 times in total.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 6:01 pm

ejolson,
We use C++ for our two-semester introduction-to-programming courses here. Since we're avoiding BASIC, what would you recommend as a good introductory programming language?
Scheme.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 6:14 pm

Heater wrote:
Fri Jan 11, 2019 6:01 pm
ejolson,
We use C++ for our two-semester introduction-to-programming courses here. Since we're avoiding BASIC, what would you recommend as a good introductory programming language?
Scheme.
Unfortunately we're not MIT. Also, I should have phrased my question differently: If the first language will also be the only programming language ever learned, which one should be taught?

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 6:52 pm

ejolson,

OK. Now I have the following in main():

Code: Select all

    #pragma omp parallel
    {
        #pragma omp single
        {
            fiboNew(n, res);
        }
    }
And it gets used like so:

Code: Select all

        if ((low1.width > (1<<11)) && (low2.width > (1<<11))) { 
            #pragma omp task default(shared)
            z0 = low1 * low2;

            #pragma omp task default(shared)
            z1 = (low1 + high1) * (low2 + high2);

            #pragma omp task default(shared)
            z2 = high1 * high2;

            #pragma omp taskwait
Here are the results:

Code: Select all

$ /usr/bin/g++ -Wall -Wextra -DUSE_OMP -fopenmp -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lpthrea
$ time ./fibo_karatsuba | tail  -c 32
4856539211500699706378405156269

real    0m0.243s
user    0m0.969s
sys     0m0.094s

$ /usr/bin/g++ -Wall -Wextra  -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lpthread
$ time ./fibo_karatsuba | tail  -c 32
4856539211500699706378405156269

real    0m0.616s
user    0m0.516s
sys     0m0.109s
A speed up of 2.5 when using OMP. Not much of a change really.

Hey, but it beat my last run of parallel.c! :

Code: Select all

$ /usr/bin/g++ -Wall -Wextra -fpermissive -O3 -fopenmp -o parallel parallel.c
$ time ./parallel | tail -c 32
4856539211500699706378405156269

real    0m0.247s
user    0m1.391s
sys     0m0.031s
Some comments/thoughts about this:

I tried setting the number of threads to 4 and 8, it made little difference. I let OMP decide for itself, not much change.

I'm not really happy about pushing the OMP stuff up to main(), or even as far up as the fibo(). This multiplication speed up is an implementation detail that should not show up at those higher levels.

The parallel.c code fails to build without -fpermissive.

Code: Select all

$ /usr/bin/g++ -Wall -Wextra  -O3 -fopenmp -o parallel parallel.c
parallel.c: In function ‘int main(int, char**)’:
parallel.c:343:37: error: taking address of temporary [-fpermissive]
         {RLIM_INFINITY,RLIM_INFINITY});
The speed gains by going parallel here are pretty poor. A speed up of 2 or 2.5 when going from 1 to 4 cores is terrible scaling. Going to 8 hyper threads is even more pathetic.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 6:57 pm

ejolson,
Unfortunately we're not MIT. Also, I should have phrased my question differently: If the first language will also be the only programming language ever learned, which one should be taught?
Javascript.

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

Re: Why Avoid BASIC on RPi?

Fri Jan 11, 2019 11:45 pm

Heater wrote:
Fri Jan 11, 2019 6:52 pm
ejolson,

OK. Now I have the following in main():

Code: Select all

    #pragma omp parallel
    {
        #pragma omp single
        {
            fiboNew(n, res);
        }
    }
And it gets used like so:

Code: Select all

        if ((low1.width > (1<<11)) && (low2.width > (1<<11))) { 
            #pragma omp task default(shared)
            z0 = low1 * low2;

            #pragma omp task default(shared)
            z1 = (low1 + high1) * (low2 + high2);

            #pragma omp task default(shared)
            z2 = high1 * high2;

            #pragma omp taskwait
Here are the results:

Code: Select all

$ /usr/bin/g++ -Wall -Wextra -DUSE_OMP -fopenmp -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lpthrea
$ time ./fibo_karatsuba | tail  -c 32
4856539211500699706378405156269

real    0m0.243s
user    0m0.969s
sys     0m0.094s

$ /usr/bin/g++ -Wall -Wextra  -O2 -o fibo_karatsuba fibo_karatsuba.cpp fibo.cpp -lpthread
$ time ./fibo_karatsuba | tail  -c 32
4856539211500699706378405156269

real    0m0.616s
user    0m0.516s
sys     0m0.109s
A speed up of 2.5 when using OMP. Not much of a change really.

Hey, but it beat my last run of parallel.c! :

Code: Select all

$ /usr/bin/g++ -Wall -Wextra -fpermissive -O3 -fopenmp -o parallel parallel.c
$ time ./parallel | tail -c 32
4856539211500699706378405156269

real    0m0.247s
user    0m1.391s
sys     0m0.031s
Some comments/thoughts about this:

I tried setting the number of threads to 4 and 8, it made little difference. I let OMP decide for itself, not much change.

I'm not really happy about pushing the OMP stuff up to main(), or even as far up as the fibo(). This multiplication speed up is an implementation detail that should not show up at those higher levels.

The parallel.c code fails to build without -fpermissive.

Code: Select all

$ /usr/bin/g++ -Wall -Wextra  -O3 -fopenmp -o parallel parallel.c
parallel.c: In function ‘int main(int, char**)’:
parallel.c:343:37: error: taking address of temporary [-fpermissive]
         {RLIM_INFINITY,RLIM_INFINITY});
The speed gains by going parallel here are pretty poor. A speed up of 2 or 2.5 when going from 1 to 4 cores is terrible scaling. Going to 8 hyper threads is even more pathetic.
It takes a clever scheduler to avoid placing two parallel tasks on the same core when hardware multithreading is enabled. Have you tried turning off Intel hyper-threading to see if you get better parallel scaling?

That's interesting that moving the OpenMP worker-pool initialization directives outside the recursive multiply didn't help. I guess I was remembering how the corresponding macros worked for Cilk. Still, in order for a collection of parallel subroutines to work together, it's often better if they all rely on the same pool of worker threads.

It appears you have significant lock contention in one of the system calls behind the scenes--perhaps something to do with objects or heap-based memory allocation. Alternatively, Windows subsystem for Linux may have too many emulations of threading or too many layers of meltdown mitigations to be very useful.

Still, considering how poorly parallel.c performs in serial mode, I would think beating it in parallel mode on the same computer would be easy. Do you think a parallel code written in Visual BASIC would work more efficiently on your Windows 10 computer?

User avatar
scruss
Posts: 1941
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 2:44 am

ejolson wrote:
Thu Jan 10, 2019 9:06 pm
I have never heard of FortranG.
It seems I've got the name slightly wrong as I'm unable to find any reference by searching.
FORTRAN H and FORTRAN G were S/360 things. In conversation with the "A FORTRAN Coloring Book" author, he reminisced that one had COMPLEX and the other didn't. He also admitted to never really liking FORTRAN much, or using it for anything substantial afterwards. Seems that MIT taught students on a painfully slow system and it was no fun to work with.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 4:46 am

scruss wrote:
Sat Jan 12, 2019 2:44 am
ejolson wrote:
Thu Jan 10, 2019 9:06 pm
I have never heard of FortranG.
It seems I've got the name slightly wrong as I'm unable to find any reference by searching.
FORTRAN H and FORTRAN G were S/360 things. In conversation with the "A FORTRAN Coloring Book" author, he reminisced that one had COMPLEX and the other didn't. He also admitted to never really liking FORTRAN much, or using it for anything substantial afterwards. Seems that MIT taught students on a painfully slow system and it was no fun to work with.
Thanks for the information. Fortran G being an S/360 compiler sounds right.

I still have Dr Kaufman's book on my shelf. It's treasured for bringing back memories, for the way it characterises how introductory programming courses used to be and, of course, the humour.

In relation to this thread one might ask, why avoid BASIC when there is Fortran?

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 5:40 am

The case for Basic.
Normally it is interpreted, so no need for a compiler.
Use cases I can think of, are quickly made simple stuff.
Some projects I have done in Shell script, SED, AWK with Micropython for a touch of GPIO speed.
It could have been done in Basic, probably.

When you have Pi's the hardware can run at 700-1GHz, plenty of cpu cycles to be used up for once every minute dataloggers.
Part of the reason I am looking at high level languages and AI stuff is these dataloggers applications are idle 98% of the time.
Turn smart sensors into super smart ones that do onboard predictive maintenance algorithms.
Yes R does run on Pi's ;) Microsoft liked this idea so much they acquired the Company.

Scripting, interpreted languages allow for instant code changes.
I have wireless modules with Python and Basic on them allowing for OTA(Over The Air updates).
I have changed scripts on running equipment more than 100Km away in another City.
Some things will need fast code, but with IoT going everywhere diversity means anything could be useful.

So perhaps I should look at FreeBASIC too.
Ok, its compiled, will it compile on Aarch64?
But what about a Basic Interpreter?
https://sites.google.com/site/smallbasi ... eters/home

Learning how to write one could be useful.
I wrote some shell extensions for testing i2c hardware in Ultibo, lots of fun, but I could see I was reinventing the Busybox toolset.
A scripting language for Ultibo is on my list of things to do, just copy BASH?.
But which language to use? What language do I write the interpreter in?

In the old day of embedded coding there was C, now we have many choices.
With $35 Desktops, $5 Zero, $1 CortexM0's, $0.03 Microcontroller's, computing has never been so cheap.
With such cheap hardware, now the expense is in the time to code them.
Lucky for people like us, these things don't yet code themselves.

I have asked this question before, "If I was a self aware AI robot, which language would I code in?"
Will we know this nanoseconds after Intel turns on their first 1million Qubit CPU?
Who will be the first 1M Qubit computer programmer and what language will they use?
Ok, my GentooPi has finished it's genup, time to code.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Sat Jan 12, 2019 7:10 am

ejolson,
In relation to this thread one might ask, why avoid BASIC when there is Fortran?
The skillful, experienced programmer learns to avoid multiple languages, at the same time.

It's not easy but after years of practice, on a typical day, I can avoid: BASIC, Fortran, Pascal, Java, C#, Forth, Erlang, PHP, Ruby, Lisp, and others.

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.

Return to “Off topic discussion”