Does more human-logical source code tend to produce more optimized compiled code?

I'm working on a large performance-critical project that is very branch heavy. In the process of designing algorithms for this product, my employer often reminds me to write code that is more "human logical", or written in a manner that more closely aligns with the way we logically think.

While this makes sense to me from a few different perspectives (e.g. ease of und开发者_如何学Cerstanding/remembering, code maintenance, etc.), I'm also wondering whether this approach could also ever be expected to lead to a more optimized compiled output.

Could this be the case due to the fact that compilers are written by humans, and optimizers are often designed to recognize familiar code blocks?

I would love to hear some thoughts on why this could/not be the case.

---

Consider two different kinds of code, library code and application code. Library code (like a string class library) is likely to own the program counter a lot of the time, like this:

while(some test){
  massage some data, while seldom calling sub-functions
}

That kind of code will benefit from compiler optimization. (So to answer your question, people write benchmark functions like this, and the compiler-writers use those as test cases.)

On the other hand, application code tends to look like this:

if (some test){
  do a bunch of things, including many function calls
} else if (some other test){
  do a bunch of things, including many function calls
} else {
  do a bunch of things, including many function calls
}

In this case, the time you save by branch prediction or cycle-shaving might be 1 time unit, say, while the do a bunch of things... might spend from 10^2 to 10^8 time units, with or without I/O. So the benefit of compiler optimization of this code tends to be completely lost in the noise.

That's not to say it can't be optimized. It's just that the compiler can't do it - it's your job.

If you want to make the latter kind of code run fast, the best way is to find out which lines of code are on the call stack a high percent of time, and if possible, finding a way to avoid doing them. (Here's an example of a 43x speedup.)

---

What is "human logical" probably varies from human to human.

For instance, if I am a newbie performing tasks according to written instructions I will (usually), over time, learn some tasks by heart whereas for others I will return to the instructions simply because the tasks are not performed often enough/are too boring or both. Others in the same situation may or may not function similiarly and it is not certain that the tasks they'll learn will be the ones I learn.

For programming it works similarly. Some may construct a loop in one manner and perform a test inside it for the sake of readability while I might do the test outside for performance reasons. What is more wrong and what is more right?

There is a widespread belief that compilers will optimize anything. This is true but as I've written (drastically) in another post, GIGO (Garbage In = Garbage Out) applies. Compilers don't operate in a vacuum: given a set of rules they'll perform safe optimizations on source code to the extent of their (the compilers') constructors' imagination and competence in code optimizations. Bloat source code will become optimized bloat machine code. In the same manner lean and mean source code will become optimized lean and mean machine code. In critical places it is possible to feed the compiler source code that it "feels" (YES! they do have personalities) absolutely comfortable in optimizing and the resulting machine code will fly.

We've all experienced poorly performing software. If we're lucky we've experienced software that performs incredibly well. One developer can learn to write a piece of code that performs well in the same amount of time that another writes code that performs poorly.