Algorithms/go-perfbook
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tweak compiler optimizations prose

Browse Source
This commit is contained in:
Damian Gryski 2018-03-16 14:33:57 -07:00
parent 3210b72350
commit e2c004a3f7
1 changed files with 8 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
performance.md
View File

@ -647,10 +647,14 @@ Program tuning:
* consider different number representations: fixed-point, floating-point, (smaller) integers,
* fancier: integers with error accumulators (e.g. Bresenham's line and circle), multi-base numbers / redundant number systems
Many folklore performance tips for tuning rely on poorly optimizing
compilers and encourage the programmer to do these transformations by hand:
hoisting invariant calculations out of loops, using shift instead of
multiply, loop unrolling, common sub-expression elimination, ...
Many folklore performance tips for tuning rely on poorly optimizing compilers
and encourage the programmer to do these transformations by hand. Compilers
have been using shifts instead of multiplying or dividing by a power of two
for 15 years now -- nobody should be doing that by hand. Similarly, hoisting
invariant calculations out of loops, basic loop unrolling, common
sub-expression elimination and many others are all done automatically by gcc
and clang and the like. Go's compiler does many of these and continues to
improve. As always, benchmark before committing to the new version.
The transformations the compiler can't do rely on you knowing things about
the algorithm, about your input data, about invariants in your system, and