Announcement: Cycle-accurate N64 development underway.

[DETOMINE]

Away on vacation, but got CEN64 working on the Google Chromebook (ARM, Samsung Exynos 5250). I don't have EGL acceleration at my fingertips, so I'm using software MESA for now, which is chewing up a large fraction of my runtime.[...]I managed to do this by putting the VR4300 into a "fast forward" mode that only checks a very minimal amount of things when the CPU starts executing a lot of "busy loop" code as it does when it's waiting for interrupts from other devices. I'm thinking that even modest x86 machines (< 3GHz) should see a full 60VI/s on all the ROMs that CEN64 is capable of running as a result... I will test when I get home from vacation.

"Runahead execution", "fast forwarding", SSE optimisation, and still cycle accurate?
Sound like sh*t just got real .

It seems I have lost the track of your progress though, could please remind me (us?) the things that you still need to implement?

[Nintendo Maniac]

Of course... that's a first-day computer architecture 101 topic. However, CEN64 is different in that it basically measures your processor's ability to execute integer and a handful of very, very-predictable branch instructions. The performance differences across architectures will vary much less than a traditional application that results in cache-misses, branch mispredictions, varying kinds of instructions, etc.

If that's true, wouldn't that mean the typically-poor-in-high-end-emulation AMD CPUs could actually be...useful? I mean, in Dolphin the Intel CPUs are quite a ways ahead regardless of clockrate:

Dolphin CPU Benchmark Results

[MarathonMan]

"Runahead execution", "fast forwarding", SSE optimisation, and still cycle accurate?
Sound like sh*t just got real .

It seems I have lost the track of your progress though, could please remind me (us?) the things that you still need to implement?

VR4300 - needs TLB, FPU, some CP0, timings, some instructions, etc.
RSP - needs a handful more instructions, dual-issue logic worked on. Also probably has a bug.
RDP - need to fix RSP/RDP communication issue and begin implementing.

Runahead execution - haven't really started, just looked into it.
SSE optimization - present for ~80% of RSP instructions.
Fast forwarding - done, needs testing on commercial ROMs.
Cycle-accuracy - framework in place, but as hack mentioned, caches aren't modeled and delays aren't present, etc. In other words, it's as easy as adding:

vr4300->pipeline.stalls = 50;

in the VR4300 FPU for instructions that take > 1 cycle, for example. I just haven't actually taken the time to determine the delays of everything and add it in.

I've been trying to "flesh out" everything so that things can drop in place when needed, but keep performance in mind at the same time. If there's some "easy" optimization that will yield enough performance (IMO) to take advantage of without getting in the way or implementing actual functionality too much, I'll generally do it right away. Any x86 machine in the last couple years will get > 30 VI/s, and CEN64 isn't capable of playing commercial ROMs yet, so I'm just putting things like runahead execution on the backburner until they're really needed and instead starting to look at things like the RDP.

If that's true, wouldn't that mean the typically-poor-in-high-end-emulation AMD CPUs could actually be...useful? I mean, in Dolphin the Intel CPUs are quite a ways ahead regardless of clockrate:

Dolphin CPU Benchmark Results

My bet is that Intel will still win out, but the difference between AMD/Intel at the same frequency won't be nearly as exaggerated. The goal is to have ~3GHz or so machines capable of running everything at 60 VI/s, so hopefully these kinds of benchmarks won't even be necessary.