Performance Z280

[Tadeusz Pycio]

On this page I found a simple performance test based on the execution of a BASIC program and a macro for TeraTerm measuring its execution time. I ran some tests and the biggest surprise is the Z280 result. What causes such low performance?

Examples of results:

V20 (x86) @ 10MHz - 126 sec

Z180 @ 9,216MHz - 141 sec

V20 (8080) @ 10MHz  -142 sec

Z80 @ 7,37MHz - 168 sec

Z280 @ 9,216MHz - 175 sec

HD63C09 @ 3MHz - 183 sec

[Bill Shen]

Z280 operating in 8-bit Z80-compatible mode is slower than Z80 with the same clock.  My recollection is that 10mhz z280 in 8-bit mode is similar in performance as 8 mhz z80, whereas 10mhz z280 in 16-bit mode is about 12mhz Z80.  Z280 is spec at 12.5mhz but I routinely run mine at 14.7mhz.

  Bill

[Alan Cox]

On Sat, 4 Feb 2023 at 22:56, Tadeusz Pycio <ta...@wp.pl> wrote:

On this page I found a simple performance test based on the execution of a BASIC program and a macro for TeraTerm measuring its execution time. I ran some tests and the biggest surprise is the Z280 result. What causes such low performance?

BASIC comparisons are useless if the BASIC used is different (which it will be). The 6309 numbers are for example way off in real performance terms and almost certainly a fairly slow Microsoft 6809 BASIC not a 6309 BASIC or a fast one. Likewise the Z180 numbers look like it's a Z80 BASIC or 8080 BASIC not a Z180 BASIC and so on. Most BASIC performance is actually down to a mix of the decode speed and soft float performance which has very little to do with CPU performance. Just compare the Microsoft BASIC and BBC Basic on an RC2014.

Also for the Z280 what cache settings are you using ?

[Tadeusz Pycio]

True, an interperter generally available without optimisation for a specific hardware platform was used ( MBASIC 5.21/CPM-80; MS 6809 EXTENDED BASIC,...) . This situation will be encountered by any user of the hardware in question, as there is little software dedicated to a specific architecture. This is not a typical benchmark showing the advantages of a specific processor, but a real test in a commonly available environment.

No, the Z280's cache memory was not used.

[Steve Crompton]

I for one would be interesting to see who can turn in the fastest time for this test on ANY homebrew retro hardware they have constructed (just for giggles) irrespective of what version of BASIC or CPU they have used

[Alan Cox]

On Sun, 5 Feb 2023 at 11:53, Tadeusz Pycio <ta...@wp.pl> wrote:
>
> True, an interperter generally available without optimisation for a specific hardware platform was used ( MBASIC 5.21/CPM-80; MS 6809 EXTENDED BASIC,...) . This situation will be encountered by any user of the hardware in question, as there is little software dedicated to a specific architecture.

Not really true. MSBASIC was slow and the 8080 one was always 8080
only. There were lots of other BASIC interpreters for the Z80, and
6809 that were far better.

> No, the Z280's cache memory was not used.

That will really hurt your performance. I don't believe the Z280 has
an asynchronous fetch queue the same way the 8088 did. Turning on the
instruction cache ought to improve performance a lot.

Alan

[Tadeusz Pycio]

Sorry, however, the cache on the Z280 was used - RomWBW uses the default value after a reboot. In this case the cache is used to store instructions, no data (CCR=0x20).

[Bill Shen]

