This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, gfortran]: PR21820, 23363 etc.: chuck mmap
- From: Paul Brook <paul at codesourcery dot com>
- To: fortran at gcc dot gnu dot org
- Cc: Janne Blomqvist <jblomqvi at cc dot hut dot fi>,GCC patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 8 Sep 2005 19:49:59 +0100
- Subject: Re: [Patch, gfortran]: PR21820, 23363 etc.: chuck mmap
- References: <20050903182352.GA19706@vipunen.hut.fi> <20050906082833.GA23323@cc.hut.fi>
On Tuesday 06 September 2005 09:28, Janne Blomqvist wrote:
> On Sat, Sep 03, 2005 at 09:23:52PM +0300, Janne Blomqvist wrote:
> > Hello,
> >
> > the attached patch provides a partial fix for the performance issues
> > in PR 21820 and 23363. Partial, as in improving performance 20-fold
> > for some cases but still being far away from other compilers. The
> > patch also solves all mmap related correctness problems, by removing
> > mmap support from the runtime library.
>
> If we want to keep mmap (perhaps there are situations where it does
> bring better performance, although my guess is not measurably so with
> the current fine-grained io library), it would be relatively
> straightforward to e.g. add a check for a GFORTRAN_USE_MMAP
> environment variable when opening a file. That way we'd get the
> performance advantages of fd while still enabling those who want mmap
> to use it.
All the benchmarks I can remember seeing show that our mmap implementation
sucks, and we're better off using the fd backend.
My recommendation is to either rip out the mmap code, or come up with a plan
for making it consistently perform well.
I'm tempted to say rip it out anyway. As Tobi says, we have version control if
anyone wants to revive it.
Paul