What Challenges and Trade-Offs Do Optimising Compilers Face?

Re:What Challenges and Trade-Offs Do Optimising Compilers Face? by jerven on Thursday June 22, 2017 @01:44PM (#14613951)

Just as a data point I wanted to see what the benefit of JVM HotSpot is over JVM just interpreting. Code that normally runs in 22 minutes with HotSpot is still running 99minutes later in interpreter only mode!

I am starting to think that the complaints about optimizing compilers are due to C family undefined behavior leading to C programmers having a love hate relationship with their compiler writers. In contrast Java programmers trust their JIT compilers to not screw up. But then UB is something that can cause issues even if there was no optimizing compiler at all.

So to conclude I am extremely grateful that there are optimizing compiler writers out there.

[ Parent | on HN ]

Re:What Challenges and Trade-Offs Do Optimising Compilers Face? by jerven on Friday June 23, 2017 @02:48AM (#14617420)

Another option is to compare a minimally optimizing compiler with a more optimizing compiler. This one can do in Java land with client/server flags. Client takes for our workload 15% more time to run than server.

Now what is that 15% worth? Take the new AMD Epyc to go from 2Ghz to 2.2Ghz is worth 800USD (3200->4000). That means running JVM -server gives a value at that level of about 1/3 of the server CPU cost over running the same JVM -client. Of course that is at the top level and would be less in the middle.

[ Parent | on HN ]