Visual C++ Compiler Optimizations (2015)
msdn.microsoft.com
msdn.microsoft.com
There are obviously exceptions in specific domains, but even in high performance cases it is generally better to optimize once you know where the bottlenecks are in practice.
For example, with floating point calculations, divides are slower (on x86 anyway) than multiplies, so quite a common one in graphics/physics is to calculate the reciprocal (1.0f / x) and multiply by that if you'd do more than one divide in the first place.
The compiler can do this in some cases, but generally only with fpmath=fast, and even then, not always.
Another good graphics/physics example is that you don't have to take the square root in a distance computation if you only care about the monotonically increasing ordering and not the exact distance. If you know that you will be dividing by magnitude or distance frequently, another optimization is to store the inverse of the magnitude instead of the original magnitude. That issue sometimes shows up in inner loops.
But optimizations like that also don't have to be done up front because refactoring that kind of thing is relatively straightforward compared to switching out the underlying data structure or algorithm.
My rule of thumb is that if I know I'm writing an inner loop, then I will bake in whatever best practices I already know about. Otherwise I'm going to write the feature first with generally sane architectural choices, and profile it later.
Will this reduction in accuracy affect your application? For graphics and physics, maybe not, or at least not until some compounded error in an edge case makes a collision detection fail, or causes an unsightly visual error.
Don't just sprinkle these optimizations throughout your code without understanding the accuracy requirements of your program.
There is a relatively straightforward way to think about this. Either your program depends on fully accurate error analysis (e.g. for reproducibility), or not. If yes, you would not even think of enabling fast-math, because that's implementation-defined behaviour. If no, any mathematically valid substitution will do, unless it causes some kind of unlikely numerical instability.
In the case of evaluating a/x as t=1/x;a * t, it is possible to analyze the optimization exactly: without overflows, the relative error of a * (1/x) will be at most 2u/(1-u), while relative error of a/x will be at most u. Thus this substitution is absolutely fine, there's no need to be scared of it.
Mathematically sensible transformations generally produce sensible results. It is exceedingly uncommon for someone to need a perfectly rounded result.
So while in principle one should be able to expect a compiler to do the $1/x$ optimization all by itself, it might be important enough to just do it by hand and get on with things.
Update: To me, a lot of responses here conflate "optimization" with "design". From where I'm sitting, "optimization" means making adjustments to and existing solution to make it faster. That has nothing to do with choosing an appropriate language or toolset, and limited amounts to do with overall design. Yes, sometimes you must project forward a bit, for example knowing you'll be able to optimize out exponential behavior with a better data structure, say.
But often people do too much, too early, with too little information.
More often than not, if you don't think about performance characteristics beforehand, then -- after taking care of the low hanging fruit -- you find out that time is wasted all over, and there's no specific culprit that's making things so slow; at which point, you need to rewrite the whole thing.
Efficiency should be considered from the beginning in most projects, or later optimizations will be on the scale of "massive undertaking" to "complete rewrite".
real micro optimization examples: order of operation in an inner loop. Changing memory alignment to facilitate vectorization, figuring out your compiler is doing something dumb and tricking it into better code generation for that area,etc.
If you are looking at generated assembly, chances you are doing micro-optimization.
At the end of the day, it's another expression of the 80/20 rule: do the 20% of the optimization work that affects 80% of the runtime. But outside of general knowledge of where the inner loops are, you won't know what that 20% of code that touches 80% of runtime is until you measure.
How would one know if the optimization was successful if there is no measurements to prove it!
Microsoft C++ compiler is a source of aggravation at best. Their unmanaged language tooling has been neglected for nearly a decade while FOSS community (led by none other than Apple) plowed ahead and delivered the work of art that is Clang/LLVM, and a profusion of languages like Rust and Swift that run on top of that infrastructure.
Umm.. it should be evaluated at the top of the loop each time.