fignition‎ > ‎

Performance

FIGnition's Firmware 1.0.0 interpreter improves by up to 20% upon version 0.9.8 and before; running at up to 400KIPs and comparable to real, early 80s 8-bit CPUs!

 Benchmark
 Jupiter-Ace (fast mode)
 (FIGnition 1.0.0)
 Ratio  FIGnition KIPS
 BM1  0.16  0.0116  13.7  86.2
 BM2  0.54  0.046  11.7  195.6
 BM3  7.66  0.218  35.1  316.5
 BM4  6.46  0.228  28.3  302.6
 BM5  6.52  0.252  25.8  281.7
 BM6  7.38  0.320  23  246.8
 BM7  12.98  0.660  19.6  180.3
 BM3L  1.0  0.034  29.4  294.1
 BM1F  14.18  0.33  43.0  60.1
     Mean
 25.5  
 Mean (subsets) BM1.. BM7 22.4  BM1.. BM3L  23.3

The Benchmarks are simple adaptations of the original BYTE / Personal Computer World Benchmarks (with an alternative simple floating-point test, but not the transcendental test). The benchmark tests are now attached.

An indication of the graphics performance is given below:

 Benchmark
 Jupiter-Ace (fast mode)
 (FIGnition 0.9.8)
 Ratio  FIGnition KIPS
 Plot Full Screen
 3.02 (2816 pixels)
 0.096  23.3  102.5

I make claims of up to 400 KIPS when none of the benchmarks report that figure. That's because loop itself is relatively slow at only 86.2KIPS (see bm1). Consider bm3L, it executes 9 simple instructions per loop + loop and does this 1000 times. So, the 9000 simple instructions take 0.034-0.0116 = 0.0224s, which is 401.8KIPs. Similarly, bm5-bm4 tells us that we can do 1000 call/returns in 0.024s, which means each call+return takes 24µs (equivalent to a 1.04MHz Z80). Pixel plotting takes 0.096s to do 2400 pixels, and since the loop involves 2 additional simple instructions+loop: the remaining code takes: 2.4*(2*0.025+0.0116) = 0.040s, leaving 0.0562s for plotting 2400 pixels, that's 43KPixels/s (lower than the effective KIPS).

The upshot though is that FIGnition can achieve performances in the same ball-park as real 8-bit micros from the late 70s/early 80s. The challenge is SRAM access, which is terribly slow at 0.9µs/2.7µs (sequential/non-sequential). Against this FIGnition prefetches the next byte while processing the previous one; makes use of internal RAM; performs 16-bit arithmetic as standard and of course, implements much of the functionality (such as displaying text, graphics and memory moves) via its fast internal Flash. As a result a simple instruction execution cycle takes as little as 25 AVR cycles (e.g. for and) which means 9.95MHz is used for the display, leaving 10.05MHz for user-code. In turn, this is equivalent to 10.05/25 = 402KIPs.

Blitter Performance

Since firmware 0.9.8 has been available, FIGnition supports a simple xor-based blitter which can move bitmaps at a rate of roughly 12622 tiles per second (or 252.44 tiles per 50Hz frame). Each move consists of two blit operations (one to erase an old bitmap and the other to blit a new bitmap). Let's compare this with, say a similar xor blitter for a VIC-20 operating with a bitmapped screen, ignoring colour RAM. In the assembly code provided on this page; a VIC-20 requires 50µs/scan + 41µs per extra column. So, a 16x16 pixel (4 tile) sprite requires: 1.641ms giving a simple blit rate of 2437 tiles per second, meaning that 1218tiles can be moved which is about 24.4 tiles per frame; about 10x slower than a FIGnition.

Floating Point Performance

Since 1.0.0, FIGnition has had single precision (32-bit) floating-point support. The underlying performance is in the region of 14.9KFlops.

**(The KIPS calculations for bm2 to bm7 were incorrectly calculated here).
ċ
Benchmarks.fth
(1k)
Julian Skidmore,
14 Jul 2014, 04:31
ċ
Vic20SwSprites.s
(3k)
Julian Skidmore,
4 Mar 2014, 12:12
Comments