Re:What Challenges and Trade-Offs Do Optimising Compilers Face?
by lmm on Thursday June 22, 2017 @06:49PM
(#14615909)
I used to think that, but I no longer do. Most code is plenty fast enough already, sure, but for the cases where performance is a requirement, it needs to be exposed and accessible in a way that the developer can work with it, the same way as for any other feature. Compare what's happened with 3D graphics APIs - OpenGL tried to abstract over the hardware capabilities and give the illusion that your card was always capable of everything, but actually that just resulted in developers having to almost reverse engineer what the OpenGL implementation was doing so that they could find out what the actual hardware fast path was and use it. So newer APIs concentrate on exposing more of the hardware details and giving the developer more precise control over what's going on.
[ Parent
| on HN ]
Re:What Challenges and Trade-Offs Do Optimising Compilers Face?
by mhh__ on Thursday June 22, 2017 @08:17PM
(#14616275)
That's the language design/philosophy, not specific details of how it was implemented.
Re:What Challenges and Trade-Offs Do Optimising Compilers Face?
by lmm on Friday June 23, 2017 @06:04AM
(#14618070)
What distinction are you drawing? I think concerns like "this operation is O(n^2) in the length of the passed list" are absolutely the responsibility of the language, and probably even lower-level details. I'm not sure how to expose "this operation takes n machine-code instructions" without sacrificing cross-platformness, but I do think that's something we're going to need for important use cases (e.g. cryptographic libraries need to be able to do various things in constant time, which no existing language really has first-class support for).