[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wip-ports-refactor

From: Ludovic Courtès
Subject: Re: wip-ports-refactor
Date: Wed, 11 May 2016 16:23:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)


Andy Wingo <address@hidden> skribis:

> 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.

Thanks for the thorough benchmarks!

My current inclination, based on this, would be to use the
“port-refactor C” version for 2.2, and save the Scheme variant for 2.4

This is obviously frustrating, but I think we cannot afford to make I/O
slower than on 2.0, where it’s already too slow for some applications


Regardless, your work in this area is just awesome!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]