Hi,
> Function reordering depends heavily on the size of the functions, in
> most cases such a reordering goes hand in hand with the
> profile-information, and the latter is usually targeted at a "main"
> application. whether such code-positioning makes sense, can't be said
> definitely. Pettis/Hansen state in their paper, that such an
> interprocedural optimization combined with bb-positioning within
> functions may be very promising allowing gains from 2 to 15 %
> depending on the application.
yes, but the gain they achieve has two reasons:
1) they use a direct-mapped instruction cache and the contiguously
placement of functions which call each other frequently might avoid
conflict cache misses since these functions are not mapped to the
same cache locations after reordering (I excluded this option in
my assumption)
2) they assume that the number of page faults will be minimized
since functions which call each other frequently will be likely
stored in the same page.
While writing this here another issue comes to my mind. When virtual
memory is used a reordering of functions might influence the TLB (if this
"cache" is not disabled) leading to different program execution.
> In fact, most compiler/frameworks sup****t function-inlining which may
> lead to even bigger functions, which again may lead to a cache being
> to small to hold more than just one function, in such cases such a
> reordering does not make much sense. the one could turn off inlining,
> this may cause a slight efficiency- improvement and together with the
> inner-procedural placement-strategies be of more meaning, but whether
> it would be better if you had inlining turned on is an other question.
Well, this does not answer my question. ;-)
Sure, when a function is completely inlined into the code than its
position in the code is irrelevant. However, a compiler will not inline
large functions (you told the reason with caches) so that the question
of their placement in memory still remains.
Tim
|
