Optimizations

[eivindbohler]

This PR aims to optimize the emulator, look at specific commits for details.

The emulator seems to be producing identical sound as the one compiled from the master branch at the time of writing, using the mkII ROM set.

I am however curious to see if there are any issues when using any of the other ROM sets - or if there's anything I've overlooked. The two last commits (1e2f6cb and 2004cd6) specifically could potentially cause issues and should be properly tested.

Update: Rebased against the current master (as of April 20). I removed the aggressive interrupt removals for better compatibility.

[giulioz]

I'm curious how faster does this goes? Is there a profilable difference?

[eivindbohler]

I'm curious how faster does this goes? Is there a profilable difference?

For me, yes definitely. From 39-41% utilization (unix-style, ie., 100% is one core) on my M1 MBP to 26-28%. On a Raspberry Pi 4 at stock clock speed (1.8GHz) it seems to be running its work thread happily at around 85-90% (+ a few percent on other threads) whereas it was unusable before these modifications.

[giulioz]

I'm trying to profile it but after those changes the demo songs don't play anymore, investigating…

[giulioz]

The problem is with remove unused interrupt checks. Apparently they are used for playing the demo songs

[giulioz]

@eivindbohler the JV-880 doesn't boot anymore with the disabled interrupts, even after your fix :( I know that that change gives a small performance boost, but maybe for compatibility with different firmwares it's better to not cripple the cpu like that

[eivindbohler]

@eivindbohler the JV-880 doesn't boot anymore with the disabled interrupts, even after your fix :( I know that that change gives a small performance boost, but maybe for compatibility with different firmwares it's better to not cripple the cpu like that

Yeah, I feared as much. I'll take a look and see if there are specific interrupts used. Enabling them all pushes the CPU usage on the stock clocked Pi4 up to mid-90s, which is uncomfortably close to where I'd like to draw the line! :)

[eivindbohler]

I re-enabled all the interrupt checks and calls in mcu_timer.cpp. Getting identical results with the JV-880 rom set as the emulator compiled from master now.

Taking a step back, I'm starting to get the feeling that it should be possible to squeeze a bit more performance out of this by going away from dynamic rom set checks and rather do separate compiles for different synth/rom set versions. It might seem impractical, but there are lots of very tight and frequent loops where every bit of branching negatively impacts performance.

If nothing else, I'd like to explore the thought of making a separate cmake build specifically for the Raspberry Pi 4 and sc-55 mkII with all possible optimizations put in place. I'll leave that for another PR if it comes to that, and let @nukeykt decide if he wants to incorporate this PR (or parts of it) into the main branch. Thx!

[giulioz]

Taking a step back, I'm starting to get the feeling that it should be possible to squeeze a bit more performance out of this by going away from dynamic rom set checks and rather do separate compiles for different synth/rom set versions. It might seem impractical, but there are lots of very tight and frequent loops where every bit of branching negatively impacts performance.

Or… using template for functions to generate different versions at compile time, so that you still end up with a single executable

[eivindbohler]

Or… using template for functions to generate different versions at compile time, so that you still end up with a single executable

I'd still need to write separate functions though, to avoid runtime type checking?

Edit: hmmm... reading about if constexpr.. Lots of things have happened since last I dove into C++ it seems! 😄

[nikitalita]

Are you still working on this? The fork seems to be deleted. If not, I'm interested in rebasing the non-interrupt changes on top of current master.

[eivindbohler]

First, I'm not sure how well these changes will blend into the current master, seeing as there've been lots of commits since then. I spent many days carefully profiling, identifying hotspots and optimizing the code as to be able to run it smoothly on a Raspberry Pi 4, which went very well. However, this PR was never addressed by the repo author, and on Vogons I was shut down by what I considered grumpy comments about how we shouldn't run the emulator on a Pi. That kinda killed my interest of this project altogether, and I cancelled my PR and deleted the fork. I did some additional optimizations using template functions, and kept these privately for my own enjoyment. Hopefully this emulator will be re-licensed and integrated into all the other wonderful open source projects longing for it one day. In the mean time, please feel free to cherry-pick whatever you want from this PR and use it however you want! :)

[nikitalita]

I'm sorry to hear that you had that experience. Oftentimes VOGONS has some pretty negative discussion and bad vibes, and I tend to stay away from there.

It was very short-sighted of them to say that you shouldn't run this on a Raspi4. For example, there is a Waveblaster card with a CM4 integrated, which is possibly one of the BEST use cases for this emulator, and perfect justification for these sorts of optimizations.

I understand wanting to not work on this anymore; I will probably take a crack at cherry picking some of these changes and rebasing them.

If you still have them and are willing, could you please upload the template function changes somewhere? I can try and rebase them as well.

[nukeykt]

please do not use Nuked-SC55 in a public projects that aim to turn it into physical synth. That's mostly because hardware costs money, and I absolutely do not want anyone monetizing project, even in indirect way.

Also, I'm sorry if I may sounded rude on vogons thread, I didn't want to hurt anyone, just wanted to make clean my position about this.

[eivindbohler]

Thanks, @nukeykt - I appreciate that!

I too don't want to be rude or insensitive, but I'll try one more time to convince you why I think you're wrong about the choice of license. Again, please don't be offended just because I'm a quarrelsome nitpicker. Ok, here goes:

You say (I'm slightly paraphrasing) you don't want public projects that aim to turn the emulator into a physical synth. My response to that is you've already done that yourself - by making everyone's Windows computer act as a hardware synth. That's what hardware emulation is. I'm thinking 99.9% of people interested in this emulator is going to want to use it purely for playing DOS games. Why does it matter if the computer they're using to run the emulator on is a big box or a small box? Threadripper monster computer or tiny and affordable Raspberry Pi? Desktop or companion board to a MiSTer? One could argue that everyone using the emulator is monetizing the project indirectly, because it saves them the cost of buying the old and discontinued hardware. That goes for all retro computing emulators, btw.

I suspect that if there existed a software license that would permit your emulator being used only in conjunction with other GPL-licensed open source hobby projects - but not to make fake black boxes that looks like the real hardware - you'd be willing to switch? I'd argue that this last scenario is already covered by trademark infringement laws. I guess the point I'm trying to make is that nobody think it's your responsibility to stop anyone from making and selling a counterfeit hardware device. And as it was pointed out in the Vogons thread, those that would be that unscrupulous would hardly be stopped by a non-commercial software license anyway. In any case, since you're not distributing the ROMs necessary for the emulator to work, I simply fail to see the harm in properly opening the emulator up to the community.

You don't have to answer this rant if you don't want to - I'm not interested in fighting or arguing my points further. I totally respect your opinions and your rights to your opinions, whether I personally agree with them or not. As I've said previously, I don't think I'll be contributing further to this project as it currently stands. I will, however, continue to use it privately for my own enjoyment, and for that I am still very thankful, and grateful of what you've accomplished! :)

@nikitalita: The work on template functions was mostly done to squeeze a further couple of percents of reduced CPU usage out of it, but it did clutter up the code somewhat. I think I'll refrain from posting this. My tip is to wait for the work being done in the "Remove global state" PR to be merged before attempting to integrate any of my changes.

[nukeykt]

As mentioned in #13 I will likely relicense my work to more permissive license evetually, be it when nuked-sc55 popularaity peak is reached or when other emulators (emusc or MAME) reach my emulator's fidelety level

[eivindbohler]

Thank you, that is very encouraging to hear! I'll keep my fingers crossed! ;)