Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: