[m-dev.] streams in Mercury
Julien Fischer
juliensf at cs.mu.OZ.AU
Fri Dec 16 14:19:40 AEDT 2005
On Fri, 16 Dec 2005, Ralph Becket wrote:
> Julien Fischer, Friday, 16 December 2005:
> >
> > > For the MercuryFile the overhead will be one extra pointer lookup to
> > > find which underlying C function to call no matter what the underlying
> > > stream is. So very slight.
> > >
> >
> > It seems somewhat more than very slight here:
> >
> > <http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mercury-developers.0008/0099.html>
> >
> > but maybe things have changed since then?
>
> Looking at that post, to read and write 1MB of data one byte at a time
> took roughly 10 times as much CPU time, but only three times as much
> real time, the absolute figures in either case being anyway very small
Yes, but I wouldn't want it to take three times as long for something
that did a large amount of I/O.
> (and given that this experiment was conducted five years ago, I'd wager
> that by now the relative difference in user to real time is tiny).
>
Which was why I asked if anyone had any up-to-date figures further
back in this thread.
> > No, but depending on the performance impact (if any) it may be good
> > reason for not implementing the predicates in the io module in terms
> > of the stream typeclasses (as Ian was suggesting).
>
> I'd go the other way and vote for the greater generality of the streams
> interface and the s/w engineering benefits of not having special-case
> code lying around.
What special case code?
> Screaminly high performance IO has not been an issue for us, just as high
> performance floating point (on 32 bit architectures) has not.
I guess this is fairly easily resolved since most of it has already been
implemented.
> If it does become an issue, we know what we have to do to improve matters.
>
A volunteer ;-)
So the as I see it there three proposals here:
(1) add the stream typeclasses to the standard library
(2) reimplement the io module in terms of (1)
(3) use the MercuryFile struct by default
I'm happy for (1) to go ahead now and for (2) and (3) to got ahead
provided they do not have a significant impact on the performance of the
compiler.
Cheers,
Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------
More information about the developers
mailing list