> Please note that even on fast computers this program struggles to simulate the C64 hardware at real speed. A real C64 is simulated at 31% of its speed on an Apple M3 Max, 39% on an AMD Ryzen AI Max+ PRO 495 (Gorgon Halo), and 48% on an Apple M5 Max

Key takeaway is why FPGA is still useful. Even modern CPUs can't handle certain seemingly simple data processing tasks in realtime.

▲

rfgplk 4 hours ago | parent [-]

No, this implementation is just horribly optimized (as usual). Just glancing at the source you could do easy 100x performance improvements with simple fixes.

ie no SIMD/SWAR anywhere; simulating things that literally don't need to be simulated; CPUs are emulated via monstrous instruction flooding cascades with ZERO reordering/speculative execution optimizations (this only improves performance, the underlying emulated program literally can't tell the difference, and with most emulators you'd get a FREE 5-20x improvement); cache trashing everywhere; zero multithreading (as far as I could tell, couldn't bother checking in detail)

▲

tombert 4 hours ago | parent | next [-]

Antirez definitely knows how to write efficient code given that he's the dude who made Redis and many other things, so I'm skeptical that you could "easily" get 100x performance, though it does seem like he used Claude to assist with this so there probably is some low hanging fruit fixes.

	▲	cactusplant7374 4 hours ago \| parent [-]
		I'm working on building a JIT for an emulator and there is no end in sight. Running plenty of experiments though. So I guess that is something. LLMs are not good at building emulators unless they have a reference implementation in the training data.

▲

flohofwoe 3 hours ago | parent | prev | next [-]

> Just glancing at the source you could do easy 100x performance improvements with simple fixes.

Now that you said this you really are expected to do a proof-of-concept implementation that is 100x faster, but with the same low-level concepts ;)

I think 2..3x might be achievable assuming the vibe-coded code quality is really badly optimized, but definitely not 100x.

As far as I understand the simulation, it does the entire address decoding and memory accesses as a transistor-level simulation (which is the whole point!), e.g. everything that happens outside the CPU, CIAs, SID and VIC-II. That means every single memory access has significant overhead because it is essentially simulated from a transitor netlist similar to how visual6502.org simulates the CPU (which even in an optimized C simulation like https://github.com/mist64/perfect6502 is still about 30x slower than a real 6502 at 1 MHz).

PS: Let's do some simple napkin math: the Antirez simulator is 3x slower than a real C64, 100x faster would mean around 30x faster than a real C64, e.g. like a C64 clocked at 30 MHz. That means on a 3 GHz host CPU you would have 100 host clock cycles to emulate a (30Mhz) C64 system clock cycle, and that's for 5 complex chips (CPU + 2xCIA + VICII + SID), so around 20 host clock cycles per emulated cycle for each chip, and that doesn't include address decoding and memory access (which is the expensive part in Antirez's simulator). And moving the chip emulators into threads won't help you much here, because you'd need to synchronise at least once per emulated clock cycle (maybe even twice per emulated clock cycle because of the C64's phi-1 and phi-2 'half cycles').

Good luck with that :) (e.g. squeezing a complete VIC-II clock cycle which renders 8 pixels and may have up to 8 active sprites into 20 host system clock cycles, even with perfect pipelining, SIMD, and no cache misses this isn't a lot of host CPU instructions compared to what a VIC-II needs to do each cycle).

(disclaimer: I'm the author of the pin-based chip emulators used in this experiment)

▲

FrankBooth 2 hours ago | parent | prev | next [-]

How much faster is your C++ Linux kernel?

▲

LocalH 2 hours ago | parent | prev [-]

Other emulators exist that do more for performance. This is more of a simulator.