Differences

This shows you the differences between two versions of the page.

--- sd:emulation_benchmarks [2026/05/16 00:01] – appledog
+++ sd:emulation_benchmarks [2026/05/16 00:24] (current) – appledog
@@ Line 46: / Line 46: @@
 These Pentium-specific traits were exploited via Abrash's hand-tuned ASM (id386.asm) delivered a 3x speedup over 486DX4-100 and AMD/Cyrix 5x86-133 style CPUs, crushing the clones' weaker floating point pipelining and marginalizing them in gaming. Pentium began to dominate the 1996 PC market as Quake's "minimum viable" software 3D benchmark, shifting devs from CPU raster hacks to hardware offload. Next, GLQuake/Voodoo (1996) hit 60+ FPS by rasterizing on GPUs, birthing the 3D acceleration era.
-//Lesson learned, the biggest improvement besides raw MIPS is a good PPU/GPU.//
 == Profiling Experiments
-Here are the results of tight-loop experiments featuring benchmarks of one instruction. They are intended as relative results only. Taken on an i7-12700k.
+Taken on an i7-12700k, a basic loop example executes at 55 MIPS in the WASM version and at 550 MIPS in the C version. However, there's an issue if we go beyond this relative benchmark.
-The basic "unrolled LDA $1000" example executes at 95 MIPS in the WASM version and at 675 MIPS in the C version. However, there's an issue if we go beyond this relative benchmark.
 === MIPS isn't useful
-The following program illustrates a baseline:
+The following program illustrates the problem with MIPS:
 <codify armasm>
@@ Line 70: / Line 66: @@
 * WASM version 55 MIPS.
-* C version was 560 MIPS.
+* C version was 550 MIPS.
-But here's the problem with MIPS. LSTEP, a command that does DEC CD and JNZ in one step, performs at 360 MIPS (in the C version). This shows that MIPS is somewhat deceptive as a measurement. The LSTEP command is performing the work of both DEC and JNZ in less time than each; but since it is a relatively slow command in and of itself it lowers the MIPS of the system as a whole. In reality if it was counted as two instructions it would show over ~700 MIPS. If we use a dual stage LSTEP (on two 16 bit registers) it runs in 470 MIPS (940 mips equivalent).
+The issue occurs when we try to replace the DEC/JNZ pair with LSTEP, a command that does DEC CD and JNZ in a single step. Using LSTEP seems to lower performance to 360 MIPS (in the C version). Why? The LSTEP command is performing the work of both DEC and JNZ, but since it is a relatively slow instruction it lowers the MIPS of the system as a whole. Yet it is still faster overall to use LSTEP than DEC/JNZ. If LSTEP was counted as two instuctions it would show over ~700 MIPS compared to DEC/JNZ's 550.
+Another example, I had benchmarked kernal 0.7.2 at 750 MIPS, then I switched kernals to from 0.7.2 to 0.8.3. This had the effect of putting CASETAB into the hot path. So instead of performing hundreds of JZ and CMP instructions in the INT $10 jumptable, it performed one CASETAB. MIPS dropped to 500 but the system ran twice as fast. That's the real takeaway; despite having a lower number of MIPS, the system runs measurably faster.
 === Conclusion: CISC vs RISC
-Time spent on the hot path is slow, while time spent in the hot path is fast. That is, just like the WASM version, the C version does best with CISC instructions. MIPS itself, is not as important as it seems. What matters is the quality of the instruction set; even at 1 MIPS, the WASM version can handle over 2,000 sprites per frame at 60fps, utterly destroying even the SNK Neo Geo (1990) in terms of arcade performance.
+Time spent on the hot path is slow, while time spent in the hot path is fast. That is, just like the WASM version, the C version does best with CISC instructions. MIPS itself, is not as important as it seems. What matters most is the quality of the instruction set.
-//Using a RISC-like ISA is only a requirement if you are emulating a particular architecture. It is not a good idea for a fantasy computer in general. A fantasy computer does better with CISC instructions.//
-A final example; I had benchmarked kernal 0.7.2 at 750 MIPS, then I switched kernals to from 0.7.2 to 0.8.3. This had the effect of putting CASETAB into the hot path. This meant that instead of performing hundreds of JZ and CMP instructions per system loop, we performed one CASETAB. MIPS dropped to 500. But the system is running much faster! As it turns out, 10 seconds at 750 MIPS is slower than 5 seconds at 500 mips. That's the real takeaway; despite having a lower number of MIPS, the system runs measurably faster.