[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) |
Hello!
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
maybe.
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
IMO.
WDYT?
Regardless, your work in this area is just awesome!
Thanks,
Ludo’.