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]

In message <20030722233258.6913E2A7EA at canning.wemm.org>, Peter Wemm writes:
>"Poul-Henning Kamp" wrote:
>
>>    If Y < X, then you have by definition a performance gain.
>
>Only if you look at the classic model where you ignore things like
>speculation and assume that every instruction is executed exactly once etc.
>Mainframe optimization strategy is not necessarily applicable to to
>contemporary cpus.

You overinterpret now.  My criteria #1 says:

	If inlining a function reduces the code size, it is by
	definition beneficial.

It does not say anything about what happens when you removing an 
inline, and it does not say what happens when inlining increases
the code size.

It only says that if you can reduce the code size by adding an
inline request, then you are on right track, and will not have
to run further benchmarks to prove that it is beneficial.

There can be corner cases where this in fact hurts your performance,
for instance by expanding a function of non-executed code in a much
repeated loop, but I certainly trust that you wouldn't even think
about inlining the function in the first place then.

>I suspect Alan Cox already knows the answer to 'which is faster' in
>the vm_object_backing_scan() case and he's waiting for you to put your foot
>in it. :-)

So far he has not said "I actually measured it", despite having had
several good chances to do so :-)


I think we all, me included, have to admit that we have seldom if
ever actually benchmarked or even just checked the size impact of
the inlines we have put in, mostly we have relied on our intuition
to determine where an inline made sense.

And now GCC has told us that we were wrong in some number of
the cases and that should prompt us to trust our intuition a little
bit less and rely more on actual facts instead.

-- 
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.