mirror of https://github.com/bsnes-emu/bsnes.git
Address the idea of multithreading.
This commit is contained in:
parent
45c8f09330
commit
1faa263a4a
62
docs/faq.md
62
docs/faq.md
|
@ -215,3 +215,65 @@ how the original console worked,
|
||||||
and it requires the emulator authors to diagnose and work around
|
and it requires the emulator authors to diagnose and work around
|
||||||
each individual supported game,
|
each individual supported game,
|
||||||
instead of having one emulator that works for everything.
|
instead of having one emulator that works for everything.
|
||||||
|
|
||||||
|
Why can't higan use multiple CPU cores?
|
||||||
|
---------------------------------------
|
||||||
|
|
||||||
|
These days,
|
||||||
|
most computers contain multiple CPU cores,
|
||||||
|
allowing them to run different programs,
|
||||||
|
or different parts of the same program
|
||||||
|
at the same time.
|
||||||
|
Since higan requires high CPU performance,
|
||||||
|
sometimes people suggest that it should split its work
|
||||||
|
into multiple threads
|
||||||
|
so it can run across multiple cores
|
||||||
|
instead of stressing one core while the others lie idle.
|
||||||
|
After all,
|
||||||
|
the original consoles higan emulates
|
||||||
|
had separate devices running independently,
|
||||||
|
so why not run each emulated device in a separate thread?
|
||||||
|
|
||||||
|
The big problem with this approach is timing.
|
||||||
|
The devices in a physical Super Famicom (for example)
|
||||||
|
run at whatever speed they run at,
|
||||||
|
and talk to each other whenever they feel like.
|
||||||
|
Because every Super Famicom uses the exact same components,
|
||||||
|
every Super Famicom runs compatible games at the exact same speed,
|
||||||
|
and games can blindly assume that
|
||||||
|
when operation X is complete on device A,
|
||||||
|
device B will have finished operation Y
|
||||||
|
and be ready to do something new.
|
||||||
|
Meanwhile, higan's emulated components
|
||||||
|
take an unpredictable amount of time to do their work,
|
||||||
|
so without deliberate synchronization
|
||||||
|
things would break almost immediately.
|
||||||
|
|
||||||
|
It's not practical to make higan's emulated devices
|
||||||
|
do their work in exactly the same amount of time
|
||||||
|
as their hardware counterparts.
|
||||||
|
The problem is forty years of technology
|
||||||
|
designed to make programs run as fast as possible:
|
||||||
|
optimizing compilers and superscalar, out-of-order CPU architectures
|
||||||
|
change programs to make them faster,
|
||||||
|
speeding up some programs more than others
|
||||||
|
in ways that are very difficult to understand and predict.
|
||||||
|
Even if higan's emulated devices
|
||||||
|
ran at the exact, correct speed
|
||||||
|
on one particular computer,
|
||||||
|
they'd still run differently on any other computer,
|
||||||
|
or with a smarter compiler,
|
||||||
|
or with a smarter CPU.
|
||||||
|
|
||||||
|
Since higan needs its emulated components
|
||||||
|
to run at particular speeds,
|
||||||
|
and they won't run at those speeds naturally,
|
||||||
|
it must force them manually.
|
||||||
|
An emulated device runs for a little while,
|
||||||
|
then all the others are run until they catch up.
|
||||||
|
It's this careful management,
|
||||||
|
regular stopping and starting,
|
||||||
|
that makes higan slow,
|
||||||
|
not the actual emulation of each device,
|
||||||
|
and so it doesn't make sense
|
||||||
|
for higan to be multi-threaded.
|
||||||
|
|
Loading…
Reference in New Issue