16

I recently came across a thread suggesting the versions of CBM BASIC on later machines, I believe the Plus4 and 128 were mentioned, were significantly slower that earlier versions. I haven't found benchmarks comparing the two, but I'm wondering if anyone is familiar with this and might suggest why this would have happened (assuming it did)? The two seem basically identical in design, which suggest waits on memory or more interrupts?

Similarly, perhaps(?), CBM BASIC 3.5 (on the TED series, e.g. the Plus/4) and 7.0 (on the C128), which are both based on MS BASIC and heavily modified by Commodore, run significantly slower than version 2.0 on the C64. Tested with a simple FOR-NEXT loop on VICE (accurate enough, as I've verified on real equipment in the past), the Plus/4 takes about 43% longer to finish, while the C128 in slow mode (to use the VIC-II) takes another 4% longer on top of that.

Improve this question
3
  • AFAIR the Plus/4 was BASIC 3.5. Does that thread tell anything about what aspect the speed loss was supposed to be about?
    – Raffzahn
    Nov 21, 2021 at 14:53
  • 1
    Quote added, it's a significant slowdown.
    – Maury Markowitz
    Nov 21, 2021 at 15:02
  • 1
    Benchmarks suggesting the slowdown is real (and less dramatic) exist here:retroprogramming.com/2010/01/… - seems BASIC 7.0 is about 25% slower and BASIC 3.5 about 5% slower.
    – Brian H
    Nov 21, 2021 at 16:36

3 Answers 3

Reset to default
17

The BASIC versions for both the Plus/4 and the C128 use a more complicated memory setup: BASIC 3.5 (+4) can access about 59K of RAM - that's only possible because it constantly disables and reenables the BASIC and Kernal ROMs.

The C128 stores the BASIC listing in one 64K RAM bank, all variables are stored in the other 64K RAM bank, so there's a lot of bankswitching neccessary when running a BASIC program.

Additionally, the standard interrupt routine on a C128 is much more complicated (i.e. it eats up more ressources): It has to take care of BASIC commands like SOUND and MOVSPR that take several seconds to complete while the actual BASIC programm continues to run. Or stuff like raster interrupts that keep running until disabled.

Improve this answer
6
  • Indeed BASIC 7.0 is, practically speaking, a whole new language. It was one of the primary motivations for some people to upgrade from the C64. Though you really wanted to stay in FAST mode whenever possible.
    – Brian H
    Nov 22, 2021 at 14:31
  • Now when you say "whole new language", how "whole" is that? Did they make major changes to the actual interpreter in terms of parsing tables and such? It seems to mostly be an expansion on 4.x. The memory issue is a horse of another color... it seems like a bad tradeoff to me, given that the earlier versions were not that fast to begin with (compare with Turbo-BASIC XL).
    – Maury Markowitz
    Nov 22, 2021 at 19:24
  • @MauryMarkowitz: An interesting trade-off made in V7 was the fact that string literals get represented by garbage-collected strings rather than simply having string references identify literals in the code. This makes it necessary to copy string literals into the gc area, which is bad, but also makes it possible to precede each string by a little bit of extra information that can allow the GC to run much faster.
    – supercat
    Nov 22, 2021 at 23:47
  • @supercat - very interesting! did the setup happen at runtime or edit time?
    – Maury Markowitz
    Nov 23, 2021 at 12:41
  • @MauryMarkowitz: Runtime. In older versions, A$="HEY" would cause A$ to hold a pointer to the string in the source code, but in V7 the source code was stored in one 64K bank while runtime strings were stored in the other bank. I don't know whether FOR I=1 TO 10:A$="HEY":NEXT would copy the string once or ten times. I would hope once, but I don't know how the second iteration of the loop would know that the string had been copied once.
    – supercat
    Nov 23, 2021 at 15:40
16

I've benchmarked the various Commodore BASICs on their 8-bit systems. This benchmark tests 10,000 iterations of FOR/NEXT, GOSUB/RETURN, GOTO, variable manipulation of integers, floats, and strings, and multiplication and division.

Benchmarking only a FOR/NEXT loops is rather simplistic. My results below should be more nuanced, but I included my FOR/NEXT results, as well as per MHz results so you can see the difference if the systems were all running at the same MHz.

BASIC v3.5 on the Plus/4 is about 28% slower than BASIC v2 on the c64, while BASIC v7 on the C128 @ 1 MHz is about 33% slower than the speed of BASIC v2 on the C64. This results in BASIC v7 on the C128 @ 1 MHz being about 18% slower than BASIC v3.5 on the Plus/4.

System BASIC FOR/NEXT/s Iters/s Iters/s@1MHz
Commodore PET v1 619.2 6,122.5 6,122.45
Commodore PET v2 625.0 5,884.2 5,884.16
Commodore PET v4 655.7 6,017.7 6,017.70
Commodore VIC-20 v2 810.8 7,300.5 7,138.44
Commodore 64 v2 679.5 6,125.9 5,988.22
Commodore CBM 500 v4 395.3 3,427.0 3,349.96
Commodore CBM 600 v4 1030.9 9,017.3 4,420.22
Commodore Plus/4 v3.5 530.5 4,882.8 2,727.81
Commodore 128 (C64 mode) v2 678.0 6,137.6 5,999.59
Commodore 128 @ 1 MHz v7 449.8 3,858.0 3,771.31
Commodore 128 @ 2 MHz v7 937.5 8,049.2 3,945.69
Improve this answer
2
  • Nice work! These really are quite a performance hit, that Plus/4 time is tending down to Atari levels.
    – Maury Markowitz
    Nov 22, 2021 at 19:22
  • A lot of Atari BASIC's slowness is due to the BCD floating point routines in the OS ROM but the rest is due to the implementation. The Atari also loses CPU cycles to the ANTIC depending on the current video mode. Atari BASIC: FOR/NEXT/s: 437.6, Iters/s: 3293.8, Iters/s@1MHz: 1840.12 Atari BASIC XE: FOR/NEXT/s: 621.1, Iters/s: 8049.7, Iters/s@1MHz: 4497.06
    – Tim Locke
    Nov 22, 2021 at 21:26
1

The reasons for C128 BASIC being slower are already well described, but maybe this is a clearer set of results:

 Machine   :  bench64  :  Graphical rank
-----------+-----------+--------------------------------------------
PET2001    :        90 : ####################################              
PET4032    :        87 : ##################################                
PET8032    :        83 : #################################                 
VIC-20     :       106 : ##########################################        
C64        :       100 : ########################################          
C128       :        71 : ############################                      
C16/+4     :        78 : ###############################

Results are from bench64, but it does show that the faster interpreter isn't necessarily the older one.

Improve this answer
2
  • Well that depends much on what this 'bench64' does test. Does it include only interpreter operations (like Tim's FOR-NEXT does), or are there additional (maybe many) kernel calls, like character output or scrolling? 'cause in that case it may be equally if not more influenced by performance of screen routines or alike - and the kernel is what may differ more between those PET models, than the BASIC.
    – Raffzahn
    May 15 at 17:38
  • It tests purely interpreter functions, @Raffzahn, with minimal output - it's portable. It also shows how hard it is to usefully benchmark computers like the first PETs: if you simply renumber it starting at 260, the PET2001 will run faster than the C64 because of the GOTO bug
    – scruss
    May 15 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.