2 ms·

Shouldn't the compiler be able to do that, too?

ModernMech 3y ago
Yes, there’s always the “sufficiently smart compiler” that can generate this code. Question is, does that compiler exist?
- Groxx 3y ago
  I sure hope so. The semantics are trivially identical, the optimizations should be as well, by default - they should depend on semantics, not syntax. And GCC in another comment under this thread seems to be doing similar or identical optimizations in both cases. I wholly admit that this implies nothing about all optimizers. But it's a pretty reasonable one to expect.
- charcircuit 3y ago
  >does that compiler exist? and if so are the compile times worth it
- icsa 3y ago
  These days, I's put my money on zig cc. I.E. zig cc -Os or zig cc -O3
  - eyegor 3y ago
    Does the zig compiler have many fancy bits? I was under the impression the c support was a "nothing special" compiler that punted to llvm for optimizations.
    - plorkyeran 3y ago
      Correct, zig currently does not do any of its own optimizations. It won't necessarily have identical results to clang because it'll generate equivalent but not identical IR and the optimizer passes may happen to do something different as a result, but it's not going to be consistently different.
thomasahle 3y ago
I tried https://godbolt.org/ https://godbolt.org/, and neither Clang nor GCC trunk give the same code for the two programs. Pretty shocking for such a simple program.
AnotherGoodName 3y ago
It's not true in general. In general branching code is faster than branchless code and there's many many places that will demonstrate this with a quick Google. You know how many cycles a correctly predicted branch takes? 0. On the other hand branchless code has to wait for each calculation to reach a certain stage in the pipeline since the thing to be output is dependent on the result. The CPU will have a whole lot of halts. So why is this faster? Because the input is literally random(). The branch predictor will be wrong. This isn't normal though. The compiler is creating code that will be faster in most normal use cases. It's an artificial benchmark that works against the output the compiler produces.
- rendaw 3y ago
  You're saying that humans have information to context that allows them to provide use-case-specific optimizations which a compiler which must anticipate general usage couldn't. That's what profile guided optimizers are for though, right?

Yes, there’s always the “sufficiently smart compiler” that can generate this code. Question is, does that compiler exist?

Groxx 3y ago
I sure hope so. The semantics are trivially identical, the optimizations should be as well, by default - they should depend on semantics, not syntax. And GCC in another comment under this thread seems to be doing similar or identical optimizations in both cases. I wholly admit that this implies nothing about all optimizers. But it's a pretty reasonable one to expect.
charcircuit 3y ago
>does that compiler exist? and if so are the compile times worth it
icsa 3y ago
These days, I's put my money on zig cc. I.E. zig cc -Os or zig cc -O3
- eyegor 3y ago
  Does the zig compiler have many fancy bits? I was under the impression the c support was a "nothing special" compiler that punted to llvm for optimizations.
  - plorkyeran 3y ago
    Correct, zig currently does not do any of its own optimizations. It won't necessarily have identical results to clang because it'll generate equivalent but not identical IR and the optimizer passes may happen to do something different as a result, but it's not going to be consistently different.

thomasahle 3y ago

I tried https://godbolt.org/ https://godbolt.org/, and neither Clang nor GCC trunk give the same code for the two programs. Pretty shocking for such a simple program.

AnotherGoodName 3y ago

It's not true in general. In general branching code is faster than branchless code and there's many many places that will demonstrate this with a quick Google. You know how many cycles a correctly predicted branch takes? 0. On the other hand branchless code has to wait for each calculation to reach a certain stage in the pipeline since the thing to be output is dependent on the result. The CPU will have a whole lot of halts. So why is this faster? Because the input is literally random(). The branch predictor will be wrong. This isn't normal though. The compiler is creating code that will be faster in most normal use cases. It's an artificial benchmark that works against the output the compiler produces.

rendaw 3y ago
You're saying that humans have information to context that allows them to provide use-case-specific optimizations which a compiler which must anticipate general usage couldn't. That's what profile guided optimizers are for though, right?