Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Mar 2004 00:13:48 +1100
From:      Tim Robbins <tjr@freebsd.org>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        John Birrell <jb@cimlogic.com.au>
Subject:   Re: cvs commit: src/lib/libc/stdio _flock_stub.c local.h
Message-ID:  <20040310131348.GA95975@cat.robbins.dropbear.id.au>
In-Reply-To: <20040310035912.GQ56622@elvis.mu.org>
References:  <200403090245.i292j0a6035728@repoman.freebsd.org> <20040309032248.GA88649@cat.robbins.dropbear.id.au> <20040309143223.Q234@freebsd3.cimlogic.com.au> <20040309035532.GA88825@cat.robbins.dropbear.id.au> <20040309150536.R234@freebsd3.cimlogic.com.au> <20040309043207.GA65153@kanpc.gte.com> <20040310000922.A5035@gamplex.bde.org> <20040310035912.GQ56622@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 09, 2004 at 07:59:12PM -0800, Alfred Perlstein wrote:

> * Bruce Evans <bde@zeta.org.au> [040309 07:50] wrote:
> > On Mon, 8 Mar 2004, Alexander Kabaev wrote:
> > 
> > > On Tue, Mar 09, 2004 at 03:05:36PM +1100, John Birrell wrote:
> > > >
> > > > I'm not sure that I agree that applications are 'broken' when they
> > > > use things that are defined in the header file along with the FILE
> > > > structure itself.
> > 
> > It's a historical mistake that FILE is not opaque.
> > 
> > > I would like to see FILE to become transparent to applications and its
> > > definition moved to the libc-private header file with the specific
> > > purpose of making the hack you mentioned impossible.
> > 
> > This would pessimize even getc_unlocked() and putc_unlocked().  getc()
> > and putc() are now extern functions, but the old macro/inline versions
> > are still available as getc_unlocked() and putc_unlocked().  Simple
> > benchmarks for reading a 100MB file on an Athlon XP1600 overclocked
> > show that the function versions are up to 9 times slower:
> > 
> > Time to read the file from a disk cache using read(): 0.17 seconds (sys)
> > getc_unlocked() overhead: 0.41 seconds (user)
> > getc() overhead: 1.64 seconds (user)
> > 
> > This is with static linkage.  Dynamic linkage increases the getc()
> > pessimization significantly:
> > 
> > read() time: no significant change
> > getc_unlocked() overhead: 0.44 seconds (user)
> > getc() overhead: 3.62 seconds (user)
> 
> Hmm, can't we use macros that do this:
> 
> #define getc()	(__isthreaded ? old_unlocked_code : getc_unlocked())
> 
> Where __isthreaded is a global that's set by threading libraries
> to 1 and 0 by non-threaded libc, this should get rid of a lot of
> the function call overhead.

Sounds like a good idea to me. In my testing, this approach was about 5%
slower than calling getc_unlocked() directly (due to the conditional jump),
but roughly 3 times faster than a call to the getc() function.

If there aren't any objections, I think we should implement getc()/putc()
this way (and all the other stdio functions that have traditionally had
macro equivalents) before 5-stable to try to recoup some of the performance
losses caused by the removal of the macros.


Tim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040310131348.GA95975>