11–20 of 21 posts
I feel like I've seen the trick of estimating upcoming interrupts before somewhere...was it mednafen or higan? Anyways cool post! How come you don't consider conditional branches to be terminating instructions of your basic blocks?
One "cheap" performance boost you could probably get is replacing your HashMaps with FxHashMap, https://docs.rs/fxhash/latest/fxhash/ , which uses a much cheaper/faster, but also not cryptographically secure, hashing algorithm. For these purposes, I doubt the hashing algorithm weakness would be an issue.
You mentioned that you do a hash map look for each (bank,addr) key. Suggestion which helped us: have this point to an Netey which contains the JIT code but also an index/pointer into the next block which executed last time you executed this block. You can do a simple check to see if this is still valid and fall back to the hashmap lookup. If you're careful about code invalidation (not an issue with ROM) then this can help skip the next lookup.
Congrats!
One "cheap" performance boost you could probably get is replacing your HashMaps with FxHashMap, https://docs.rs/fxhash/latest/fxhash/ , which uses a much cheaper/faster, but also not cryptographically secure, hashing algorithm. For these purposes, I doubt the hashing algorithm weakness would be an issue.
Why the hell would a HashMap use a cryptographically secure hash?
One "cheap" performance boost you could probably get is replacing your HashMaps with FxHashMap, https://docs.rs/fxhash/latest/fxhash/ , which uses a much cheaper/faster, but also not cryptographically secure, hashing algorithm. For these purposes, I doubt the hashing algorithm weakness would be an issue.
Why the hell would a HashMap use a cryptographically secure hash?
> It was designed to be efficient even for short inputs, with performance comparable to non-cryptographic hash functions, such as CityHash, this can be used to prevent denial-of-service attacks against hash tables ("hash flooding") [...]
Earlier quoted context omitted.
Why the hell would a HashMap use a cryptographically secure hash?
HashMap uses SipHash. To call it cryptographically secure is not a clear way of summarizing what it provides. See Wikipedia for more info. Blurb: > It was designed to be efficient even for short inputs, with performance comparable to non-cryptographic hash functions, such as CityHash, this can be used to prevent denial-of-service attacks against hash tables ("hash flooding") [...]
I did not know this was a thing. What a massive amount of engineering effort is being wasted on protecting against outlandish attacks!
A JIT is something I’d been wondering about for a bit, and this post was eye-opening about the complexities involved (I have no real compiler background).
One "cheap" performance boost you could probably get is replacing your HashMaps with FxHashMap, https://docs.rs/fxhash/latest/fxhash/ , which uses a much cheaper/faster, but also not cryptographically secure, hashing algorithm. For these purposes, I doubt the hashing algorithm weakness would be an issue.
I feel like I've seen the trick of estimating upcoming interrupts before somewhere...was it mednafen or higan? Anyways cool post! How come you don't consider conditional branches to be terminating instructions of your basic blocks?
Initially I was doing that, but it was making tight loops too slow. And what I am referring to as a "block" was not a basic block, but a entire compilation unit.
One "cheap" performance boost you could probably get is replacing your HashMaps with FxHashMap, https://docs.rs/fxhash/latest/fxhash/ , which uses a much cheaper/faster, but also not cryptographically secure, hashing algorithm. For these purposes, I doubt the hashing algorithm weakness would be an issue.
I am already using a non-cryptographic hasher. In fact, I am not doing any hashing at all, I am just assuming that the input is already random enough, and use a Hasher that just copies the input to output. But I still didn't measure the performance of that, so that may be something silly to do.