Re: [MIT-Scheme-devel] Faster ports.

[Taylor R Campbell]

   Date: Thu, 23 Jun 2011 09:53:24 -0700
   From: Matt Birkholz <address@hidden>

   I suppose there is an unavoidable extra indirection in the
   external-string case.  I thought YOU wanted both internally and
   externally buffered ports.  We inline a buffer type test, or go all
   external?

Either way, EXTERNAL-STRING-REF -- some bignum arithmetic followed by
an out-of-line primitive -- is non-negligibly slower than STRING-REF.
This is not acceptable for, e.g., using OPEN-OUTPUT-OCTETS to
accumulate a chunk of bits in-memory.

But maybe this is irreconcilable with having non-moving buffers for
asynchronous I/O -- at least on i386, which is still what my world
runs on...

   > `Byte' won't make any sense when we get the PDP-10 port working again.

   That very old joke is why you can't say "byte"?  You can't be serious.

On a more serious note, while `byte' and `octet' both mean 8-bit
quantities these days, there is still a difference in connotation.
`Byte' connotes memory addressing and perhaps ephemeral internal
representations; `octet' connotes interchange formats such as internet
protocols (all the relevant standards and RFCs use the term `octet')
and perhaps long-term external representations.  That's why I would
prefer `octet' for ports -- they have to do with exchanging data in
well-defined formats with external systems.

Neither term implies a numeric interpretation of the bits, though,
which is why I suggested `u8'.

   > - Octet-by-octet reads and writes with ports are out-of-line [...]

   We're talking about fixing that, yes?

Yes.

   > - There is no support for memory-mapped I/O [...]

   Whoa.  Don't get the portability drums started...

What portability drums?  What serious system in 2011 that MIT Scheme
is likely to run on doesn't support memory-mapped I/O?

In any case, most of the applications I had in mind would always be
able to fall back to read and write with an allocated buffer anyway,
for the I/O devices that don't support memory-mapped I/O (e.g.,
reading data from a socket).

   > At <http://mumble.net/~campbell/tmp/mit-io.tgz> is a tarball [...]

   You are keeping buffers in sources/sinks?  I thought you wanted them
   "exposed" to the inlined read-u8.

If you look closely, you'll see that SOURCE-OCTET (i.e. READ-U8) is
integrated.  The sole purpose of the source/sink abstraction is to be
a buffer admitting in-line usage that is occasionally filled/emptied
out-of-line.

   > I compared ports [...] the improvement in performance [...] was
   > enormous -- probably a decimal order of magnitude, at least.

   How did/would you take measurements?

Simple things such as copying octet-by-octet from an input port to an
output port, interleaving the octets from three input ports to a
single output port, &c.  Switching from ports to octet sources/sinks
as implemented in mit-io.tgz made the tests go from being very clearly
CPU-bound to being very clearly disk-bound.

   > Here's a very rough sketch of the plan I have had in mind [...]
   > 
   > 1. Expose something similar to the channel abstraction, [...]

   I thought we had "exposed"(?) the buffer (not the "channel")...

The purpose of exposing channels is to clearly distinguish operations
on external I/O devices from in-heap buffering.  Think stdio (ports,
or sources/sinks) vs file descriptors (channels).  When I say `expose'
here, I mean make it available to programmers as a documented,
intentional part of the API, as opposed to an undocumented detail of
the implementation as channels are currently.