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: Janne Blomqvist <jblomqvi at cc dot hut dot fi>
- To: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: GNU GFortran <fortran at gcc dot gnu dot org>, GCC patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 3 Sep 2005 22:31:41 +0300
- Subject: Re: [Patch, gfortran]: PR21820, 23363 etc.: chuck mmap
- References: <20050903182352.GA19706@vipunen.hut.fi> <4319F1EB.9090104@physik.uni-muenchen.de>
On Sat, Sep 03, 2005 at 08:56:43PM +0200, Tobias Schlüter wrote:
> Janne Blomqvist wrote:
> > 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.
>
> The comment at the beginning of unix.c should then be removed as well:
>
> /* This implementation of stream I/O is based on the paper:
> *
> * "Exploiting the advantages of mapped files for stream I/O",
> * O. Krieger, M. Stumm and R. Umrau, "Proceedings of the 1992 Winter
> * USENIX conference", p. 27-42.
> *
> * It differs in a number of ways from the version described in the
> * paper. First of all, threads are not an issue during I/O and we
> * also don't have to worry about having multiple regions, since
> * fortran's I/O model only allows you to be one place at a time.
> ...
I disagree. Even if we don't use mmap anymore, the architecture is
still based on the Krieger paper. The *_alloc_at functions, sfree(),
the stream structure etc.
Also, the implementation described in the paper also contains
"backends" both for mmap and fd, due to the same reasons gfortran
needs fd (special files etc.).
--
Janne Blomqvist