Xlife-8 benchmark results

This pattern was designed to test the speed of 8 bit version of XLife program, its size is 126x108. The pattern should be placed at coordinates (1,1) to get the same results. The next table shows the speed in generations per second for different screen modes (pc means pseudocolor mode).

	v5 Commodore +4 PAL	v5 Commodore +4 NTSC	v5 Amstrad CPC6128	v3 Элeктpoникa БK-0011	v2 IBM PC-5150 CGA	v2 IBM PC AT @6MHz CGA	v2 IBM PC AT @6MHz 0WS CGA	v1 Amiga 500 PAL	v1 Amiga 500 PAL fast RAM	v1 Amiga 1200 PAL	v1 Amiga 1200 PAL fast RAM
blank	2.85	2.88	2.34	1.44	3.68	9.01	13.55	7.40	7.55	14.02	27.20
zoom out	1.65	1.50	1.77	1.30	3.35	7.87	11.74	6.94	7.07	13.47	25.48
zoom out pc	1.47	1.34	1.48	1.08	2.97	6.95	10.42	5.51	5.60	11.21	20.82
zoom in	1.78	1.61	2.04	1.33	3.36	8.10	12.09	6.76	6.92	13.12	24.46
zoom in pc	1.72	1.57	2.00	1.29	3.32	7.89	11.47	6.63	6.77	12.92	23.88

The calculations are 8-bit. They intensively use bitwise instructions and lookup tables. The 68k and PDP-11 processors are not good for such computations.

The Commodore +4 has the 6502 CPU running at 0.89-1.7 MHz without wait states. The average frequency of this CPU with the standard screen mode is about 1.11 MHz (PAL) or 1.01 MHz (NTSC).

The Amstrad CPC 6128 has the z80 CPU running at 4 MHz. Wait states make the actual frequency close to 3.19 MHz.

The Elektronika BK0011 has the K1801VM1 (the PDP-11 architecture) 16-bit CPU running at 4 MHz. RAM access wait states eat about 40% of the CPU power. So the actual frequency is close to 2.3 MHz.

These results demonstrate that the +4's CPU in the standard screen mode at 1.11 MHz is slower than the CPC's at 3.19 MHz but +4's video is faster. The BK0011 demonstrates the fast 16-bit video but its CPU is slow to work with 8-bit data. The BK0011 may show the best results at 160x192 mode with very big patterns.

The final 6502:z80 speed ratio with equal frequencies and no wait states is close to 2.3 to 1.

The results for the z80:K1801VM1 speed ratio is close to 1.2 to 1.

The first IBM PC used the 8088 CPU at 4.77 MHz. The results show that it is not too fast. It is only about slightly faster than the z80 and about 2.2 times slower than the 6502 at the same frequency. The first IBM PC AT uses the 80286 at 6 MHz, it uses 2 wait states when a memory access occurs and this slows down the CPU quite much. If we want to get the true 80286 speed we need to use memory without wait states.

The Commodore Amiga 500 uses the 68000 CPU at 7.09 MHz (PAL) or 7.16 MHz (NTSC). The results show that the 68000 is approximately 1.2 faster than the 8088 at the same frequency. The 80286:68020 speed ratio is shown equal approximately to 1.2 – it is not much surprising for byte computations.

The next table contains approximate values of efficiency reciprocals (ER). These values are calculated by multiplication of the time of the calculation of 100 generations in screen blank mode by the effective CPU frequency. The ER value reflects the efficiency of a CPU electronics, it gives the reciprocal of the CPU performance at 1 MHz.

It can be interesting to compare Xlife-8 performance with the performance of other programs. AXlife v1.2 is a port of Xlife v2.0 for the Amiga. It uses 1x magnification instead of zoom out mode, and 16x magnification instead of zoom in mode. AXlife, like Xlife v2.0, doesn't support pseudocolor mode.

AXlife shows performance about 10% faster than Xlife-8 for the Amiga when visualization is disabled – it is rather because of larger lookup tables used in AXLife. However AXlife uses slow system functions for dot drawing which makes AXlife much slower than Xlife-8 when the generation is visualized.

Emulators were used to get all these results.

The pattern is available for downloads here.

All ports of Xlife-8 share the same algorithm implementations. Some variety is only imposed by the difference in graphic hardware and io systems. The next table contains sizes of executable code for all Xlife-8 implementations. This is exactly total sizes of all instructions. This table may be used as an illustration for code density for different CPU. This code mostly does manipulations with 8-bit data.

Program sizes can't be use for code density measurements because the Amiga and IBM PC use larger universes for cells, programs can have "holes", etc. The 8086 shows an excellent code density while the 68000 shows a rather poor result for this 8-bit processing code. This inferior result for the 68000 is caused partially by larger code for text printing. A more objective result may be given by comparison of sizes of the same subroutine. So sizes of key subroutines `generate' are provided too. However due to BCD arithmetic used in the DEC T11 code for this procedure, the code for the PDP-11 is unexpectedly large.

It may be interesting to check the speed of one modern system with this pattern. I used the AMD Phenom(tm) II X4 955 @3.2GHz based PC to get the next results. Xlife uses 4x magnification instead of zoom out mode, and 64x magnification instead of zoom in mode.

Xlife v7, in the hash algorithm mode, can show virtally almost any superfast speed, for instance more than billions of billion...

The main Xlife-8 page