BBC BASIC
« Why is BB4W (and its derivatives) so slow? »

Welcome Guest. Please Login or Register.
Jan 23rd, 2018, 7:12pm


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Why is BB4W (and its derivatives) so slow?  (Read 1017 times)
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Why is BB4W (and its derivatives) so slow?
« Thread started on: May 4th, 2016, 12:16am »

By common consent, BBC BASIC for Windows is shockingly slow. In league tables of BASICs, ranked by speed, it is often at or near the bottom (fortunately there are even slower BASICs - Liberty BASIC and its cousin Just BASIC - so if they are included in the ranking it can keep BBC BASIC from last place).

Why is BB4W - and its derivatives such as the SDL2 versions for Linux and Android (86) - so slow? Is it perhaps an inherent property of the dialect? That is certainly true to a degree: BBC BASIC is interpreted, and interpreted languages inevitably run much more slowly than compiled languages. But that can't be the whole story because Acorn versions of BBC BASIC, including the original 6502 version on the BBC Micro, had a reputation for being exceptionally fast.

So if not inherent to the dialect, perhaps it's the CPU. Maybe the 6502 and ARM processors have an architecture or instruction set better suited to executing tokenised BBC BASIC code. That's not so implausible when you consider that the language was developed specifically to run on a 6502 - and the ARM instruction set was devised by the same person who created BBC BASIC! But that can't be it either, because Brandy (a cross-platform version of BBC BASIC written in portable C) runs at a comparable speed to - and sometimes faster than - BB4W on the same processor.

That really leaves only one explanation: incompetence! To see why, we need to go back about 34 years. At that time I was keen to have a version of BBC BASIC for the CPU with which I was most familiar - the Z80. I knew a lot about the language, including some subtle details that I gleaned from Acorn, but crucially I had not the first idea how to write an interpreter. I was a self-taught amateur programmer, and in those days there was no Google to search for "how to write a BASIC interpreter"!

So I just dived in without knowing what I was doing. The result was an interpreter that worked, but the code was na´ve and terribly slow. That could easily have been the end of the story - who would want such a slow version of BBC BASIC? - but I had a stroke of luck. The benchmarks used to compare speed needed to be written in 'generic' BASIC so they would run without modification on all the different dialects. That implied the use of 'undecorated' variable names, e.g. I or N.

Now in the original BBC BASIC a variable of this sort, without any suffix character, was a 40-bit floating-point variable. The poor old 8-bit 6502 processor had no hardware support for floating-point arithmetic, so even something as simple as an integer FOR...NEXT loop (typical of benchmark programs of the day) would internally be carrying out the computations in floating-point and therefore much slower than it would have been using integer variables like I% and N%.

I realised that this allowed me to 'cheat'! By modifying my Z80 BASIC so that undecorated variables were variants rather than floats (and therefore capable of holding integer values) the same benchmark program running on my version would use integer calculations and - apparently - run at a comparable speed to the 6502 version. It was an illusion of course: adding a % suffix to the variables would cause the 6502 version to speed up tremendously but have little or no effect on the Z80 version.

The amazing thing is that the na´ve, slow, interpreter architecture that I devised from scratch for the Z80 in 1982 is basically unchanged in BB4W! The 8-bit Z80 code was first translated to 16-bit 8086 code for MS-DOS, and then the 16-bit code was translated to 32-bit IA-32 code for Windows. But these were largely 'mechanical' translations and the code structure is the same.

So there we have it. BB4W is slow, in part, because it consists of crappy code written by an incompetent and inexperienced programmer. sad

Richard.
« Last Edit: May 4th, 2016, 12:25am by Richard Russell » User IP Logged

michaelgallup
Guest
xx Re: Why is BB4W (and its derivatives) so slow?
« Reply #1 on: May 4th, 2016, 04:02am »

The language is fine for one of the oldest BASIC languages on the planet. (though the Windows version is 15 years old I think)
A person could always do a facelift to the language?

"We can make it better, faster, stronger "


User IP Logged

Edja
New Member
Image


