5 ms·
It's really no different from native compiler optimizations, which are also mysterious and always changing, except for one key aspect: when recording timings to
by _bxg1 7y ago
It's really no different from native compiler optimizations, which are also mysterious and always changing, except for one key aspect: when recording timings to compare against other timings, you can control whether optimizations are turned on or off, to remove that variable from the comparison.
- lpghatguy 7y agoThankfully, with a native compiler you don't have to deal with your JIT warming up, or some other code causing your function to get deoptimized, or subtle JIT trace aborts. :(
- fctorial 7y ago> or some other code causing your function to get deoptimized Why doesn't the optimizer generate different compiled implementations of a function for different pieces of code?
- notamy 7y agoI would imagine this to be due to the overhead of then having to track where EVERY variant of a JITted function can then be called from, when to deoptimize, etc.
- pjmlp 7y agoInstead you have to deal with the myriad of optimization flags, optimizations that take advantage of UB and change between versions regarding C and C++ compilers, inlines being dropped because a bug correction made the function body bigger than the allowed threshold,...
- saagarjha 7y ago> It's really no different from native compiler optimizations, which are also mysterious and always changing Go’s compiler is kind of stupid in this sense.