Optimizing Software in C++ [pdf]
agner.org
Optimizing Software in C++ [pdf]
1–10 of 13 posts
Re: Optimizing Software in C++ [pdf]
#2Re: Optimizing Software in C++ [pdf]
#3Re: Optimizing Software in C++ [pdf]
#4> How compilers optimize
This didn't mention scalar replacement of aggregates [1]! This is easily one of the most important optimizations for programmers in C++ and similar languages to know about.
[1]: https://books.google.com/books?id=Pq7pHwG1_OkC&pg=PA331&lpg=... is a reasonable explanation.
Re: Optimizing Software in C++ [pdf]
#5Re: Optimizing Software in C++ [pdf]
#6Does this have second part ? (I saw "1" at first page in headline). I am asking because I am in love with this . Thank you so much
for anyone who wants complete series.
Re: Optimizing Software in C++ [pdf]
#7Quick link to grab all five manuals:
Re: Optimizing Software in C++ [pdf]
#8Re: Optimizing Software in C++ [pdf]
#9Chapter 14 is twenty-four carat gold. Would love to see optimize.com as a dedicated site with Rosetta Code-style ports of optimization recipes across languages, platforms ;) Quick link to grab all five manuals: http://www.agner.org/optimize/optimization_manuals.zip
Maybe, but the bounds-checking optimisation [14.2] just looks dangerous. If you end up with an erroneous 'int' index of -1 then the original code will error out, whereas the new code will interpret it as 2^32 - 1. This is a perfectly valid index in an array of 2^32 values. This optimisation just isn't equivalent if INT_MAX Am I missing something?
Re: Optimizing Software in C++ [pdf]
#10Chapter 14 is twenty-four carat gold. Would love to see optimize.com as a dedicated site with Rosetta Code-style ports of optimization recipes across languages, platforms ;) Quick link to grab all five manuals: http://www.agner.org/optimize/optimization_manuals.zip
> Chapter 14 is twenty-four carat gold Maybe, but the bounds-checking optimisation [14.2] just looks dangerous. If you end up with an erroneous 'int' index of -1 then the original code will error out, whereas the new code will interpret it as 2^32 - 1. This is a perfectly valid index in an array of 2^32 values. This optimisation just isn't equivalent if INT_MAX Am I missing something?