member is offline

Avatar




PM


Posts: 22
xx Re: Why is BB4W (and its derivatives) so slow?
« Reply #2 on: May 4th, 2016, 10:51am »

Quote:
So there we have it. BB4W is slow, in part, because ....
BB4W is more then just the interpreter. The quality of BB4W is to be measured as the sum of a number of parameters. Speed is one of them, in my case totally insignificant. I would rank other parameters a lot higher :
  • absence of bugs
  • clarity of the documentation
  • features & functions
  • libraries !!
  • development tools
  • support
So this doesn't change my appreciation of the language. But that's just me. Or ... is that just me ?

As said above speed is the least of my concerns.
But the following question stems from a mixture of some curiosity and a large dose of naivety: maybe part or parts of the interpreter could be rewritten to better exploit the instruction set of the Intel processors. I remember from previous threads that you are "reluctant" (and rightfully !) to modify this very stable code, but maybe there is some low hanging fruit to be found?

Edja
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Re: Why is BB4W (and its derivatives) so slow?
« Reply #3 on: May 4th, 2016, 1:49pm »

on May 4th, 2016, 10:51am, Edja wrote:
maybe there is some low hanging fruit to be found?

I don't think so. A few years ago I profiled the interpreter, to see where most of the time was being spent when running a typical program (this was in itself an interesting project, because the profiler was written in BB4W - loosely based on the BASIC program profiler but instead measuring time spent in the interpreter!).

I did succeed in finding a couple of bottlenecks that I was able to improve upon - I can't remember the version numbers now but there was a worthwhile step in performance at one of the BB4W upgrades - but nothing else amenable to an easy and safe fix.

To make a further significant improvement would require one or other (or both) of two extensive - and hence both difficult and risky - changes:
  • Convert the run-time engine from a conventional interpreter to a Just In Time compiler, i.e. translating the BASIC program to machine-code on-the-fly at run time.

  • Rather than execute the original tokenised BASIC program, perform some 'pre-processing' operations and execute the resulting 'intermediate code'.
The second of these is how Brandy works. Because it is coded in portable C it is inherently slower than an interpreter written in assembly language, but by pre-computing things like the destination of a jump or the ELSE clause of an IF statement it can save time which would otherwise be spent searching at run-time.

There are other potential benefits of executing not the original BASIC code but an intermediate 'semi compiled' version. Things like macros can be implemented, or a true 'include' statement, or inserting temporary breakpoints without changing the program code. Some of these features have already been taken advantage of in LBB (LB Booster) which runs Liberty BASIC code by translating it to BBC BASIC. That supports, for example, SEH and OOP extensions using a much nicer syntax than available in BB4W (because the user never sees the actual BBC BASIC code).

On and off over the last year or so I have been working on a replacement IDE for BB4W, itself written entirely in BBC BASIC. The idea was not to add to the functionality, but to make it available as an Open Source IDE that could be developed and enhanced independently of me. Because that runs programs the way LBB does (not by executing the program in memory) it would be possible to incorporate some of the same features - it already has 'true' breakpoints.

I should mention the REM!Fast compiler directive available in BB4W version 6. This can produce a worthwhile speed increase, because variables, arrays, structures, functions, procedures etc. can be accessed about as fast as the static integer variables. Code containing 'fast' variables isn't readable in the BB4W editor, but the run-time-engine (BBCWRUN6.EXE) knows how to execute it. Although it currently doesn't, the Open Source IDE could take advantage of that too.

Richard.
« Last Edit: May 4th, 2016, 9:38pm by Richard Russell » User IP Logged

michaelgallup
Guest
xx Re: Why is BB4W (and its derivatives) so slow?
« Reply #4 on: May 4th, 2016, 1:56pm »

Quote:
But the following question stems from a mixture of some curiosity and a large dose of naivety: maybe part or parts of the interpreter could be rewritten to better exploit the instruction set of the Intel processors.


