From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christopher Allan Webber Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-ports-refactor Date: Wed, 11 May 2016 09:00:47 -0500 Message-ID: <87possy9rk.fsf@dustycloud.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 X-Trace: ger.gmane.org 1462975282 18157 80.91.229.3 (11 May 2016 14:01:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 May 2016 14:01:22 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed May 11 16:01:21 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 1b0UhR-0007qP-5a for guile-devel@m.gmane.org; Wed, 11 May 2016 16:01:17 +0200 Original-Received: from localhost ([::1]:52383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0UhQ-00007p-HJ for guile-devel@m.gmane.org; Wed, 11 May 2016 10:01:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0UhD-0008Km-3p for guile-devel@gnu.org; Wed, 11 May 2016 10:01:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0UhA-00019y-Ky for guile-devel@gnu.org; Wed, 11 May 2016 10:01:01 -0400 Original-Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:51304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0UhA-00017k-GU; Wed, 11 May 2016 10:01:00 -0400 Original-Received: from oolong (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 9B09B26652; Wed, 11 May 2016 10:00:47 -0400 (EDT) User-agent: mu4e 0.9.13; emacs 24.5.1 In-reply-to: <871t5aq7la.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c02::f03c:91ff:feae:cb51 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:18303 Archived-At: Andy Wingo writes: > Greets, > > On Sun 17 Apr 2016 10:49, Andy Wingo 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 Happily at least, none of these benchmarks are *that much* slower than Guile 2.0. So most "present day" users won't be noticing a slowdown in IO if this slipped into the next release. You're probably right (is my vague and uninformed suspicion) that native compilation would speed it up. My thoughts are: if this refactor could bring us closer to more useful code for everyday users, a small slowdown over 2.0 is not so bad. Eg, if we could get SSL support, and buffered reads with prompts, etc... those are good features. So if you had my vote I'd say: forge ahead on adding those, and if they come out well, then I think this merge is worth it anyway, despite a small slowdown in IO over 2.0. Hopefully we'll get it back in the future anyway! - Chris