I took out my Z280 and RC2014 and run your test.  (As an aside, the TeraTerm macro file is cool, I can't read the file so how did you create it?)

7.37MHz RC2014 running RomWBW's MBASIC is 167 seconds
14.7MHz ZZRCC (Z280 operating in 8-bit Z80-compatible mode) running RomWBW's MBASIC is107 seconds.  So 9.4MHz ZZRCC is same as 7.37MHz Z80 for this particular test
  Bill

[Bill Shen]

I overclocked a W65C02 to 36MHz and ported DOS/65 (CP/M clone for 6502) to it.  Distributed with DOS/65 is a 6502 port of Microsoft BASIC.  So I ran the asciiart benchmark with 6502 version of Microsoft BASIC and it ran in about 10 seconds.

https://groups.google.com/g/retro-comp/c/sS8R8OqAUvA/m/PKdaCHmLAgAJ
  Bill

[Tadeusz Pycio]

I am not the author of this macro, there was a link to this script on the page shown earlier.

[Tadeusz Pycio]

Reading the data sheet for this processor, I do not find the reasons for such low performance. It is possible that the interpreted code is causing such huge overheads in order to flush the cache and pipeline. I have no other explanation.

[Bill Shen]

Z280 is more efficient operating on 16-bit wide bus; it also has many advanced instructions operating on words rather than bytes.  Operating on 8-bit wide bus and executing only Z80 instructions really handicap Z280's performance.  
  Bill

[Wayne Warthen]

IMHO, the script below is significantly better.  It is far simpler and measures elapsed time in milliseconds.  😀

Thanks,

Wayne

uptime StartTime                        ; capture start tick
;
; do something worth measuring...
;
sendln 'RUN'
wait 'OK' 'ok' 'Ok' 'Ready'
;
;
;
uptime EndTime                          ; capture end tick
ElapsedTime = EndTime - StartTime       ; compute elapsed ticks
sprintf2 Message "%ims" ElapsedTime     ; format a string
messagebox Message "Execution Time"     ; display it

[Phillip Stevens]

On Sunday, 5 February 2023 at 22:05:01 UTC+11 Alan Cox wrote:

Most BASIC performance is actually down to a mix of the decode speed and soft float performance which has very little to do with CPU performance. Just compare the Microsoft BASIC and BBC Basic on an RC2014.

I'm fairly certain that it is the token decode logic in Microsoft BASIC that is the reason for its poor performance.

The floating point library (called MBF32 when used in z88dk) is actually pretty speedy. It uses some SMC tricks to get around limitations in 8080 instructions, and is about the same performance as the BBC Basic math library.

And, if the MBF32 library is exchanged for hardware floating point using an APU, the net performance of Microsoft Basic doesn't increase greatly. At various times I've seen it about 15% faster when using the APU, and specific to this benchmark it is about 25% faster. I would expect (based on C compiled benchmarks) hardware floating point using the APU to be about 3x faster than soft floating point on average.

I wish I understood the Microsoft Basic token parse and decode code enough to speed it up.

It would certainly improve benchmark results across a wide range of machines.

Phillip

[Chris Odorjan]

Which interpreter were you using on V20? I did some testing a while back with a similar Mandelbrot demo and found GW-BASIC was much slower clock-for-clock than an 8085 running MBASIC in CP/M. (Although this was a DOS system with DRAM refresh and probably wait states slowing it down.)

Also, what speed is the bus in the Z280 system? (From what I remember it could be set at reset to run at quarter, half, or the same speed as the CPU.)

--

Chris Odorjan

[Bill Shen]

Wayne,
Thanks for the ExecTime.ttl; save it to my TeraTerm utility folder.  I used it to measure ASCIIART benchmark of 36MHz 6502 and the elapse time is 15.9 seconds, not quite as good as I've thought, but at least I now have consistent measurements.
  Bill

[Bill Shen]

Chris,
That's a good point, by default Z280's bus clock is 1/2 CPU clock.  However for ZZRCC, the Z280's bus clock is same as CPU clock (14.7MHz).
  Bill

[Chris Odorjan]

On Sunday, 5 February 2023 at 21:49:41 UTC-5 Bill Shen wrote:

Chris,
That's a good point, by default Z280's bus clock is 1/2 CPU clock.  However for ZZRCC, the Z280's bus clock is same as CPU clock (14.7MHz).

Ah, okay. I see now from another thread that Tadeusz' board is also running with the bus at 1:1 with the CPU.

--

Chris Odorjan

[Tadeusz Pycio]

Which interpreter were you using on V20? I did some testing a while back with a similar Mandelbrot demo and found GW-BASIC was much slower clock-for-clock than an 8085 running MBASIC in CP/M. (Although this was a DOS system with DRAM refresh and probably wait states slowing it down.)

  V20 was tested in a CP/M environment - CP/M-86 and MBASIC 5.22; CP/M 2.2 and MBASIC-80 5.21.

Also, what speed is the bus in the Z280 system? (From what I remember it could be set at reset to run at quarter, half, or the same speed as the CPU.)

The Z280 runs at a bus clocking of 1:1 to the CPU. With a 1:2 split, the test result is 255 sec. for a clock of 9.216MHz. 

[Bill McMullen]

"I for one would be interesting to see who can turn in the fastest time for this test on ANY homebrew retro hardware they have constructed (just for giggles) irrespective of what version of BASIC or CPU they have used"

I ran a few tests on my Min-eZ system (50 MHz eZ80) but since I don't use TeraTerm, the times are the approximate average of several runs using stopwatch:
MBASIC 5.21 ~= 6.8 seconds; BASCOM ~= 3.0 seconds

[Steve Crompton]

That  50 MHz eZ80 is blindingly quick

[Tadeusz Pycio]

I have started to redesign my Z280 processor module already under RCBus taking into account the errors noticed. I decided to return to investigate the performance of this processor. I ran the system on the SCM Z80 bios to exclude RomWBW support overheads. To my surprise, the test took 5 sec longer to execute on the processor's default register values. Disabling the cache memory equalled the results I was getting under RomWBW. My next step will be to set the same wait cycle parameters as in RomWBW (I think I'll gain another 5 sec) and I'll start investigating the effect of cache settings on performance. I think it could be an interesting experience.

[Captain Dunsell]

Keep in mind that this test is subjective because it is writing to the terminal and therefore it is not a proper test of the CPUs ... 

Like for like... the same version of BASIC must be used also ...

Run the test with the following changes:

130 REM

205 Z$ = CHR(48+I)

220 REM

To eliminate nearly all the terminal traffic ...

Paul

[Tadeusz Pycio]

Hi Paul,

Turning off console support did little to improve the results:
Z2...@9.216/ Bus 4.608 RomWBW - 235 sec.
Z2...@9.216 (reset defaults) - 180 sec.

Z2...@9.216 (reset defaults, no cache) - 174.5 sec.

Z2...@9.216 RomWBW - 173.5 sec. (this is the same configuration from the first post where the result was obtained: 175 sec.)

The results suggest that for 8-bit mode you get better performance when the cache is disabled. I need to check this under RomWBW and possibly ask Wayne for a fix for his bios.
As I mentioned earlier, it is likely that the interpreted code forces the processor to time-consumingly clean the cache and, unfortunately, also the pipeline, over which we have no control.