Not many people would know how to use the assembler, and those that do can make BBC do some amazing graphics magic.. Like DDRM did with the Christmas fractal.. That was cool and blazingly fast.
Perhaps a library that would give that assembly language speed to the native draws. I know that the asm can give this power, but can that boost be given with a new set of commands that use the assembler language be made simple? Perhaps there remains some people that could help give BBC that boost and make it simple for the native commands?

How much faster is the compiled program VS the IDE executed program in BBC?

« Last Edit: May 4th, 2016, 2:21pm by michaelgallup » User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Re: Why is BB4W (and its derivatives) so slow?
« Reply #5 on: May 4th, 2016, 5:44pm »

on May 4th, 2016, 1:56pm, michael wrote:
Perhaps a library that would give that assembly language speed to the native draws.

Graphics are almost always dominated by the plotting/rendering speed, so it often makes virtually no difference whether the program is coded in BASIC or assembly language or anything else. Look at TEAPOT.BBC and WORLD.BBC in the supplied examples: they are coded entirely in BASIC (even D3DLIB is BASIC) but if you check with the profiler hardly any time is actually spent in the interpreter.

The reason assembler code benefits programs such as MANDEL.BBC is not to do with the graphics, but the complex mathematical calculations that are required. Anyway it's quite likely that the graphics plotting is happening in the GPU, not the CPU, so it's probably already faster than the fastest possible assembler code!

The idea that coding something in assembler rather than BASIC will always make it run significantly faster is totally false. Get familiar with using the Profiler so you know where the time is being spent, and therefore which optimisations are worthwhile and which are completely unnecessary.

Richard.
« Last Edit: May 4th, 2016, 6:37pm by Richard Russell » User IP Logged

Richey
New Member
Image


member is offline

Avatar




PM


Posts: 1
xx Re: Why is BB4W (and its derivatives) so slow?
« Reply #6 on: May 4th, 2016, 10:05pm »

According to this benchmark, BB4W is by no means the slowest interpreter tested.

http://retrogamecoding.org/board/index.php?topic=443.0

It beat Thinbasic, which also appears within the TIOBE Index along with BBC BASIC (looks like Ed didn't test PureBasic or VB, which are the other BASIC dialects found in the TIOBE Index).

A lot of the other BASICs tested that are quicker than BB4W are native / VM / JIT compilers.

So, BB4W as an interpreter is by no means a slouch - but it also has all the advantages outlined by Edja.

In conclusion : one of the best BASICs - IMHO languages - out there.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Re: Why is BB4W (and its derivatives) so slow?
« Reply #7 on: May 5th, 2016, 09:36am »

on May 4th, 2016, 10:05pm, Richey wrote:
A lot of the other BASICs tested that are quicker than BB4W are native / VM / JIT compilers.

Indeed this is true, but the average user neither understands nor cares about the difference. I have had a number of Visual Basic and PowerBasic users contact me to ask about the suitability of BBC BASIC as an alternative, and they are often perplexed by the large speed difference (about 500 times slower than the fastest BASIC according to the table you linked to).

BBC BASIC is, as far as I am aware, unique amongst current products in being a traditional interpreted BASIC in which the run-time engine executes the very same program that the user sees and edits, i.e. without intermediate code generation of any kind (I am excluding scripting languages like ScriptBASIC). Even Liberty BASIC generates an intermediate form (the so-called TKN file, although it's not tokenised) which the run-time engine executes.

Looked at in that light BBC BASIC is not slow in comparison with similar products, because there are no directly comparable products! But as I say the typical user isn't interested in what goes on under the hood.

Richard.
« Last Edit: May 5th, 2016, 09:43am by Richard Russell » User IP Logged

michaelgallup
Guest
xx Re: Why is BB4W (and its derivatives) so slow?
« Reply #8 on: May 5th, 2016, 3:08pm »

I prefer these styles of editors that are complete and have lots of documentation.
I hate it if something has bugs or missing libraries that you have to hunt for.
Aren't the majority of programmers hobby programmers?
I am a hobby programmer.
I really am trying to keep my language learning central to something I can relate to.

User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls