From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-ports-refactor Date: Thu, 12 May 2016 10:15:10 +0200 Message-ID: <87lh3fpu9d.fsf@pobox.com> References: <87twjempnf.fsf@pobox.com> <87zisw9tju.fsf@gnu.org> <8760vgmxfy.fsf@pobox.com> <871t5aq7la.fsf@pobox.com> <8737powu54.fsf@gnu.org> 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 1463041212 29325 80.91.229.3 (12 May 2016 08:20:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 May 2016 08:20:12 +0000 (UTC) Cc: guile-devel To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu May 12 10:19:59 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 1b0lqe-0006YR-HD for guile-devel@m.gmane.org; Thu, 12 May 2016 10:19:56 +0200 Original-Received: from localhost ([::1]:56039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0lqd-0000wt-Q8 for guile-devel@m.gmane.org; Thu, 12 May 2016 04:19:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0lmL-0002wS-7f for guile-devel@gnu.org; Thu, 12 May 2016 04:15:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0lmF-0000mc-0c for guile-devel@gnu.org; Thu, 12 May 2016 04:15:27 -0400 Original-Received: from pb-sasl2.pobox.com ([64.147.108.67]:52910 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0lmE-0000lx-Jn; Thu, 12 May 2016 04:15:22 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id 37A6A12E51; Thu, 12 May 2016 04:15:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=lRr0312eo1PJ 8nxWUtsGkMJD9u0=; b=widqG/ul68Uqcp1FT8EwawFzuJr/79BvgKc2YnpZUCXF 9NPDyg3438ImZcVAHwC5NhgNXNVLqhNRPyoqAIS/27k1FRcBHjTfTNX/sFI8orl4 /u5qq1GOGB9XH2YEOcjf6deSIgQd47k4hqILCOyAAvgnD4irG0+96Kt7FOwBE+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=SNJeO9 ll+2vl7IxHWd6GgSJ7idleQ527yASHCsJt3uEC8yHrPKBPBAQzcwL3LBQkb+hbMV aZKQE5ufTn3LseJ//6WUYQlpfsY/XDDT9F8YOoKj4K7Fsmg28RGcmRnKnaPSdV4q LSNyoN4yo0qDfVaUz53k8lXsbUx6ijtRnARZ8= Original-Received: from pb-sasl2. (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id 2F56D12E50; Thu, 12 May 2016 04:15:19 -0400 (EDT) Original-Received: from clucks (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl2.pobox.com (Postfix) with ESMTPSA id 288DC12E4F; Thu, 12 May 2016 04:15:18 -0400 (EDT) In-Reply-To: <8737powu54.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Wed, 11 May 2016 16:23:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Pobox-Relay-ID: A9DE9F1E-1819-11E6-99FC-D472793246D6-02397024!pb-sasl2.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.67 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:18307 Archived-At: On Wed 11 May 2016 16:23, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Andy Wingo skribis: > >> | 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 >> > 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 va= riant 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 applicat= ions > IMO. > > WDYT? Humm, you might be right! I still have some questions though. Before the questions, one point -- the "port refactor C" and "port refactor Scheme" variants use the same underlying port structure. The Scheme variant just implements part of the port runtime in Scheme instead of using the C runtime. So, it would be possible to have the Scheme version in a module in 2.2, if that were useful -- and I think it's useful enough to enable green threads that suspend on I/O. Regarding speed, you say 2.0 is too slow, but I could not reproduce that in my initial benchmarks. But, I can't be sure what you mean -- there are the different axes as to whether you're processing input a byte at a time, or in a block of bytes, whether you are decoding text or not, and whether the port is buffered or not. Do you recall any more details? In my experience I never found 2.0 I/O to be too slow, but your mileage evidently varies. On all of these different axes, wip-port-refactor will be better because it uniformly buffers the input through a standard buffer, which I/O routines like get-bytevector can peek into directly. This is true whether the I/O routines are written in Scheme or in C. The cases that I measure above are the worst cases for the difference between C and Scheme, because they have all the overhead of a potential slow-path that does a buffer fill and BOM handling and what-not but they do very little I/O (just a byte or a char) and have no associated workload (they do nothing with those bytes/chars). Routines that read multiple bytes at a time would not have as big a difference between Scheme and C. Furthermore with the uniform buffer, we can rewrite things like read-line to peek directly into that buffer instead of doing a bunch of read-char operations. This would be big news for things like the web server. We could make this refactor either in Scheme or in C but I suspect the performance would be similar, and Scheme is better than C ;-) But, probably it is time to step back a bit now that the core changes to the ports infrastructure have been made and seem to be performant enough. I will see if I can manage to get the extra internal helpers that I had to expose shunted off into a separate module that's not exposed to (guile-user), and then if that's all looking good I'll update documentation and NEWS and see about a release. What think ye? Andy