[Gibbon1]

> If execution efficiency is not a concern and you're using C

Two things.

Thing one: Execution efficient on super scalar processors is very unlike what you assume it to be. For instance you assume alignment makes you program fast, when in fact it makes it slower due to cache pressure.

Thing two: On lower end processors what's important is not speed but code size.

Thing three: (off by one error natch) The amount of critical C code is tiny tiny tiny compared to the amount of C code where execution speed just does not matter because the code is almost never executed. The bleeding hot sections are often rewritten in assembly (encryption cough decryption)

[adwn]

> Execution efficient on super scalar processors is very unlike what you assume it to be.

It's not. What do you think I "assume execution efficiency to be"?

> On lower end processors what's important is not speed but code size.

That's why I said "most likely", not "always". Besides, those tiny microprocessors typically don't run the "business apps" which bokglobule was talking about.

> The amount of critical C code is tiny tiny tiny compared to the amount of C code where execution speed just does not matter because the code is almost never executed.

Not true for most software. Sure, most applications spend most of their execution time in a small part of the code, but it's typically not so small that you could easily rewrite it in assembly.

> The bleeding hot sections are often rewritten in assembly (encryption cough decryption)

Cryptography kernels are written in assembly to ensure that they have a constant execution time to prevent timing attacks. Not so much for performance.

[Gibbon1]

> I "assume execution efficiency to be"?

You assume that modern high performance processors execute instructions. They do not, they analyze, optimize and emit their an internal instruction stream and then execute that. That extra step is what makes fiddly UB type 'optimizations' worthless. And since you don't know what processor is going to execute the code and how it's optimized, the speed gains are basically 'noise'

> Besides, those tiny microprocessors typically don't run the "business apps" which bokglobule was talking about.

"Business apps" is usually network and io bound more than anything.

> Not true for most software.

Dan Bernstein says you're wrong.

> Cryptography kernels are written in assembly to ensure that they have a constant execution time to prevent timing attacks. Not so much for performance.

Dan Bernstein says you're wrong here too. Performance is everything with encryption. Consider video streaming over and encrypted connection. Yeah that.

[adwn]

> You assume that modern high performance processors execute instructions.

Yeah, stop making stuff up about me.

> they analyze, optimize and emit their an internal instruction stream and then execute that.

I know how an out-of-order, superscalar processor works. I also know that they can't do magic, because their optimizations are severely limited by time and scope constraints (although they do have access to some information that isn't available at compile time).

> That extra step is what makes fiddly UB type 'optimizations' worthless.

I'm not arguing for optimizations based on UB. This subthread is about compiler optimizations in general, which bokglobule claimed to be nearly always unnecessary.

> Dan Bernstein says you're wrong.

Do you have a study you can cite? Do you think just dropping a name will convince anyone?

> Performance is everything with encryption.

I never claimed it wasn't. I claimed that performance isn't the reason why cryptography kernels are rewritten in assembly, and that's because C + optimizing compiler is already fast enough and the small performance gain alone doesn't justify the switch to assembly.