cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c

Poul-Henning Kamp phk at phk.freebsd.dk
Tue Jul 22 22:46:11 PDT 2003


In message <20030723013442.DFA102A7EA at canning.wemm.org>, Peter Wemm writes:

>What has been highlighted is that inline has been abused over time. The
>argument is how and where to draw the line in cost vs benefit.  'inline' is
>a hint to the compiler that you believe that the increased code size cost
>is worth it.  The problem is that some inlines were being failed because
>the gcc cost estimation was happening before optimization and was way out
>of sync with reality.  eg: a reference to curthread blows the estimate out
>of the water, even though it accounts for 1 or 2 instructions only.

That is only half the problem Peter.

The other half of the problem is that since GCC ignored some of
the inlines, people may have looked at the object size and thinking
"Ok, that had no significant cost and I probably saved a couple of
instructions" despite the fact that nothing happened at all.

Once we increase the GCC limit to get the cases you mention above
inlined, then these impotent inlines suddenly explode in our face
as pessimizations.

Those were the onces I tried to deal with yesterday.

>The other problem is that many of the original measurements were done years
>ago by folks who are no longer with us (eg: John Dyson) on hardware that
>is no longer an accurate representative of current hardware.

This is really only an issue in the few cases where measurements were
actually performed.  I don't see anyone saying "I always test my
code to see if inline has han impact".

>> Might we expect some
>> performance improvements now that we know to force gcc to
>> inline the functions?
>
>Thats an interesting question, isn't it?  Somebody had previously measured
>a 5% slowdown as a result of not inlining the VOP_* function wrappers.
>I wonder if this is part of the 4.x -> 5.x slowdown that hasn't been
>resolved yet.  I dont know how many VOP_* calls are or are not presently
>being inlined though.

In generic all VOP's are inlined at a limit>= 270 so I think the ansker
is "none".

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the cvs-src mailing list