Hmm. Bit of a problem with the emulator, it would seem - after all the work I've put in to tidy-up the interfaces and object structures, improve the MemoryMap class with indexers instead of bespoke methods, get the CPUCore class nicely thread-safe, and just generally give the whole codebase a good spring-clean...
...it's nearly 25% slower.
This is, to use the official technical term, a bit of a bugger. I was expecting nothing less than an improvement in core clock speed, and my worst-case scenario was that it remained constant. To come out of this with something that isn't as good as it was before is a bit disappointing, to say the least. Yes, the code is now much cleaner and significantly more maintainable, but for some reason I'm seeing clock speeds of around 30MHz instead of about 40MHz which I was getting before.
Possible reasons for this are:
1. My cycle-counting is broken somewhere, or the speed calculation is wonky. This would be the best option, as it would mean the core itself is OK and I'm just reporting the speed incorrectly.
2. I've made enough changes that I've actually inadvertantly fixed a bug I didn't know I had in the old version that meant it looked like it was running faster than it really was. Not as nice, because I don't know what that bug might have been, and therefore have no easy way to prove it was causing a problem and now isn't.
3. I've introduced a bottleneck somewhere by accident. Maybe the shiny indexer code in MemoryMap isn't as slick as I thought it was; or maybe the use of the (long) cast to get the indexer to do a double-byte access is actually a bad idea, even though I don't do it that often. Or perhaps it's something else entirely, although to be honest the CPUCore instruction decode/execute logic is not particularly complex, so I'm not sure where else a slowdown might be occurring.
I guess it's time to find a decent .NET code profiler and let it interrogate the emulator as it runs, to see where the hotspots are...
Hmm.
...it's nearly 25% slower.
This is, to use the official technical term, a bit of a bugger. I was expecting nothing less than an improvement in core clock speed, and my worst-case scenario was that it remained constant. To come out of this with something that isn't as good as it was before is a bit disappointing, to say the least. Yes, the code is now much cleaner and significantly more maintainable, but for some reason I'm seeing clock speeds of around 30MHz instead of about 40MHz which I was getting before.
Possible reasons for this are:
1. My cycle-counting is broken somewhere, or the speed calculation is wonky. This would be the best option, as it would mean the core itself is OK and I'm just reporting the speed incorrectly.
2. I've made enough changes that I've actually inadvertantly fixed a bug I didn't know I had in the old version that meant it looked like it was running faster than it really was. Not as nice, because I don't know what that bug might have been, and therefore have no easy way to prove it was causing a problem and now isn't.
3. I've introduced a bottleneck somewhere by accident. Maybe the shiny indexer code in MemoryMap isn't as slick as I thought it was; or maybe the use of the (long) cast to get the indexer to do a double-byte access is actually a bad idea, even though I don't do it that often. Or perhaps it's something else entirely, although to be honest the CPUCore instruction decode/execute logic is not particularly complex, so I'm not sure where else a slowdown might be occurring.
I guess it's time to find a decent .NET code profiler and let it interrogate the emulator as it runs, to see where the hotspots are...
Hmm.
Posts
0 comments:
Post a Comment