4 ms·

It does if you want research done so compilers can implement results in this space and optimise away unnecessary copies without introducing errors.

millstone 7y ago
This class of automatic, best-effort optimizations is actually bad! Say the compiler discovers an optimization like "we don't have to copy this giant array". Now either you care or you don't. If you don't care, it was wasted work. If you do care, now you have some fragile, implicit set of preconditions to maintain the optimization. How do you document these, how do you test it? Instead, in a high performance language, we should: 1. Make the language do the algorithmic heavy lifting. Rust's annoyingly explicit affine type system enables its deterministic memory management and various safety guarantees. Its generics are explicitly monomorphic, which enable aggressive inlining. etc. 2. The compiler's optimizer sweeps up just the details. Register allocation, constant propagation, inlining, all the classics. But not inter-procedural stream-fusing tail-calling Haskell-heroism. The idea is to make the important optimizations explicit, and allow the compiler to make things faster on the margins and avoid the obviously wasted work.
- gowld 7y ago
  Explicitness is nice when you are building spacecraft, be but it has a real human cost. I'd rather not write all that stuff, and let my static or dynamic analyzer warn me about potential hotspots non-optimizable code. Best-effort is fine if it's run an ecosystem where code changes are tested before deployment, which is everywhere performance matters.
  - logicallee 7y ago
    Let's say someone includes a line 48362/37277295; That's a no-op. (Some rational value you're not using - it's not even assigned to a variable name). The compiler might warn you about it. But do you think it should be allowed to just remove it - not even create the op? Regardless of what the standard says, I'd expect the answer to be "sure." What do you think?

millstone 7y ago

This class of automatic, best-effort optimizations is actually bad! Say the compiler discovers an optimization like "we don't have to copy this giant array". Now either you care or you don't. If you don't care, it was wasted work. If you do care, now you have some fragile, implicit set of preconditions to maintain the optimization. How do you document these, how do you test it? Instead, in a high performance language, we should: 1. Make the language do the algorithmic heavy lifting. Rust's annoyingly explicit affine type system enables its deterministic memory management and various safety guarantees. Its generics are explicitly monomorphic, which enable aggressive inlining. etc. 2. The compiler's optimizer sweeps up just the details. Register allocation, constant propagation, inlining, all the classics. But not inter-procedural stream-fusing tail-calling Haskell-heroism. The idea is to make the important optimizations explicit, and allow the compiler to make things faster on the margins and avoid the obviously wasted work.

gowld 7y ago
Explicitness is nice when you are building spacecraft, be but it has a real human cost. I'd rather not write all that stuff, and let my static or dynamic analyzer warn me about potential hotspots non-optimizable code. Best-effort is fine if it's run an ecosystem where code changes are tested before deployment, which is everywhere performance matters.
- logicallee 7y ago
  Let's say someone includes a line 48362/37277295; That's a no-op. (Some rational value you're not using - it's not even assigned to a variable name). The compiler might warn you about it. But do you think it should be allowed to just remove it - not even create the op? Regardless of what the standard says, I'd expect the answer to be "sure." What do you think?