Re: 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

[ Available lists | Index of cvs-all | Month of Jul 2003 | Week of 23 Jul 2003 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Wes Peters <wes@softweyr.com>
Date
23 Jul 2003 17:10:58
Subject
Re: 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
Message-ID
200307231710.46896.wes@softweyr.com


[ Hide this part ]
On Tuesday 22 July 2003 16:43, Poul-Henning Kamp wrote:
>
> 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.

As a general note, I think it is quite hard to predict how any such
"optimization" is going to behave across even the common x86 family
processors. We've seen many times that optimizing for p4 is not the
same as optimizing for Athlon, etc. These days, benchmark results on a
single architecture are arguably no more valid than no benchmark
results at all.

That said, "my athlon is your athlon" (XP 2000+, will be running
-current after this weekend) for anyone who needs one for testing.
Not a speed daemon by todays standards, but it was yesterday...

--
"Where am I, and what am I doing in this handbasket?"

Wes Peters wes@softweyr.com



Elapsed time: 0.304 seconds