Legend:

• Green: The SD-8516 is capable of emulating this level of performance on an i7-12700 (Geekbench 6 baseline).
• Light Green: Capable, but only with extensive use of the PPU and APU.
• Light Gray: The SD-8516 cannot reach this level of performance, but can reach at least 60%, so ports are possible but may be heavily constrained. Optimization in Assembly may be required.
• Dark Gray: The SD-8516 cannot emulate this system. This is almost always because it is designed as a single threaded system with no 3D acceleration. As an emulator, modern computers can often run emulated systems at near-native speeds. But even if we pass-through the GPU via SDL2 we are unlikely to be able to emulate this class of system because we don't have multi-threading. Given time it is likely computers will continue to increase in speed and we will be able to emulate these systems performance; if I ever add the ability to multitask, these limitations will almost certainly disappear.

Looking at the above chart, you will see “what happened”. In the early 90s, the 486dx-66 was the last great consumer CPU before the 3d revolution really took off. The death of the Amiga, the rise of the accelerated playstation and the absolute dominance of the Pentium changed how home computing worked. After that moment, graphics acceleration was a must and MIPS did not matter anymore. Thus, the PS-1, even though it is only 30 mips, had enough graphics acceleration to do things a similarly priced PC of the day could not.

The original Pentium (P5, 1993–1997) provided several key architectural accelerations that Quake's software renderer exploited via hand-tuned x86 assembly (primarily by Michael Abrash), delivering ~2–3x the performance of a 486DX4-100 in rasterization-heavy scenes.

The Pentium was really the key that launched the GPU acceleration wars.

• Superscalar dual integer pipelines (U/V): Allowed two integer instructions per cycle, allowing quake to draw pixels in bursts
• Pipelined FPU: pipelined floating point ops let Quake fire FDIV for perspective-correct texturing in parallel with integer rasterization (r_alias.s), making slow DIV “free” (~1c effective).
• 64-bit FPU data path: Enabled fast 64-bit FP loads/stores and near-free FXCH (stack rotates, 0-1c), optimizing matrix/dot products for geometry and lighting
• Branch prediction: predicted branches (e.g., bottom-of-loop) increased throughput.

These Pentium-specific traits were exploited via Abrash's hand-tuned ASM (id386.asm) delivered a 3x speedup over 486DX4-100 and AMD/Cyrix 5×86-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.

Taken on an i7-12700k, a basic “unrolled LDA” 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.

The following program illustrates the problem with MIPS:

.address $000100

    LDCD $0FFFFFFF        ; choose a number to make the test take ~10 seconds

loop:
    DEC CD                ; Decrement CD
    JNZ @loop             ; Jump to loop if CD != 0

    HALT                  ; Halt when done

• WASM version 55 MIPS.
• C version was 550 MIPS.

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.

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.