Closed mkeeter closed 6 months ago
Yes. Keep in mind that the original DynASM project for C (used as backend in LuaJIT 1.x, used as frontend in ) does not use a hash map for labels. It is a plain array.
I know this is hard given the constraints of rust proc-macros, but Ideally we would move in that direction......
It wouldn't necessarily have to be a new type of label, it'd be possible to guarantee that local labels in a single block always get determined at compile time. It'll be quite annoying to implement though.
But before we have a try at that, The default LabelRegistry
just uses the standard cryptographically secure hasher in the label hashMaps. You could try benchmarking it with FnvHasher
instead.
Idea: it wouldn't be hard to just special case strings of length 1 to just be array lookups instead. Make those bypass the internal hashmaps, if recent changes do not alleviate the bottleneck enough.
As discussed in the related pull request, you can use dynamic labels to skip the overhead from hashmap lookups if you want to know the theoretical speedup due to that. That would be useful knowledge to have before proceeding on working on this.
Closing this due to inactivity after requested information.
I noticed that hashmap lookups are taking a decent amount of JIT time when using local labels.
For example, if I manually compute jumps in this code:
I end up with something like this:
In my codebase, this reduces the time spent in
dynasm
by about 30%, which is a decent chunk of performance!It would be great to introduce a new flavor of label which is only valid during a single
dynasm!
block; the branch offset could then be computed at compile-time instead of runtime.