R
RayLopez99
Hennessey on Compilers: don't hand craft your code, let the compiler do itfor you better, faster (optimization is futile)
Optimization by hand does not work. See below by uP guru Hennessey from his latest textbook. He is talking about C language but the same holds true for C$. BTW he also got rich in Silicon Valley by getting involved with startups.
Why doesn't optimization work? Because the machine is better than you, just like in chess. The other day I spent more than an hour streamlining a certain section of code that relied on stacks to pop/push data from a List. I created an array, then figured out mathematically how the data was fed into the List, to then access the data directly from the array without the need to pop/push into a stack. I also eliminated unnecessary if/then clauseswhich I found never triggered. I figured the code would run at least twice as fast...when I checked using a stopwatch, I found: a mere 15% improvement. Now granted 15% is better than 0%, and if other sections of the program had similar bottlenecks then performance would improve by optimizing the code this way, but frankly 15% is not a game changing big deal.
Lesson learned: the compiler will figure out the most efficient way to runyour program. Readability (eye candy) and maintenance by others reading your code is therefore the only value add of a programmer these days. "GOTO" conditions anybody? They probably run as fast or faster than anything a programmer can come up with.
RL
Fallacy: Write in assembly language to obtain the highest performance.
At one time compilers for programming languages produced naïve instruction sequences; the increasing sophistication of compilers means the gap between compiled code and code produced by hand is closing fast. In fact, to compete with current compilers, the assembly language programmer needs to understand the concepts in Chapters 4 and 5 thoroughly (processor pipelining and memory hierarchy).
This battle between compilers and assembly language coders is one situationin which humans are losing ground. For example, C offers the programmer a chance to give a hint to the compiler about which variables to keep in registers versus spilled to memory. When compilers were poor at register allocation, such hints were vital to performance. In fact, some old C text-books spent a fair amount of time giving examples that effectively use register hints. Today’s C compilers generally ignore such hints, because the compiler does a better job at allocation than the programmer does.
Even if writing by hand resulted in faster code, the dangers of writing in assembly language are the longer time spent coding and debugging, the loss in portability, and the difficulty of maintaining such code. One of the fewwidely accepted axioms of software engineering is that coding takes longerif you write more lines, and it clearly takes many more lines to write a program in assembly language than in C or Java. Moreover, once it is coded, the next danger is that it will become a popular program. Such programs always live longer than expected, meaning that someone will have to update thecode over several years and make it work with new releases of operating systems and new models of machines. Writing in higher-level language instead of assembly language not only allows future compilers to tailor the code tofuture machines, it also makes the software easier to maintain and allows the program to run on more brands of computers.
Optimization by hand does not work. See below by uP guru Hennessey from his latest textbook. He is talking about C language but the same holds true for C$. BTW he also got rich in Silicon Valley by getting involved with startups.
Why doesn't optimization work? Because the machine is better than you, just like in chess. The other day I spent more than an hour streamlining a certain section of code that relied on stacks to pop/push data from a List. I created an array, then figured out mathematically how the data was fed into the List, to then access the data directly from the array without the need to pop/push into a stack. I also eliminated unnecessary if/then clauseswhich I found never triggered. I figured the code would run at least twice as fast...when I checked using a stopwatch, I found: a mere 15% improvement. Now granted 15% is better than 0%, and if other sections of the program had similar bottlenecks then performance would improve by optimizing the code this way, but frankly 15% is not a game changing big deal.
Lesson learned: the compiler will figure out the most efficient way to runyour program. Readability (eye candy) and maintenance by others reading your code is therefore the only value add of a programmer these days. "GOTO" conditions anybody? They probably run as fast or faster than anything a programmer can come up with.
RL
Fallacy: Write in assembly language to obtain the highest performance.
At one time compilers for programming languages produced naïve instruction sequences; the increasing sophistication of compilers means the gap between compiled code and code produced by hand is closing fast. In fact, to compete with current compilers, the assembly language programmer needs to understand the concepts in Chapters 4 and 5 thoroughly (processor pipelining and memory hierarchy).
This battle between compilers and assembly language coders is one situationin which humans are losing ground. For example, C offers the programmer a chance to give a hint to the compiler about which variables to keep in registers versus spilled to memory. When compilers were poor at register allocation, such hints were vital to performance. In fact, some old C text-books spent a fair amount of time giving examples that effectively use register hints. Today’s C compilers generally ignore such hints, because the compiler does a better job at allocation than the programmer does.
Even if writing by hand resulted in faster code, the dangers of writing in assembly language are the longer time spent coding and debugging, the loss in portability, and the difficulty of maintaining such code. One of the fewwidely accepted axioms of software engineering is that coding takes longerif you write more lines, and it clearly takes many more lines to write a program in assembly language than in C or Java. Moreover, once it is coded, the next danger is that it will become a popular program. Such programs always live longer than expected, meaning that someone will have to update thecode over several years and make it work with new releases of operating systems and new models of machines. Writing in higher-level language instead of assembly language not only allows future compilers to tailor the code tofuture machines, it also makes the software easier to maintain and allows the program to run on more brands of computers.
