Re: threaded I/O

[Bruce Lilly]

Nikos Balkanas wrote:
> 
[...]
> 2) threaded I/O: As Aberg has correctly pointed out, most of the time in
> plain lexxers is waisted on disk I/O. Tests that I have done in my system
> indicate that writing to disk is roughly 3x slower than reading. In addition
> input during development is most of the time cached and read from memory.
> 
> Problem: Flex does blocking I/O. In other words every time the buffer fills
> on read, it stops processing until the buffer fills again from the hard
> disk. Worse even on writing it will try to write to disk on every new line.
> 
> Let's focuse on write. Instead on writing to stdout, one could write to a
> buffer. A separate thread could maintain and write from that buffer. It
> would require changes to ECHO and aliasing printf to sprintf. (Incidentally
> a cosmetic glitch - the definition to ECHO has arguments 2 & 3 to fread
> reversed, according to man fread.). Granted a lot of the time flex just
> returns in memory values to bison. A lot
> of other times though (95% of my time) is used as a standalone. That's why
> ECHO
> was developed. One could also use non-blocking I/O, but it's a hassle, and I
> think interrupts are more expensive.

Stdio *is* buffered.  If the bottleneck is your disk (or driver, or
filesystem), what happens when the buffer (quickly) fills up? You have
to wait.  Also, modern operating systems buffer writes unless you take
pains to specify direct disk I/0.  So you already have two levels of
buffering behind the bottleneck.  Adding another layer of buffering
and its associated overhead cannot help -- it can only make matters
worse.  Moreover, only a multiprocessor configuration could possibly
benefit, and you would have to ensure that the I/O was run on a
different processor from the computational work.

I don't see why you make reference to printf and fread; ECHO uses
fwrite, not printf or fread.

> I have timed tests where I took standalone lexxers and just removed the
> ECHOs from the actions (simple lexxers - no printfs). The difference in
> speed was quite significant. With printfs one would have to evaluate time
> spent to format the output versus writing it to disk. If there is interest I
> can do some benchmarks.

Instead of removing ECHOs, wouldn't it have been better to redirect
output to /dev/null, avoiding the disk I/O?  Assuming that you want
to measure the effect of disk writes and not disk writes + stdio
buffering.  If you have a particularly inefficient stdio
implementation, you might benefit from replacing it, and you
certainly wouldn't benefit by adding another layer of buffering
using an inefficient implementation.

[...]
-- 
  Bruce Lilly