Why was BBC BASIC so fast?

[Coeus]

I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:

Here are some figures from B-Em which I believe has the Z80 timing accurate.

realclock.png (3.77 KiB) Viewed 1161 times

That has a clock speed of 6Mhz so if everything else were the same it would be 1.5x as fast as the Einstein. Scaling up the Einstein figures gives

Code: Select all

Really real REPEAT loop 2.16Mhz
Integer REPEAT loop     1.845Mhz
Really real FOR loop    1.335Mhz
Integer FOR loop        0.93Mhz
Trig/Log test           5.10Mhz
String manipulation     1.90Mhz
Procedure call          2.145Mhz
GOSUB call              1.455Mhz
Combined Average        2.145Mhz

That's pretty close so suggests there problem isn't much if any memory access contention on the Einstein, very different from the Sinclair machines.

[jgharston]

Fixed.

I can't see any difference and the files on that page, both ZIP and BIN, seem to be the same as before.

I bet the link is broken. I'll fix it when I get home and can FTP to it. The ZIP should contain the BIN and ASM both dated 26-Oct-2020.

I've probably called it something like EhBasic222p4v1 or something.

[Lardo Boffin]

I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:

That's pretty close so suggests there problem isn't much if any memory access contention on the Einstein, very different from the Sinclair machines.

The Tatung has 16K of dedicated video RAM outside of the 64K main RAM so presumably that helps.

Multiplied by 1.5 the figures are impressively close! Does the co-proc version gain a small advantage due to only doing language processing and no house keeping / handling interrupts etc.?

[jgharston]

Fixed.

I can't see any difference and the files on that page, both ZIP and BIN, seem to be the same as before.

I bet the link is broken. I'll fix it when I get home and can FTP to it. The ZIP should contain the BIN and ASM both dated 26-Oct-2020.
I've probably called it something like EhBasic222p4v1 or something.

Do'h! My FTP client was still resolving to the old server. Really fixed now.

[1024MAK]

I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:

That's pretty close so suggests there problem isn't much if any memory access contention on the Einstein, very different from the Sinclair machines.

The Tatung has 16K of dedicated video RAM outside of the 64K main RAM so presumably that helps.

That’s because it uses the Texas Instruments TMS9129 Video Display Controller (VDC). These map to a small range of I/O addresses in the microprocessors I/O space and have their own video RAM (which is not connected to the microprocessor). Various other machines have a similar arrangement.

Mark

[Coeus]

I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:
Multiplied by 1.5 the figures are impressively close! Does the co-proc version gain a small advantage due to only doing language processing and no house keeping / handling interrupts etc.?

I don't think there will be any interrupt activity on the second processor during that test. Interrupts can be used as part of the tube transfers but, once loaded, that test runs entirely from RAM and sending characters over the tube to be printed does not use interrupts on the client (2nd proc).

We also need to be careful about parallelism when measuring performance. On the I/O processor, when one calls OSWRCH to write a character to the screen, the calling program then has to wait for the screen write to happen before OSWRCH returns. On the 2nd processor, OSWRCH just stuffs the character into a FIFO in the tube ULA and then the I/O processor will receive it, and print it, while the 2nd processor gets on with the next thing. Obviouly the FIFO has limited depth so sometimes OSWRCH will have to wait because the FIFO is full, but that's going to be less than 100% of the time.

For this benchmark, though, I don't think it makes any difference as the timed loops themselves don't generate output - the printing happens beween tests.

So back to the overhead of interrupts the BBC MOS uses interrupts extensively. Many of them only happen in response to things like typing keys, characters arriving from RS423/tape or being printed on the printer, but there is a regular timer interrupt, a VSYNC interrupt and end of ADC conversion that just happen every so often regardless unless dsabled.

But the real question for the comparison is what level of interrupt activity there is on the Einstein.

[Lardo Boffin]

I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:
Multiplied by 1.5 the figures are impressively close! Does the co-proc version gain a small advantage due to only doing language processing and no house keeping / handling interrupts etc.?

But the real question for the comparison is what level of interrupt activity there is on the Einstein.

This was what I was wondering. I assumed the interrupts would be minimal on the co-proc but would be ‘normal’ (whatever that is for the TC01) on the tatung hence the co-proc being slightly faster.

