Let’s say because of your genetics, you can enjoy playing basketball, and you do that, and you have fun doing that, you get better at it… but that’s that, it won’t be that easy for you with other subjects or even get to next level at basketball. Then you need to submit to discipline… or are you willing to wait for things to become fun?
> pays off
That’s why it is important to chase things you are curious about, then you don’t need to wait for some return…
This story is in “surely you are joking mr. Feynman” or “what do you care what does other people think?”.
When they ask him to do something not concrete, that was his answer :) so he was preferring fetching pencils to thinking about applications of some technology…
Genuinely asking - not directly to OP of course, wasn’t this how people were playing the game when you were kids? Not as rigorous, but you intuitively try offsets to get lucky and find the number in fewer tries?
I guess in the same sense that every functional aircraft is. Taking everything apart and putting it back together, replacing worn out parts, is considered normal maintenance.
>just a simple case of bad code generation render little compiler into a toy one
If you find some time to go through gcc bugzilla you'll find shockingly simple snippets of code that miscompiled (often by optimization passes), with fixes never backported to older versions that production environments like RHEL are using.
I realized with all the rhel systems I’m using, we are never using default toolchains on them. Just use those old systems to run stuff, even newer toolchains.
I think a production grade compiler not only can, but must, leave performance on the table when the cost is correctness (unless the performance gain is incredibly high and the correctness loss is minimal). Correctness is not all important, but it is the most important thing. Unfortunately, compiler writers do not agree and they do silly things like "let's assume UB cannot ever happen and optimize based on that".
This is about optimizations affecting timing of cryptographic code, not correctness of computation, the argument for calling this a correctness bug in the compiler is quite weak I think.
I do not agree in the general case. There are very useful DSL compilers which do not consider performance at all, but just compile to a target which does the optimization for them (JVM, LLVM IR or even just C)
if you aren't running on the gpu you're leaving 80+% of your computer's performance on the table. no optimizing compiler is going to make your legacy c or lisp or rust code run efficiently on the gpu, or even in most cases on a multicore cpu. nor, as thechao points out, can it compete with assembly-language programmers for simd vectorization on the cpu
in summary, optimizing compilers for c or pascal or zig or rust or whatever can only be used for code where considerations like compatibility, ease of programming, security, and predictability are more important than performance
probably the vast majority of production code is already in python and javascript, which don't even have reasonable compilers at all
