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

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Sat, 25 Jun 2011 22:37:39 +0000
> 
> [...]
>
> I expect the cost of branching and cache effects to tremendously
> outweigh the cost of a couple arithmetic instructions.

I suppose you are right.  All hail the pipeline!  (20%!  You win for
all of us; thanks!)

> Note that I'm talking about a general slice abstraction here which
> would be useful for a much broader range of applications than just
> I/O buffers.

If the slice object keeps the external string (e.g. 64bit) address in
a non-marked area, untagged, then slice-ref (load indirect/indexed)
might give string-ref (untag and load indexed) a run for Fastest.

But you will not distract me with sexy data structures.  I am on a
mission.

> From: Matt Birkholz <address@hidden>
> Date: Sat, 25 Jun 2011 13:42:31 -0700
> 
> [...]
> I just wanted async i/o without mangling the port performance.  I
> suppose I should have done
> 
>       Step 1 (first!): write tests/runtime/port-performance.scm.
> 
>       Step 2: implement the obvious extra copy from async buffer to
>       internal string buffer.  Take a baseline GIO performance
>       measurement.
> 
>       Step 3: genericize genio.scm so that works on external string
>       buffers.  Take another GIO performance measurement, compare
>       and complain. :-)

So I did Steps 1-3 and got this:

                                   copy  xstring  %change
        System ports                            
            Expression reading  11991.0  11778.6     -1.8
            Expression writing  11670.5  11502.9     -1.4
            Line reading         1394.8   1387.1     -0.6
            Line writing          447.6    458.6      2.5
        GIO ports                               
            Expression reading  12543.8  15194.3     21.1
            Expression writing  11882.4  13114.3     10.4
            Line reading         1309.1   3074.3    134.8
            Line writing          620.9   2212.9    256.4

        copy - commit 6910d4e855c5a566ccf0146577c9e92b2ecb14e9
        genio.scm is unaffected.  Gports copy buffer to heap.

        xstring - commit cf8d8af266d372b15739293f4c559e763dfb6ae0
        genio.scm uses external-string buffers.

      Conclusion: copying into a string is faster than accessing the
      external-buffer (until we have slices, or xstring-ref is
      open-coded at least, and loses the bignum arithmetic).

      The system's ports never copy, so the "xstring" implementation
      should be slightly worse, yet was actually slightly better.  I
      had accidentally included

              (integrate-external "string")

      in the "xstring" genio.scm.  The increase in the size of
      genio.bin/com could go without saying, so... too much said
      already.  (I WILL say: We could use that declaration.)

The answer to my BIG question

        How badly did I screw port performance with my ham-handed
        changes to genio.scm for external-string buffers?

is

        You needn't have bothered, to measure it neither. :-}

Oh well.  My fraternization with GIO *did* lead to a nice wrestle over
which thread will run our signal handlers.  Gotta love dem Heisenbugs!

The referenced commits, my test script, and my signal forwarder are
all in my Gtk branch.

    git://birkholz.chandler.az.us/~matt/mit-scheme.git