I have a tendency to write in an accusatory manner, so you'll have to excuse me on that, but I'm taking both sides here.
At once, I have a border line OCD tendency to write "correct" code, so that it does what it's supposed to do in the most correct fashion (it works against me a lot) and then go about optimizing it. Each processor in the SNES being a separate thread certainly seems to be the most correct way to emulate the system, but I wasn't aware of the huge problem of thread synchronization (I read the other thread about save states).
Tthere are still the "classic" emulators, ZSNES and Snes9x, both of which
are already incredibly fast. Like someone else said, you've got a choice. There's no point writing another ZSNES/Snes9x, because they're already there. I haven't looked at the BSNES code but if he optimized as aggressively as some suggest, he might as well drop the project. It has a different goal, so let it be.
On the other hand, I also have a huge tendency to want code to be fast, no matter the application, and violated my own principles at my last job due to the fact that they didn't care about speed nearly at all. Stuff like:
Code: Select all
int a = 0;
a += 10;
for(int i; i < a; i++)
should certainly be changed, but I'm assuming the optimizations in BSNES aren't on the order of that kind of silliness. Besides, there are other kinds of optimizations: BSNES should scale well on multi-core processors. That said, the thing is pretty slow even given modern processors. PCSX2, an emulator for a much more powerful machine, can run nearly full speed on top of the line PCs. I was looking at task manager and watching none of my 4 cores top out above maybe 25% usage, and still the emulation was slow.