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||v1 Amiga 500 PAL||v1 Amiga 500 PAL fast RAM||v1 Amiga 1200 PAL||v1 Amiga 1200 PAL fast RAM|
|zoom out pc||1.47||1.34||1.48||1.27||3.17||13.62||5.51||5.60||11.21||20.82|
|zoom in pc||1.72||1.57||2.00||1.49||3.58||14.87||6.63||6.77||12.92||23.88|
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.4 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 the 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 K1801VM1:z80 speed ratio is close to 1 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 50% faster than the z80 and about 2 times slower than the 6502 at the same frequency.
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 2.9 - it is surprising that the 68020 was so slow. The 68020 is so slow because the stock A1200 doesn't have fast RAM. If the A1200 uses fast RAM it becomes about 95% faster making the 80286:68020 speed ratio close to 1.5 – it is not much surprising.
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.
|the stock A1200||the A1200 with|
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.
All results have been gotten from emulators (plus4emu, ep128emu, BK2010, pce, pcem, fs-uae). The pattern is available for the download 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.
|Port||CPU||Code Size||Program Size||'Generate' Size|
|Commodore +4, v5||6502||14486||60062||2506|
|Amstrad CPC6128, v5||Z80||15326||48345||2060|
|Элeктpoникa БK-0011, v3||T-11||14420||48722||2484|
|IBM PC, v2||8088||12942||63517||1994|
|Commodore Amiga, v1||68000||20690||118516||2080|
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.
|zoom out pc||≈55100||≈1140||≈330||396.83|
|zoom in pc||≈54500||≈3510||≈1100||462.96|
Xlife v7, in hash algorithm mode, can show virtally almost any superfast speed, for instance more than billions of billion...
The main Xlife-8 page