> IMO, a SNES emulator requiring 3GHz means brain-dead implementation, simple as that
No, it means accurate implementation. That doesn't mean accurate gameplay (which many inaccurate emulators achieve), but proper accurate emulation. You should really, really read up on byuu's work; he's probably the best developer in emulation at this point.
Even for accurate SNES emulation implementation, 3GHz (on 3 way OooE CPU with massive SIMD capabilities -e.g. Core2Duo, Core iX, or modern AMD-), is crazy. BTW, my evaluation was based on his article, not on his reputation.
No, it's not crazy at all. There's a massive amount of synchronization that has to be done between, say, the CPU and PPU. It's not possible to even do per-pixel synchronization right now, which is why line-based sync is in use. Have you read the source? The implementation is brilliant, even if it is "slow".
My current builds do perform per-pixel synchronization of the CPU and PPU. It cuts the speed in half compared to scanline-based, and even that is only because I run the chips out-of-order until synchronization is absolutely required.
Per-pixel synchronization makes sense on systems writing pixels directly to the CRT, like the case of Atari 2600, which has no framebuffer at all, and required accurate CPU timing for writing to the DAC (Atari 2600 TIA).
In case of the SNES, or any tile-based 8 and 16 bit console, IMO, the only accurate synchronization required is per-line (HSYNC) and per-frame (VSYNC), in most cases. If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written (complex multiprocessors systems with CPUs, coprocessors, DMA, rely on interrupts for synchronization, although some per-cycle heterogeneous memory access thing was used as anti-copy protection, timer handling, etc.).
> If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written
That's the whole point. There are games that did crazy stuff, and don't work well on many emulators. Perfect emulation requires software simulation of these crazy exploitations of the hardware.
Yes, but 3GHz of a modern OooE CPU (with at least 3 instruction per clock, capable of massive SIMD)? Come on. Also, from desktop snapshot, in task manager it showed 4 CPUs, with 3 of them at almost 100% (!). It reminds me the comparison between Git and Monotone made by Linus Torvalds. I find no reason in the Earth for perfect SNES emulation with just one core of a modern OooE CPU and 1-1.5GHz (with GPU assistance for stretch and filtering/postprocess), even written in C, with no SIMD assembly at all (SNES 65816 CPU was running at maximum speed of 3.58 MHz, being its coprocessors even slower).
> Also, from desktop snapshot, in task manager it showed 4 CPUs, with 3 of them at almost 100%
The Ars Technica image guy made that screenshot. It wasn't from running my emulator, which is strictly single-core (for a whole host of reasons I won't get into.)
Your guess is as good as mine why he chose that screenshot, I didn't know about it until after the article was published.
Thank you for the answer, byuu. Don't get me wrong, your emulator is great, and I apreciate very much your commitment with open source. I simply pointed about the Nesticle patches were not necessary for speeding up the emulation, and that 3GHz was overkill, in my opinion. I bet in the future it will be much faster, no mater if is optimized by yourself o by others (I understand that may be optimization is not your goal, my point is just that the 3GHz is not a requirement just because precission, but because of current implementation). Best regards, and please, excuse me for telling you "idiot" in a previous post, change it by "innacurate" (Nesticle thing) and "incomplete" (3GHz required not only because accuracy, but also because current implementation limitations).
> If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written
I agree, and there were several such games released for the SNES. Would you rather those poorly written games never be playable under emulation? Because until now, they weren't playable. And now they are on moderate PC desktops. And personally, I don't think the extra emulator overhead will matter in 20 years when our cell phones have ten times the power needed for it.
No, it means accurate implementation. That doesn't mean accurate gameplay (which many inaccurate emulators achieve), but proper accurate emulation. You should really, really read up on byuu's work; he's probably the best developer in emulation at this point.