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.

Lesson learned, the biggest improvement besides raw MIPS is a good PPU/GPU.

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 560 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).

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.

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.