3 ms·
As the co-author of that blog post a more accurate tl;dr would be the variance comes from shared hot counters that collide based on the address of objects.
by fsfod 8y ago
As the co-author of that blog post a more accurate tl;dr would be the variance comes from shared hot counters that collide based on the address of objects.
- loeg 8y agoOk, to resummarize: LuaJIT is a JIT'd interpreter for a GC'd language and those two factors are where the variance comes from. You found some very low hanging fruit in the JIT engine in particular (64 global trace buckets), fixed it and at least threw it over the fence upstream (and kudos for that). But you buried it in a bunch of irrelevant figures, and at the end of the article you rediscovered GC pauses. GC pauses are a classic, well-known problem with GC languages. My critiques are this: 1. There is a huge body of prior work and analysis of JIT'd and GC languages due to the outsized impact of Java, probably the most popular language on the planet at one point (if it isn't still). (And Golang — Java 2.0.) Java's history (and perhaps Golang's more recent history) should have been top-of-mind at the outset of this project. I think you could continue to apply lessons learned from abundance of experience around Hotspot and JRE tuning to the LuaJIT interpreter. 2. The lengthy benchmark spreadsheets seem like a distraction rather than a useful tool. They're certainly not adding much to the article and could be summarized in 2-3 sentences each. If you really felt like it, they could be linked to an external appendix.