From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-ports-refactor Date: Wed, 11 May 2016 16:23:35 +0200 Message-ID: <8737powu54.fsf@gnu.org> References: <87twjempnf.fsf@pobox.com> <87zisw9tju.fsf@gnu.org> <8760vgmxfy.fsf@pobox.com> <871t5aq7la.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1462976652 9805 80.91.229.3 (11 May 2016 14:24:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 May 2016 14:24:12 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed May 11 16:24:06 2016 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b0V3S-0007cV-AG for guile-devel@m.gmane.org; Wed, 11 May 2016 16:24:02 +0200 Original-Received: from localhost ([::1]:52563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0V3R-0000aF-Km for guile-devel@m.gmane.org; Wed, 11 May 2016 10:24:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0V3B-0000HG-I5 for guile-devel@gnu.org; Wed, 11 May 2016 10:23:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0V36-00077K-EA for guile-devel@gnu.org; Wed, 11 May 2016 10:23:44 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0V36-00077F-Bt; Wed, 11 May 2016 10:23:40 -0400 Original-Received: from wifi-eduroam-161119.inria.fr ([128.93.161.119]:52520 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1b0V35-0005az-3T; Wed, 11 May 2016 10:23:40 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 23 =?utf-8?Q?Flor=C3=A9al?= an 224 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <871t5aq7la.fsf@pobox.com> (Andy Wingo's message of "Tue, 10 May 2016 17:02:41 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18304 Archived-At: Hello! Andy Wingo 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 =E2=80=9Cport-refactor C=E2=80=9D version for 2.2, and save the Scheme vari= ant 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=E2=80=99s already too slow for some applicatio= ns IMO. WDYT? Regardless, your work in this area is just awesome! Thanks, Ludo=E2=80=99.