It's even much worse than that ;)

The fastest Z80 instructions are 4 clock cycles, at least 7 clock cycles if they also need to load or store an 8-bit value from/to memory, and at least 10 clock cycles for instructions that load or store a 16-bit value.

I did a little deep dive into Z80 timings a little while ago using the Z80 netlist simulation from visual6502.org:

https://floooh.github.io/2021/12/06/z80-instruction-timing.h...

But for BASIC programs those timings don't matter much, since BASIC on 8-bit home computers was easily 100x times slower than assembly code doing the same thing (the difference is probably less though when floating point math is involved, since this also needs to be 'software-emulated' in assembly).

To grasp the interpreter speed you need to remember how memory was even more of a constraint than CPU. BASIC had to hold your code in RAM in way that's source-editable and runnable and compact, and process it using interpreter code that's also squeezed for its space. Any obvious optimization you just assume for a speed demon like Python nowadays, you might be surprised about when it comes to those 8-bit Basics.

Damn, we’re in CPI territory

Yup. Everything pre-RISC was CPI (Cray doesn't count - it was effectively RISC, and way too expensive anyway).

I've been working with eZ80 on Agon Light and the performance ceiling is considerably different. Both the clocks and the instruction timings are more generous owing to a three-stage pipeline, so while interpretation is still slow, and it's got a clear preference for either 8 or 24-bit(in ADL mode), it is now a Z80 that can be applied productively to high-level code operating over 32-bit values...

...except that the BBC BASIC was giving me Heisenbugs, so I had to give up on it. So I'm on Forth now, and immediately found that Forth is a more productive environment than an early BASIC anyway. Linenums add a killer amount of bookkeeping.

Well, yes and no. You're correct that ZX Spectrum is a lot slower than the author estimates, but there's also a software-side performance bottleneck: the code is written in the built-in BASIC language, which on ZX Spectrum, was not only interpreted at runtime, but also almost comically unoptimized. For example, people would use "aftermarket" circle-drawing routines that performed 10x better than the stock ROM implementation.

BASIC on ZX Spectrum was meant for learning, but no serious software of the era relied on it for anything that needed to run fast.

I suspect this code could be 10x faster if written in assembly or a compiled language (a handful existed for the platform).

Yeah, there was a C compiler, a Pascal compiler... I'm pretty sure others. I would guess at least 100x for an optimized assembly version. Even 500x between this sort of interpreter and assembly is not unheard of.

And a BASIC compiler.

https://spectrumcomputing.co.uk/entry/8249/ZX-Spectrum/HiSof...

The manual:

http://hayne.net/Spectrum/HiSoftBASIC/manual.html

HiSoft... that does bring back some memories.

After learning to code on it, we used BASIC as means to write the utilities to load DATA statements representing Assembly code, hexdump monitors or compiled languages, although the later were relatively hard to take advantage of, given the space requirements.

Z80A ;) But hey, it booted instantly. Those were the days.

> A modern CPU would be thousands times faster

And we'll waste all these cycles on JavaScript.