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
bde at zeta.org.au
Wed Jul 23 00:28:57 PDT 2003
On Tue, 22 Jul 2003, Peter Wemm wrote:
> "Poul-Henning Kamp" wrote:
> > That is the sort of thing which makes me belive that unless proven
> > beneficial (by one of the two criteria), inline is harmful.
> There is a great leap there. Just because somebody isn't willing to spend
> considerable time to re-prove that the runtime improvement is still there
> to your satisfaction, that doesn't mean that it is harmful.
> Take the i386 interrupt vector code. Thats an example where it is massively
> inlined. Having a non-inlined function that does all the calculations
> and bit shifting is much smaller in code size, but slower at runtime.
A good bad example :-). I've wanted to try uninlining that code for
years. Everything except fast interrupt handlers gets demultiplexed
through sched_ithd() and ithread_schedule(), so we do some calculations
and bit shifting anyway; we may even have to repeat some. Anyway,
interrupt handlers aren't called very often, and interrupt handler
time is dominated by hardware access time on non-old machines, starting
with the PIC/APIC accesses in Xintr*. We still do *PIC mask setting
and EOI in Xintr*, but we do *PIC mask unsetting from C code.
More information about the cvs-all