|
Somehow this[^] seems appropriate.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
I personally have never believed that one "can't beat the compiler." But I will say that in most cases the amount of time to beat the compiler will never be repaid.
When writing your own code, this is a non-issue. Some people take pride in having the fastest time possible. But when doing this for pay, it should always be considered. And we should consider all of the costs. This would include the amount of time one spends finding the fastest way. (And will expense of paying someone to wait that time would be more then the expense of paying the developer.) But also needs to include the extra time it takes the next guy to know what you did, why and decide if it is right or wrong.
|
|
|
|
|
Kirk Wood wrote: I personally have never believed that one "can't beat the compiler."
With you on that. The compiler usually optimizes the best for any general case. Seldom would it optimize for a specific case.
In this scenario it might be that optimizing for 5's divisibility check could be done faster than the compiler's more generalized method. Or it might be a situation of some compilers using that trick about unequal devisors, but not others. You can't just assume the compiler will optimize to the best possible efficiency.
I think the point about this is to go with a middle ground approach: Don't always try to out-perform the compiler, 99% of the time you're wasting effort. But know a bit of what the compiler does, so you can more easily pick-up what might be of use to look further.
|
|
|
|