3 ms·

This issue isn't directly related to BitSet. I have observed the same thing in my programming language interpreter that runs on the JVM (well, it's written in K

This issue isn't directly related to BitSet. I have observed the same thing in my programming language interpreter that runs on the JVM (well, it's written in Kotlin multiplatform so it runs on JS and Natively as well). I start the interpreter and measue the time it takes to all all then numbers below 1000000000. The first time I run it after starting the interpreter it always takes 1.4 seconds (within 0.1 second precision). The second time I measure the time it takes 1.7, and for every invocation following that it takes 2 seconds. If I stop the interpreter and try again, I get exactly the same result. I have not been able to explain this behaviour. This is on OpenJDK 11 by the way. If anyone wants to test this, just run the interpreter from here: https://github.com/lokedhs/array https://github.com/lokedhs/array To run the benchmark, type the following command in the UI: time:measureTime { +/⍳1000000000 } My current best guess is that the optimiser decides to recompile the bytecode to improve performance, but the recompiled version actually ends up being slower.

jffhn 5y ago
>the optimiser decides to recompile the bytecode to improve performance, but the recompiled version actually ends up being slower. I had that happen while developing a fast "exp(double)" implementation: for some reason casting a double into an int can be very slow (at least on some architectures) if the double is not close to int range, so I took care to put each of two (exclusive) occurrences of the statement "int i = (int)foo;" after special cases dealing with huge values, but the JIT reworked the code by factoring them above the special cases, making the code much slower for huge values. My first workaround was to replace one of the "int i = (int)foo;" by "int i = -(int)-foo;", which behaved the same in practice but was not factored out by the JIT.
- lokedhs 5y ago
  Thanks. I'd guess something similar happens here. However, I doubt it's they same case as you, since there are no floating point operations involved here. How's were you able to figure it out? Where should I start looking?
  - jffhn 5y ago
    I didn't use any tool, I just knew these casts could be slow and changed one to avoid a suspected factorization, which just worked, but there are ways to show the code generated by the JIT, cf. https://stackoverflow.com/questions/1503479/how-to-see-jit-compiled-code-in-jvm https://stackoverflow.com/questions/1503479/how-to-see-jit-c... or https://stackoverflow.com/questions/30928786/how-do-i-check-assembly-output-of-java-code https://stackoverflow.com/questions/30928786/how-do-i-check-...

jffhn 5y ago

>the optimiser decides to recompile the bytecode to improve performance, but the recompiled version actually ends up being slower. I had that happen while developing a fast "exp(double)" implementation: for some reason casting a double into an int can be very slow (at least on some architectures) if the double is not close to int range, so I took care to put each of two (exclusive) occurrences of the statement "int i = (int)foo;" after special cases dealing with huge values, but the JIT reworked the code by factoring them above the special cases, making the code much slower for huge values. My first workaround was to replace one of the "int i = (int)foo;" by "int i = -(int)-foo;", which behaved the same in practice but was not factored out by the JIT.

lokedhs 5y ago
Thanks. I'd guess something similar happens here. However, I doubt it's they same case as you, since there are no floating point operations involved here. How's were you able to figure it out? Where should I start looking?
- jffhn 5y ago
  I didn't use any tool, I just knew these casts could be slow and changed one to avoid a suspected factorization, which just worked, but there are ways to show the code generated by the JIT, cf. https://stackoverflow.com/questions/1503479/how-to-see-jit-compiled-code-in-jvm https://stackoverflow.com/questions/1503479/how-to-see-jit-c... or https://stackoverflow.com/questions/30928786/how-do-i-check-assembly-output-of-java-code https://stackoverflow.com/questions/30928786/how-do-i-check-...