Re: Code density and performance?

Peter Grandi <pg_nh@xxxxxxxxxxxxxxxxxxx> wrote:
....
> Seongbae.Park> If you want better locality, you need a
> Seongbae.Park> combination of compile time and link time
> Seongbae.Park> optimization [ ... ]
>
> pg_nh> Sure, ideally, but these cost a lot more time, and
> pg_nh> programmers can't be asked.

For example, Sun's Performance Analyzer
can produce a mapfile from performance measurement
to optimize for code locality
(and it's certainly not the only one that can do that sort of thing).
This mapfile can be used in your build environment
- it requires only a minimal impact in the build environment
since the mapfile doesn't need to be generated
everytime you build.

> Seongbae.Park> Time as in compilation/linking time but no effort
> Seongbae.Park> for programmers especially just turning on
> Seongbae.Park> certain optimization flags. e.g. link time
> Seongbae.Park> optimizer can reorder at function/basic block
> Seongbae.Park> granularity to gather functions and basic blocks
> Seongbae.Park> that are close in the static call graph, and
> Seongbae.Park> compilers can "outline" cold blocks (like
> Seongbae.Park> exception handler or error handling path).
>
> What in essence such optimizers do is to run 'lorder | tsort'
> inside compilation units...
>
> This is still just a bit more fine grained static clustering,
> and in its simplicity 'lorder | tsort' does most of the same
> things, and at the function granularity too if one enables
> splitting.

It's a wrong tool for the job.
Splitting object files for each functions require significant
changes for build environment, and is totally unnecessary.
e.g. simply putting functions into different ELF sections
would give the same degree of freedom to appropriate tools
without impacting user environment.
If somone bothered to use lorder|tsort,
s/he could easily put just a bit more effort
and could potentially get *much* better outcome.

> I think we have already had in past discussions of how nice it
> would be to have 'else infrequently' hints in the language,
> not that would programmers would be bothered to use that. :-/

....and most programmers, even the most competent ones,
will suffer from the consequence of putting wrong "hints".
But let's not go down that rathole again.
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/";
.

Relevant Pages