Re: [RFC] ifunc suck, use ufunc.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Mon, May 25, 2015 at 09:17:48AM -0300, Adhemerval Zanella wrote:
> 
> Although the reason for such mechanism seems reasonable, I do not see a
> good approach to add more architecture specific behaviour on GLIBC. 
> IFUNC is already not really on all platforms and it has its own 
> idiosyncrasies for some ports (like hwcap init order).
>
While it isn't wise to add another mechanism it is necessary. If you
have program where in 50% of call sites implementation A is better while
in other half B is better how would you resolve that? No matter how you
select you would get bad performance (and resolving selection on
backtrace would likely cost more than savings.)

Also you would lose performance from not being able to use precomputed
tables.

You could use ifunc with losing per-call site information. However
ifuncs would get ugly not simple if you have feature X select
implementation using X in order from newest to oldest.

You would need to at start of program read file and you would must
decide to select function according to profile from file. You should
probably do same with ufuncs but these provide some stack.

An aim would be replace ifuncs with ufunc or some variant. For that they
would need to coexist for some time until they are converted.

One side benefit is that you wont need add ifunc for new architectures,
just use ufuncs. One problem would be cost, as mentioned before without
harware atomic write it could be too costy. One possibility that I
mentioned was force double compilation on these arch so you could do
resolving for given cpu and then distribute separate binaries with each
cpu data. 
 
> Also, I think Rich and Szabolcs brought valid points: the devils in the
> details.  For such proposal to have some traction the ideal implementation
> proposed (either in pseudo-code or C implementation) should also be 
> reasonable (and bashing criticise arguing that it is a easily fixable 
> technical details is not the way to go).
> 
Sorry, its when I seen complaint that looked like that i should use tab
followed by space followed by tab on line 1 i tried to cut irrelevant
parts and move to real problems.

> Do you have some background on how other languages or runtime accomplish
> such think? I know java hotspot do have some internal profiler and
> dynamic recompilation based on profile feedback.

Yes, main problem why java-like approach is unsuitable is that in linux
lot of programs have very short lifetime so you need persistent storage
to collect enough data to select implementation with some reliability.
This is compounded that some functions are called rarely.

As i said before one benefit could be make resolver select
implementation that minimizes size for first twenty calls and then do
potentialy expensive profiling/reading profile to determine optimum.