This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFTesters] Make portable sgetn/1-in and 1-io tests


On Mon, Jun 16, 2003 at 09:08:08PM +0200, Paolo Carlini wrote:
> Nathan Myers wrote:
> 
> >My experiments suggested that 8192 really is (still) optimal, ...
> >...  I wonder if the default buffer size for filebuf should be 
> >BUFSIZ/sizeof(_CharT), or 2K for wchar_t.  
> 
> Interestingly, it looks like many systems actually use BUFSIZ ~ 1024 or 
> < 8192:
> 
>    http://www.pimpworks.org/security/telnetd.txt

Yes, historically it was 1K on the PDP-11.  It tends to stay fixed
on a given architecture, through generations, for ABI-like reasons,
and even across architectures, just because people promoting a new
architecture often have too much else to think about until it's too 
late.  When a new, incompatible architecture or kernel comes out, it 
becomes worthwhile to measure again.  Now that we break the ABI every 
day before breakfast, though, we should run nightly benchmarks and 
adjust accordingly.  ;-)  

Seriously, 8K is likely to be (harmlessly) too small on modern targets
but is very likely to be too large on P4, which has only an 8K (!) L1
cache.   It would be silly to jimmy our design for the sake of the
crippled P4, but that shouldn't stop us from doing what is usually the
right thing, and what would still be better on the P4.  It does mean
that our primary streambuf measurements ought not to be run on a P4, 
as it behaves very differently from the rest of the known universe.
(Alternatively, tests run on P4s should be carefully skewed -- such as
using a different buffer size -- to avoid generalizing results from the
P4's potholes.)

Nathan Myers
ncm-nospam@cantrip.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]