Re: wip-ports-refactor

[Andy Wingo]

Greets,

On Sun 17 Apr 2016 10:49, Andy Wingo <address@hidden> writes:

>                       | baseline | foo    | port-line | peek-char
>     ------------------+----------+--------+-----------+----------
>     guile 2.0         | 0.269s   | 0.845s | 1.067s    | 1.280s
>     guile master      | 0.058s   | 0.224s | 0.225s    | 0.433s
>     wip-port-refactor | 0.058s   | 0.220s | 0.226s    | 0.375s

So, I have completed the move to port buffers that are exposed to
Scheme.  I also ported the machinery needed to read characters and bytes
to Scheme, while keeping the C code around.  The results are a bit
frustrating.  Here I'm going to use a file that contains only latin1
characters:

  (with-output-to-file "/tmp/testies.txt" (lambda () (do-times #e1e6 
(write-char #\a))))

This is in a UTF-8 locale.  OK.  So we have 10M "a" characters.  I now
want to test these things:

  1. peek-char, 1e7 times.
  2. read-char, 1e7 times.
  3. lookahead-u8, 1e7 times.  (Call it peek-byte.)
  4. get-u8, 1e7 times.  (Call it read-byte.)

                       | peek-char | read-char | peek-byte | read-byte
  ---------------------+-----------+-----------+-----------+----------
  2.0                  | 0.811s    | 0.711s    | 0.619s    | 0.623s
  master               | 0.410s    | 0.331s    | 0.428s    | 0.411s
  port-refactor C      | 0.333s    | 0.358s    | 0.265s    | 0.245s
  port-refactor Scheme | 1.041s    | 1.820s    | 0.682s    | 0.727s

Again, measurements on my i7-5600U, best of three, --no-debug.

Conclusions:

  1. In Guile master and 2.0, reading is faster than peeking, because it
     does a read then a putback.  In wip-port-refactor, the reverse is
     true: peeking fills the buffer, and reading advances the buffer
     pointers.

  2. Scheme appears to be about 3-4 times slower than C in
     port-refactor.  It's slower than 2.0, unfortunately.  I am certain
     that we will get the difference back when we get native compilation
     but I don't know when that would be.

  3. There are some compiler improvements that could help Scheme
     performance too.  For example the bit that updates the port
     positions is not optimal.  We could expose it from C of course.

Note that this Scheme implementation passes ports.test, so there
shouldn't be any hidden surprises.

I am not sure what to do, to be honest.  I think I would switch to
Scheme if it let me throw away the C code, but I don't see the path
forward on that right now due to bootstrap reasons.  I think if I could
golf `read-char' down to 1.100s or so it would become more palatable.

Andy