3 ms·

Insulation from performance concerns also makes your performance model less predictable. Because the ends of optimisations are observable, but their means are n

Insulation from performance concerns also makes your performance model less predictable. Because the ends of optimisations are observable, but their means are not, people resort to “butterfly programming”. As a small example, in ActionScript 3, people used to write their conditionals like this: if (a) if (b) { ... } Rather than this: if (a && b) { ... } Because the dumb compiler generated better code for the former. In the real world, I’ve seen seemingly benign code changes prevent optimisations from firing—optimisations we didn’t know we were relying on. So people start coding to the implementation, rather than the language or the human, without even being able to see what they’re doing. I really don’t like that. Optimisers are like garbage collectors—they give you better ergonomics than, and equal average performance to the manual alternative, if you’re willing to relinquish predictability and a non-voodoo mental model of your code’s performance.

mikeash 11y ago
I wonder if it would be practical to expose the optimizations to the programmer and allow the complex ones that are easy to accidentally disable to be invoked explicitly. Your code would look something like: optimization(fold_constant_vector_lookup_access_frobnitz) { complex code here } And if the compiler can't apply the optimization, it can produce an error rather than slow code.
- evincarofautumn 11y ago
  That works. We already have some things like that, like “__attribute__((always_inline))”. Of course, forcing some optimisations could implicitly prevent others, but that’d also be true if you did it manually. With expressive enough metaprogramming, you could also do some of these explicit optimisations in user code.
johncolanduoni 11y ago
> Optimisers are like garbage collectors—they give you better ergonomics than, and equal average performance to the manual alternative, if you’re willing to relinquish predictability and a non-voodoo mental model of your code’s performance. This is why I'd like to see optimizers become less opaque. It would be great if we could not only suggest optimizations to the compiler (and more sophisticated ones that just inlining), but actually see the process which our code went through. One language that has some interesting things going on in this area is Nim, which lets you write your own domain-specific optimizations[1]. [1]: http://hookrace.net/blog/what-is-special-about-nim/#add-your-own-optimizations-to-the-compiler http://hookrace.net/blog/what-is-special-about-nim/#add-your...
temo4ka 11y ago
Some people continue to write JavaScript in such a way: https://github.com/greensock/GreenSock-JS/blob/1.18.0/src/uncompressed/TimelineLite.js#L459 https://github.com/greensock/GreenSock-JS/blob/1.18.0/src/un...
WalterBright 11y ago
> I really don’t like that. Unfortunately, the nature of optimizations makes tracking these sorts of things really hard. They don't occur in a vacuum - nearly every optimization transformation interacts with a dozen other transforms, sometimes with very surprising (and usually counterproductive) results. If you simply implement "book" optimizations, you'll find that they often don't even work without some considerable re-engineering from the bottom up. Many book optimizations make the code slower. And then there are the myriad of optimizations that make code faster on one CPU and slower on the next release of that CPU. If you think that compiler optimizer writers are holding out on you, they aren't. It's a bit of an arcane art, like samurai sword making technique.
- evincarofautumn 11y ago
  Of course. I have no problem with generic, implicit optimisation. However, people often need to optimise further, manually. Without good language support, they start coding to a particular implementation: using less-than-portable intrinsics, or worse, trying to trigger heuristics that produce the optimisations they actually want.

mikeash 11y ago

I wonder if it would be practical to expose the optimizations to the programmer and allow the complex ones that are easy to accidentally disable to be invoked explicitly. Your code would look something like: optimization(fold_constant_vector_lookup_access_frobnitz) { complex code here } And if the compiler can't apply the optimization, it can produce an error rather than slow code.

evincarofautumn 11y ago
That works. We already have some things like that, like “__attribute__((always_inline))”. Of course, forcing some optimisations could implicitly prevent others, but that’d also be true if you did it manually. With expressive enough metaprogramming, you could also do some of these explicit optimisations in user code.

johncolanduoni 11y ago

> Optimisers are like garbage collectors—they give you better ergonomics than, and equal average performance to the manual alternative, if you’re willing to relinquish predictability and a non-voodoo mental model of your code’s performance. This is why I'd like to see optimizers become less opaque. It would be great if we could not only suggest optimizations to the compiler (and more sophisticated ones that just inlining), but actually see the process which our code went through. One language that has some interesting things going on in this area is Nim, which lets you write your own domain-specific optimizations[1]. [1]: http://hookrace.net/blog/what-is-special-about-nim/#add-your-own-optimizations-to-the-compiler http://hookrace.net/blog/what-is-special-about-nim/#add-your...

temo4ka 11y ago

Some people continue to write JavaScript in such a way: https://github.com/greensock/GreenSock-JS/blob/1.18.0/src/uncompressed/TimelineLite.js#L459 https://github.com/greensock/GreenSock-JS/blob/1.18.0/src/un...

WalterBright 11y ago

> I really don’t like that. Unfortunately, the nature of optimizations makes tracking these sorts of things really hard. They don't occur in a vacuum - nearly every optimization transformation interacts with a dozen other transforms, sometimes with very surprising (and usually counterproductive) results. If you simply implement "book" optimizations, you'll find that they often don't even work without some considerable re-engineering from the bottom up. Many book optimizations make the code slower. And then there are the myriad of optimizations that make code faster on one CPU and slower on the next release of that CPU. If you think that compiler optimizer writers are holding out on you, they aren't. It's a bit of an arcane art, like samurai sword making technique.

evincarofautumn 11y ago
Of course. I have no problem with generic, implicit optimisation. However, people often need to optimise further, manually. Without good language support, they start coding to a particular implementation: using less-than-portable intrinsics, or worse, trying to trigger heuristics that produce the optimisations they actually want.