3 ms·

If you care about optimizing your C/C++ code, you need to be reading the assembly language output from the compiler on a regular basis. You will constantly stum

If you care about optimizing your C/C++ code, you need to be reading the assembly language output from the compiler on a regular basis. You will constantly stumble over cases where the compiler isn't doing what you expected. For example, it might be reloading memory in an inner loop instead of caching its value in a register outside the loop because its alias analysis was inconclusive. Or not enough inlining is happening where you expected it. Or there's too much inlining like when a side exit to a cold function is inlined within an inner loop. This last case exemplifies a general issue that ahead-of-time compilers have with identifying code paths as hot or cold. You can sometimes give hints to the compiler, but you must verify that the hints were actually taken in the way you expected. Obviously you only dive into this level of detail with a piece of code once you have reason to believe it's warranted (e.g. profiler information).

blt 12y ago
Yes. Sampling profiler + reading generated assembly are the two prongs of my optimization approach. Sometimes the compiler does something really stupid and inefficient, but other times it does something really clever that I (who never wrote any serious assembly by hand) would never think of.
- vardump 12y ago
  Better be careful though. Sometimes compiler generated output that looks stupid is correct. And what you think is faster, is not faster or correct. Such as signed division by two by strength reduction to a shift. The results are wrong for negative numbers without a fixup. Compilers also consider whole possible value range. They do reduce the set of possible values based on earlier code. Like if you've previously multiplied a value by two, the compilers know afterwards "value & (~1)" can be safely removed entirely. But the compiler is forced to drop an optimization if there's even one possible value for which the optimization is not valid. Common values for this to occur are for example 0, INT_MIN, INT_MAX, etc. Compilers also know a lot of cost. Hypothetically speaking (I haven't actually seen following ever happening!) there can be situations where it's faster to multiply by two than to shift left or add to self. Like because of CPU core execution unit availability that the compiler knows about.

blt 12y ago

Yes. Sampling profiler + reading generated assembly are the two prongs of my optimization approach. Sometimes the compiler does something really stupid and inefficient, but other times it does something really clever that I (who never wrote any serious assembly by hand) would never think of.

vardump 12y ago
Better be careful though. Sometimes compiler generated output that looks stupid is correct. And what you think is faster, is not faster or correct. Such as signed division by two by strength reduction to a shift. The results are wrong for negative numbers without a fixup. Compilers also consider whole possible value range. They do reduce the set of possible values based on earlier code. Like if you've previously multiplied a value by two, the compilers know afterwards "value & (~1)" can be safely removed entirely. But the compiler is forced to drop an optimization if there's even one possible value for which the optimization is not valid. Common values for this to occur are for example 0, INT_MIN, INT_MAX, etc. Compilers also know a lot of cost. Hypothetically speaking (I haven't actually seen following ever happening!) there can be situations where it's faster to multiply by two than to shift left or add to self. Like because of CPU core execution unit availability that the compiler knows about.