[Coeus]

Do'h! My FTP client was still resolving to the old server. Really fixed now.

So EhBASIC has the same issue with jumping out of FOR loops as BBC BASIC. Running the reference implementation:

Code: Select all

 1  GOTO 10
 5 COUNT = COUNT + 1
 6  GOTO 50
 10  DIM PRIMES(99)
 20 PRIMES(0) = 2
 25  PRINT PRIMES(0)
 30 COUNT = 3
 40  FOR FOUND = 1 TO 99
 50  FOR INDEX = 0 TO (FOUND - 1)
 60 V = COUNT / PRIMES(INDEX)
 65  IF ( V =  INT(V)) THEN  GOTO 5
 70  NEXT INDEX
 80  PRINT COUNT
 90 PRIMES(FOUND) = COUNT
 100 COUNT = COUNT + 1
 110  NEXT FOUND
 120  END

I get "Out of memory error in line 60". It also has a quirk that the ( of INT( must have no separating space or this is interpreted as an array access rather than a function call. So modifying it to deal with the FOR loop problem:

Code: Select all

 1  GOTO 10
 5 INDEX=FOUND - 1
 6 NEXT INDEX
 7 COUNT = COUNT + 1
 8  GOTO 50
 10  DIM PRIMES(99)
 20 PRIMES(0) = 2
 25  PRINT PRIMES(0)
 30 COUNT = 3
 40  FOR FOUND = 1 TO 99
 50  FOR INDEX = 0 TO (FOUND - 1)
 60 V = COUNT / PRIMES(INDEX)
 65  IF ( V =  INT(V)) THEN  GOTO 5
 70  NEXT INDEX
 80  PRINT COUNT
 90 PRIMES(FOUND) = COUNT
 100 COUNT = COUNT + 1
 110  NEXT FOUND
 120  END

and it's really slow. It took 3m15s running on the 6502 2nd processor (because that's what it is supplied assembled for). I can't run the exact same code in BBC BASIC because COUNT is a reserved word but changing that to COUNU (same length so no advantage) gives a timing of 27s so over 7x the speed. Running the BBC optimised version (below) completes in 10.7s on the same 2nd processor.

Code: Select all

   10DIMP%(100)
   20C%=2
   30FORF%=1TO100
   40PRINTC%
   50P%(F%)=C%
   60C%=C%+1
   70FORI%=1TOF%
   80IFC%MODP%(I%)=0THEN120
   90NEXTI%
  100NEXTF%
  110END
  120I%=F%
  130NEXTI%
  140GOTO60

[jgharston]

We also need to be careful about parallelism when measuring performance.
...
For this benchmark, though, I don't think it makes any difference as the timed loops themselves don't generate output - the printing happens beween tests.

If you read the documentation and the REMs, ClockSp is specifically coded to just solely explicitly test the speed of the /interpreter/ *NOT* the I/O system.

[jgharston]

So EhBASIC has the same issue with jumping out of FOR loops as BBC BASIC. Running the reference implementation:

No, what you mean is the author of the code has the same problem in his brain causing him to write broken FOR/NEXT loops

It also has a quirk that the ( of INT( must have no separating space or this is interpreted as an array access rather than a function call. So modifying it to deal with the FOR loop problem:

I think that's one of the Patch5 bugfixes.

With so few people working in the office at work, we've got the service desk queue down to single figures (it's usually in the mid-100s!!!), I'm tempted to take some coding to work instead of twiddling my fingers and clicking REFRESH on the incident dashboard every 30 minutes.

[jgharston]

So EhBASIC has the same issue with jumping out of FOR loops as BBC BASIC. Running the reference implementation:

No, what you mean is the author of the code has the same problem in his brain causing him to write broken FOR/NEXT loops

It also has a quirk that the ( of INT( must have no separating space or this is interpreted as an array access rather than a function call. So modifying it to deal with the FOR loop problem:

I think that's one of the Patch5 bugfixes.

With so few people working in the office at work, we've got the service desk queue down to single figures (it's usually in the mid-100s!!!), I'm tempted to take some coding to work instead of twiddling my fingers and clicking REFRESH on the incident dashboard every 30 minutes.

Edit:
1 GOTO 10
5 ...
8 GOTO 50
...
GOTO 5

what concussed sort of code is this?

[BigEd]

A wild guess: in Fortran you get FOR loops and GOTO and you can go wild. As in simple Basics - but not the Basics we have in mind.

I do like prime number programs, and yet though they don't strongly lend themselves to structured programming.

[Coeus]

Edit:
1 GOTO 10
5 ...
8 GOTO 50
...
GOTO 5

I had assumed It's written for a BASIC in which the only way for the program to finish is to get to the last statement, so there can be nothing after that. And don't many assembler programs start with a jump to some initialisation code?

My BBC optimised version also has a little "diversion" like this one but I have put it at the end rather than the beginning. Or maybe the author put this little diversion at the start of the program so finding the line number would be faster.

Of course, in the BBC Basic version one could also write it with a multi-statement line as:

Code: Select all

   10DIMP%(100)
   20C%=2
   30FORF%=1TO100
   40PRINTC%
   50P%(F%)=C%
   60C%=C%+1
   70FORI%=1TOF%
   80IFC%MODP%(I%)=0THENI%=F%:NEXTI%:GOTO60
   90NEXTI%
  100NEXTF%
  110END

There isn't really an elegant solution without a statement that means specifically "break out of this loop", i.e. the C break statement.

[Coeus]

A wild guess: in Fortran you get FOR loops and GOTO and you can go wild. As in simple Basics - but not the Basics we have in mind.

So why in simple BASICs?

In compiled languages, loops are generally lexically scoped. The compiler does the housekeeping and the generated code can just to the test and do to the address determined by the compiler so there is no leakage inherent from the loop control, though obviously you can introduce your own leakage depending on what you put in the loop.

I suppose a very simplistic BASIC interpreter could offer the same if NEXT searched the program for a FOR with the same variable name and thus did not need to put anything on a stack. That could possibly be speeded up instead by keeping an index of loop control variables and the address of the corresponding FOR.

[BigEd]

Umm, yes, it's a good point, how do I expect an interpreter to be so forgiving about non-nested FOR/NEXT... I suppose instead of a stack it could keep a list, and if it doesn't find a record then that's a NEXT without FOR, which it could either be forgiving about or throw an error. It needn't ever tidy up the list, or expect things to be nested.

[1024MAK]

In some BASIC versions, you can’t have multi-statement lines, hence an IF THEN will GOTO somewhere else to do whatever is needed. It’s going to the second line of the program for maximum speed (assuming the search for the correct line number starts from the beginning of the program).

Also in some BASIC versions, you can GOTO a FOR statement as many times as you like, or indeed have more than one FOR statement using the same variable before the execution gets to a matching NEXT statement. The last FOR statement encountered for that variable resets the values used by the FOR variable, and this FOR statement is the one that the NEXT will loop back to.

Mark

[lurkio]

Also in some BASIC versions, you can GOTO a FOR statement as many times as you like, or indeed have more than one FOR statement using the same variable before the execution gets to a matching NEXT statement. The last FOR statement encountered for that variable resets the values used by the FOR variable, and this FOR statement is the one that the NEXT will loop back to.

Do you happen to know if that's what any of the TRS-80 BASICs did?

[jimmy]

Can anybody confirm that BBC BASIC Z80 v3.x is slower than v2.x?
I've just tried with the v3.10 BBC BASIC source code (from CPMish Git area - thank you RTR for allowing this!) and the timings are different (for the worse):
Red border screenshot shows v3.10 on a ZX Spectrum 128

Blue border screenshot shows v2.20 (JGH's version) on a ZX Spectrum 128

I'm happy for it to be my (rough) conversion at fault - and I've tried to confirm using the generic CP/M BBC BASIC 3.00 version, but this doesn't support TIME so the benchmarks won't work. All I've done so far is to take all the source code fragments and put them into one file (with some label renaming) and add a simple I/O handler. There are some opportunities for optimisation, but even they can't close this performance gap.

[1024MAK]

Are they running from the same memory? Or from different memory areas?

I ask because some RAM is contended on the ZX Spectrum, so how fast the code runs depends on which part of memory is being used.

Mark

[jimmy]

I''ve tried to avoid contended memory wherever possible, so PAGE for BASIC starts at &8000, the BASIC Z80 code is in ROM space &0000-&3FFF, and the BASIC sysvars are at &F000. The only values in contended memory are to do with I/O routines - as I have to provide input and output routines since I've paged out the ZX ROM. The benchmarks are slightly flattering for the Spectrum as the 128 model is used so the CPU speed is slightly increased to 3.54MHz.
Richard has kindly got in touch with me to suggest a few reasons why v3 is slower than v2. Unfortunately the v2 source is not available, but I think a dissasembly using the v3 source routines as a guide should be possible.
I was surprised to find out that the ZX Spectrum 'wastes' more than 1% of CPU time scanning the keyboard 50 times a second. By changing the standard IM1 routine to abort a keyscan if no keys are pressed, I got an instant speed-up for BBC BASIC increasing the combined average speed by 0.01MHz.
I've come up with a few other ideas for improving the speed. I've already taken the quick win of page-aligning the Dispatch table, allowing the jump code to be shortened and simplified.

[scruss]

Hmm, BBC BASIC for Amstrad CPC (v2) turns in some dismal but not unexpected numbers:

clocksp on emulated Amstrad CPC, Z80 BBC BASIC v2

clocksp-v2.png (4.74 KiB) Viewed 649 times

The CPC's clock ran at an effective 3.3 MHz, so I might expect slightly slower numbers than the ZX Spectrum.

Despite the slowness, the Amstrad completed the test in 56 s, while a BBC might do it in around 49 s. I'm not sure why I feel this, but I think I'd prefer a benchmark that runs the same amount of code on each machine rather than a variable amount depending on a calibration run and tweaked constants.

[BigEd]

Indeed, ClockSp does autocalibrate - which is quite handy when the range of machines goes from pretty slow to very fast indeed.

[Richard Russell]

BBC BASIC for Amstrad CPC (v2) turns in some dismal but not unexpected numbers

You are running the old version of ClockSp in which the 'real' measurements are nothing of the sort (they are actually integer loops), making Z80 BBC BASIC appear much faster than it actually is. For a meaningful comparison you need to run the modified version of the program which reports "Really real REPEAT loop" and "Really real FOR loop".

[scruss]

You are running the old version of ClockSp in which the 'real' measurements are nothing of the sort …

· I'm running the same version as jimmy.
· It's also the same version on JGH's site and in the beebjit emulator
· The really real version isn't anywhere I can find.

[Richard Russell]

The really real version isn't anywhere I can find.

It's in this very thread! Here's a direct link to the post containing the listing; Coeus used it in his post listing the 'reference' Z80 Second Processor results from B-Em.

The original version is only suitable for testing emulators running the 6502 (or ARM) BASIC interpreter, it gives misleading results when run with any of my interpreters (Z80, 8086, IA-32 or the cross-platform editions written in C) because they detect that the so-called 'real' loops are actually using integers.

[Kweepa]

Has anyone analysed the differences between BBC, Master, and Master Compact BASIC?
I'm amazed at the improvements in the speed of the math routines over the versions.

[1024MAK]

Also in some BASIC versions, you can GOTO a FOR statement as many times as you like, or indeed have more than one FOR statement using the same variable before the execution gets to a matching NEXT statement. The last FOR statement encountered for that variable resets the values used by the FOR variable, and this FOR statement is the one that the NEXT will loop back to.

Do you happen to know if that's what any of the TRS-80 BASICs did?

The only TRS-80 that I have is a TRS-80 Model 100
See photos...

TRS-80 Model 100

Hello StarDot forum

Program listing

Program output

Mark

[lurkio]

Do you happen to know if that's what any of the TRS-80 BASICs did?

...

Thanks for that! Of course, I could be a smartarse and point out that that doesn't prove anything because even a Beeb will display ten iterations of the loop, and your photo only shows seven! But I presume you're trying to say that the Model 100 keeps going indefinitely. Nice demo.

[BeebMaster]

Can some BASICs not do nested loops at all then? I think I would find that very limiting.

[1024MAK]

Another ‘unconventional’ FOR - NEXT program:

Program listing

Program output

Mark