3 ms·

Emulating a system of a few 2Mhz with a 4x3Ghz chipset ought to be doable using managed memory.

by hopler 8y ago

flohofwoe 8y ago
Nitpicking a bit, but there's not a lot of useful things that could be multithreaded in an 8-bit emulator, so it would be more like 1x3Ghz ;) In those old 8- and 16-bit machines all components usually ran completely synchronous for each clock tick, for instance if the video emulation runs out of sync with the CPU emulation for a tick or two, a write from the CPU to a video hardware register might not make it in time and you get garbage video output. Modern asynchronous systems may need less (relative) host system performance for emulation, because the timing requirements between the different hardware components are much more relaxed.
- jrockway 8y ago
  The original hardware was multithreaded... in the sense that there were several separate processing units.
  - flohofwoe 8y ago
    Yes, but as far as I can glance from the NES spec, those still run from the same clock (with different dividers, but they're still locked to each other). I haven't written an emulator for the NES yet, but on machines like the Amstrad CPC or C64, the CPU can reprogram video hardware registers (like color palette entries) at any time, for instance in the middle of a scanline. When this is off by a tick, you get the color palette change a couple of pixels late or early. If CPU and video chip emulation would run on different threads, they would need to sync with each other a few million times per second, that doesn't sound like a good idea. If synchronization is only needed once per scanline, or even per frame that's an option of course. Often this is good enough to run some games which didn't go too close to the metal (again this is only from my experience with home computer emulators, haven't done NES stuff yet). Parallelizing through SIMD might be an option though (one can pack a lot of 4- or 8-bit counters into a 512-bit register).
  - boomlinde 8y ago
    Yes, but their emulation needs to be performed in lockstep, normally per clock tick or at least externally visible state change, to accurately model their interaction with respect to timing. Threading in that case would likely mean several orders of magnitude of performance degradation.
TheCoelacanth 8y ago
Except that an explicit goal of the project was to run simulations much faster than real-time to train an AI to play the game, so they still wanted to squeeze the the maximum performance out of the program.

Emulating a system of a few 2Mhz with a 4x3Ghz chipset ought to be doable using managed memory.

by hopler 8y ago

Emulating a system of a few 2Mhz with a 4x3Ghz chipset ought to be doable using managed memory.

Nitpicking a bit, but there's not a lot of useful things that could be multithreaded in an 8-bit emulator, so it would be more like 1x3Ghz ;) In those old 8- and 16-bit machines all components usually ran completely synchronous for each clock tick, for instance if the video emulation runs out of sync with the CPU emulation for a tick or two, a write from the CPU to a video hardware register might not make it in time and you get garbage video output. Modern asynchronous systems may need less (relative) host system performance for emulation, because the timing requirements between the different hardware components are much more relaxed.

jrockway 8y ago
The original hardware was multithreaded... in the sense that there were several separate processing units.
- flohofwoe 8y ago
  Yes, but as far as I can glance from the NES spec, those still run from the same clock (with different dividers, but they're still locked to each other). I haven't written an emulator for the NES yet, but on machines like the Amstrad CPC or C64, the CPU can reprogram video hardware registers (like color palette entries) at any time, for instance in the middle of a scanline. When this is off by a tick, you get the color palette change a couple of pixels late or early. If CPU and video chip emulation would run on different threads, they would need to sync with each other a few million times per second, that doesn't sound like a good idea. If synchronization is only needed once per scanline, or even per frame that's an option of course. Often this is good enough to run some games which didn't go too close to the metal (again this is only from my experience with home computer emulators, haven't done NES stuff yet). Parallelizing through SIMD might be an option though (one can pack a lot of 4- or 8-bit counters into a 512-bit register).
- boomlinde 8y ago
  Yes, but their emulation needs to be performed in lockstep, normally per clock tick or at least externally visible state change, to accurately model their interaction with respect to timing. Threading in that case would likely mean several orders of magnitude of performance degradation.

TheCoelacanth 8y ago

Except that an explicit goal of the project was to run simulations much faster than real-time to train an AI to play the game, so they still wanted to squeeze the the maximum performance out of the program.