Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.compression
Subject: Re: Proposed standard: Replies to criticisms.
Message-ID: <25847.Jun2821.34.4291@kramden.acf.nyu.edu>
Date: 28 Jun 91 21:34:42 GMT
References: <899@spam.ua.oz> <11228@chorus.fr>
Organization: IR
Lines: 20

In article <11228@chorus.fr> jloup@nocturne.chorus.fr (Jean-Loup Gailly) writes:
> Although I said above that it is preferable to have the compressor drive the
> I/O, this does make it more difficult to try multiple compression algorithms
> concurrently. If your language does not give you concurrent threads or
> coroutines, the easiest solution is to read the input file once per algorithm.
> But this is costly for very high speed algorithms which are IO bound. Also,
> this is not applicable if the input data must be read only once (modem or
> pipe). Dan, do you have a suggestion for this?

Well, one advantage of passing in read-write function pointers to the
compression routine is that you can substitute routines to read from
memory instead. So the I/O problem disappears. (Actually, that may be a
bit too optimistic: the UNIX read-write interface demands an extra copy
into the buffer, and doesn't even allow for truly asynchronous I/O. I've
never seen a compressor that wants to write to an input block, so the
copies could, in principle, be avoided. The read-write interface thus
involves up to a 5% loss in speed on a Convex [trust me, I've measured
it!], probably around 15% on a Cray, and about 2% on a Sun 4. Boo hoo.)

---Dan