fignition‎ > ‎

Performance

FIGnition's Firmware 0.9.9 interpreter improves by up to 20% upon previous versions running at up to 400KIPs, comparable to real, early 80s 8-bit CPUs!

 Benchmark
 Jupiter-Ace (fast mode)
 FIGnition (0.9.8)
 Ratio  FIGnition KIPS**
 (Firmware 0.9.9)
 Ratio  FIGnition KIPS
 BM1  0.16  0.014  11.42  74  0.0116  13.7  86.2
 BM2  0.54  0.056  9.64  161  0.046  11.7  195.6
 BM3  7.66  0.286  26.7  241  0.218  35.1  316.5
 BM4  6.46  0.298  21.7  232  0.228  28.3  302.6
 BM5  6.52  0.326  20  218  0.252  25.8  281.7
 BM6  7.38  0.402  18.4  197  0.320  23  246.8
 BM7  12.98  0.836 15.5
 142  0.660  19.6  180.3
 BM3L  1.0  0.04  25  250  0.034  29.4  294.1
     Mean 18.55
   Mean
 23.3  
 
 (w/o BM3L)
 17.62    (w/o BM3L)
 22.4  

The Benchmarks are simple adaptations of the original BYTE / Personal Computer World Benchmarks (with the exception of the floating point tests). The benchmark tests are now attached.

An indication of the graphics performance is given below:

 Benchmark
 Jupiter-Ace (fast mode)
 FIGnition  Ratio  FIGnition KIPS
 (Firmware 0.9.8)
 Ratio  FIGnition KIPS
 Plot Full Screen
 3.02 (2816 pixels)
 0.11(2400 pixels)
 22.98  88  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 10.7MHz is used for the display, leaving 9.3MHz for user-code.

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.

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