3 ms·
If you're writing the interpreters in Java (or other language compiled to JVM bytecode) your code itself is going to be interpreted and JIT'd on the go by the J
by brabel 2y ago
If you're writing the interpreters in Java (or other language compiled to JVM bytecode) your code itself is going to be interpreted and JIT'd on the go by the JVM, so it's really difficult to come up with real optimisations to your interpreter.
In my experience, the JVM "likes" dumb code: direct, without abstractions on top. Use static final methods for everything, no inheritance, avoid memory allocation (though the JVM is insanely good at optimising small, short memory usage). In a bytecode interpreter you may be tempted to use "proper" type hierarchies with Ops represented by interfaces and things like that. Instead, using an array of objects of the same type which can hold the "variants" (basically, C-style OOP without vtables) of each Op is what makes things go from slow to fast.
The code looks very non-idiomatic for Java, of course, but with care can be made pretty readable.
- robinei 2y agoIdeally arrays of primitive values like `long` to store the bytecode represenation for proper good performance. Then use bitwise manipulation to access "fields"
- bruce343434 2y agoAt this point, why not just use C or C++ since you are already writing it like that? Gets rid of the whole middleman.
- gjadi 2y agoBecause you get all the nice tooling around the JVM + safety of running inside the JVM. See https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-... / https://news.ycombinator.com/item?id=24895395 https://news.ycombinator.com/item?id=24895395 > An improvement can be discussed in the morning, and be implemented, tested and released in production in the afternoon.
- larsga 2y agoThat's what we did. Still no luck.
- brabel 2y agoWhat are the bottlenecks according to the profiler?