develooper Front page | perl.perl5.porters | Postings from November 2010

Re: why is the perlio buffer hard-wired to 4K?

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
November 9, 2010 17:05
Subject:
Re: why is the perlio buffer hard-wired to 4K?
Message ID:
AANLkTinVTWdVbHtW-wyxAz63EOPLq3t_3jM8Sn31wnKa@mail.gmail.com
On Tue, Nov 9, 2010 at 5:06 PM, Tom Christiansen <tchrist@perl.com> wrote:

> I therefore do not believe that a buffer size that's the same as the VM
> pagesize is necessarily optimal.

I agree completely.

> My hunch is that a bigger one might help.  Careful benchmarks would be
> needed to prove or disprove, or even substantiate, that hunch.

I'm pretty sure the benchmark I posted already demonstrates that on
one particular machine with a 4K page size, buffers of 16K or 32K
provide much faster perlio performance than a buffer that matches the
page size.  I welcome improvements on the benchmark and results on
platforms with varying page sizes.

It might make sense to do page *alignment*, i.e., the buffer size is
a multiple of the page size, but I suspect even that is not the most
important aspect of this.  I'm no performance guru, but the principles
I think I (partly) understand imply that coalescing multiple I/O
operations into a single operation is likely to be a bigger win even
than avoiding the much-dreaded page faults and alignment faults.  Not
to mention that "coalescing," which may require varying levels of
effort for the layers implementing read()/write() on down to the
hardware, is for perlio a passive activity: we simply don't flush as
often, so we save on shuffling things around inside the interpreter.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About