0
        final long s0 = this.s0;
        long s1 = this.s1;
        final long result = s0 + s1;
        s1 ^= s0;
        this.s0 = Long.rotateLeft(s0, 24) ^ s1 ^ s1 << 16;
        this.s1 = Long.rotateLeft(s1, 37);
        return result;

Does copying the fields onto the stack sever the dependency on the other operations; basically allowing the method to return while the next values are computed in the 'background' using instruction level parallelism?

sulljason
  • 1
  • No. If the JIT compiler can figure out how to order the instruction to maximize parallelism in the pipeline, it will do it ... without your attempted assistance. In your example, the JIT compiled code performance (probably) doesn't benefit from you loading `s0` and `s1` into local variables. The JIT compiler can do that kind of optimization without your help. – Stephen C Oct 04 '21 at 06:16
  • But you should be able to confirm this by either writing a benchmark to compare alternative versions of that code (see [How do I write a **correct** micro-benchmark in Java?](https://stackoverflow.com/questions/504103)), or by carefully analysing the JIT compiled code (see [How to see JIT-compiled code in JVM?](https://stackoverflow.com/questions/1503479)). – Stephen C Oct 04 '21 at 06:20
  • Cool thanks for the answer. It's a snippet from some RNG implementation. Thought the style was unusual but its so fast compared to other RNGs I've seen I thought it might be on purpose to achieve that. Good to know the JIT is smart enough to realize that there isn't real dependency and it can be done out of order. I still don't fully understand all the capabilities for parallelism. So to be clear just keep writing numerical algorithms in linear simpler style and rely on the JIT to reorder it? – sulljason Oct 04 '21 at 20:26
  • There could be other things going on. For example, if `this.s0` and `this.s1` are `volatile` then there are performance issues: the JIT is constrained in how it can optimize volatile reads and writes. However, in general, just write your code to be readable. Also: only optimize by hand when strictly necessary, and do it in conjunction with profiling and benchmarking to avoid wasting your time ... – Stephen C Oct 05 '21 at 00:21
  • And finally, don't assume that some random code you find is necessarily an example of efficient coding. The author may have *thought* is was efficient. It may actually have been efficient ... once upon a time. It may never have been efficient. If you really want to know, the only sure ways to find out are to benchmark and/or analyze. And bear in mind that JIT optimizers tend to improve over time. – Stephen C Oct 05 '21 at 00:29

0 Answers0