2 ms·

> In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input. Sure, but I'm interested in wh

> In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input. Sure, but I'm interested in what the program does on all meaningful inputs, not a specific one. Otherwise, I'd just precompute the answer and hardcode it. > I don't see how that isn't equally applicable to writing code to fool your JIT. AOT compilers are supposed to provide feedback to the programmer about what the program means (e.g., inferred types, type errors). JIT compilers are not. > I don't really understand why optimistic heuristics bother you so much. Um, because they can be wrong, and then you need to fix errors, which makes the system more complex? > Seems like you just have an aesthetic preference. Yes, for simplicity, and for thinking before writing code.

smallnamespace 10y ago
> Um, because they can be wrong, and then you need to fix errors, which makes the system more complex? Yes, but I don't understand why compiler complexity concerns you, so long as the whole thing works. AOT compilers are also extremely complex, and are also full of heuristics. You seem really hung up on the fact that an optimization can be rolled back at some point, but why should you care? JIT optimizations can be 'wrong' in the same way that caches can miss. It the right engineering solution to eliminate caching, over some belief that one should never be 'wrong' anywhere in a program, even though the eventual answer is always correct? This might matter in system with real-time performance demands, but then you should be equally concerned about the garbage collector, for example.
- catnaroek 10y ago
  > Yes, but I don't understand why you compiler complexity concerns you, so long as the whole thing works. Because I find it easier to trust simpler systems than complex ones. > AOT compilers are also extremely complex, and are also full of heuristics. Yep, those heuristics are annoying too. (But less so than the ones JIT compilers use, because at least they don't involve temporarily breaking my program.) > unless you've profiled it and see this having a real adverse effect on overall performance? How many times do I have to repeat that what annoys me is the excessive complexity?

smallnamespace 10y ago

> Um, because they can be wrong, and then you need to fix errors, which makes the system more complex? Yes, but I don't understand why compiler complexity concerns you, so long as the whole thing works. AOT compilers are also extremely complex, and are also full of heuristics. You seem really hung up on the fact that an optimization can be rolled back at some point, but why should you care? JIT optimizations can be 'wrong' in the same way that caches can miss. It the right engineering solution to eliminate caching, over some belief that one should never be 'wrong' anywhere in a program, even though the eventual answer is always correct? This might matter in system with real-time performance demands, but then you should be equally concerned about the garbage collector, for example.

catnaroek 10y ago
> Yes, but I don't understand why you compiler complexity concerns you, so long as the whole thing works. Because I find it easier to trust simpler systems than complex ones. > AOT compilers are also extremely complex, and are also full of heuristics. Yep, those heuristics are annoying too. (But less so than the ones JIT compilers use, because at least they don't involve temporarily breaking my program.) > unless you've profiled it and see this having a real adverse effect on overall performance? How many times do I have to repeat that what annoys me is the excessive complexity?