Re: Books and other things which cost money to improve performance

Colin Paul Gloster schrieb:


> It has been warned many times in books such as by Appel and the red
> dragon book that compilers need to be conservative. If I can get more
> ideas on what mind be hindering compilers from applying optimizations,
> then I could rewrite the code to make the work easier for the
> compilers, or to manually perform such optimizations. After all, I do
> not need to be conservative. I do not even need to preserve the
> semantics of the program: if I find that I can get similar semantics
> which is just as correct but results in faster executables, then I
> will.


IMO it depends on the language, what (loop...) constructs are available,
and how these can be optimized. When people start to suggest *not* to
use this or that feature, because it results in slow code, then the
compiler should optimize these structures better. E.g. a Pascal For loop
(counted) can perform very well, when the indexed access to array
elements is replaced by pointers and increments in the loop body, by the
compiler. It's not a good idea when the users avoid that loop type, and
use pointers themselves, only due to missing optimization. The same for
loop unrolling and other possible manual optimization.


The introduction of fast processors, where every memory access costs
many CPU cycles, made instruction reordering a *must* for every
compiler. I would not do such optimizations in high level code, when the
compiler can do that itself, and for every supported CPU in the best
possible way. Similarly for machines with different register sets, like
x86 in 32 and 64 bit mode, where the compiler can make best use of the
*actually* available number of registers, while high level code can be
optimized only for on specific CPU - without duplicating code and ending
up in a maintenance nightmare.




Thanks anyhow for you book list :-)


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.