7

If you look at the results of the Rugg/Feldman benchmarks, shown in this Wiki entry, you'll see that Sinclair ZX80 is much faster than Sinclair Spectrum on all tests despite the fact that both computers use the same CPU. Why is that?

Improve this question

1 Answer 1

Reset to default
8

[...] Sinclair ZX80 is much faster than Sinclair Spectrum on all tests despite the fact that both computers use the same CPU.

It's not about the CPU, but because these are vastly different BASIC implementations. In this case it's due to integer vs. floating point maths.

The fact is marked in the ZX80 entry by noting 'integer only'. The numbers shown are for the original, not upgraded ZX80 with its 4 KiB integer-only BASIC, not be confused with the 'backported' 8 KiB ZX81 BASIC. Having the upgrade installed, the numbers should be quite in line with the Spectrum readings.

A similar difference is shown in the Apple II entries for Integer BASIC vs. Applesoft.

Improve this answer
9
  • 1
    This is the major factor, obviously, but I also wonder whether the Z80 in the Spectrum is actually managing to go even as fast as that in the ZX80 when dealing with the sort of tiny BASIC programs that comprise the benchmark. It always starts BASIC storage in the contended area regardless of whether 48kb is available, so programs that should will mean that every RAM access is contended. Conversely the ZX80 doesn't even paint a display while running BASIC. So it could be not just that the Spectrum is doing a lot more, but that it's running more slowly while it does.
    – Tommy
    Oct 2, 2019 at 20:26
  • 1
    The ZX80 doesn’t have SLOW mode or a FAST mode — those are the ZX81 — and the Spectrum will be blocked by the video every time it fetches a BASIC statement or mutates a temporary value (e.g. during calculation of a multiplication).
    – Tommy
    Oct 2, 2019 at 20:47
  • 1
    Okay, so we have different concepts of how often the ROM would access RAM during execution of BASIC programs like those given, that's all. It might be interesting to profile but, regardless, thanks as ever for the reasoned argument — I've nothing on my side except instinct so I could easily be way off.
    – Tommy
    Oct 3, 2019 at 1:43
  • 1
    @Tommy Oh, I really understand that. It hits everyone. We always overestimate the 'useful' work done by microprocessors in comparison to bookkeeping. The Z80 with it's high cycle numbers per instructions is even worse. But it's possible to check limits without looking into code The worst (common) memory accessing instruction may be some 16 bit load (LD DE,(x)) it takes 20 cycles (unhindered), issueing two memory access. That would be a maximum of 2x5 cy wait. So the absolute maximum slow down is 30:20=33%. No program is just 16 bit loads...
    – Raffzahn
    Oct 3, 2019 at 12:41
  • 2
    @Tommy By inserting a simple INC HL (common here) with 13 cy, it gets down to 43:33=23%. In Reality, even the most memory hungry routine will need 3-4 instructions per (data) memory access, kicking the slow down way into the lower 1 digit region. I'm pretty sure that the main loop will have a single load followed by many CP/JP, turning the rational close to zero. Now, all of this is worst case, assuming always being delayed and always delayed by the maximum 5 cy. In reality this will be way less --- I pushed my head quite often against the wall of unwanted cycles and it hurts every time
    – Raffzahn
    Oct 3, 2019 at 12:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .