From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: SHA256 performance with Guile 2.2 vs. Guile 3.0 Date: Mon, 06 Jan 2020 20:52:27 +0100 Message-ID: <87mub0s6pw.fsf@pobox.com> References: <874kxcnlh8.fsf@inria.fr> <87sgkwm4uv.fsf@gnu.org> <871rse1bes.fsf@pobox.com> <875zhoex2c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="33063"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Andy Wingo , Guile Devel To: Ludovic =?utf-8?Q?Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 06 20:53:00 2020 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ioYQu-0008RU-04 for guile-devel@m.gmane.org; Mon, 06 Jan 2020 20:53:00 +0100 Original-Received: from localhost ([::1]:59290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioYQs-0001fC-Tg for guile-devel@m.gmane.org; Mon, 06 Jan 2020 14:52:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57792) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioYQf-0001f6-PB for guile-devel@gnu.org; Mon, 06 Jan 2020 14:52:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioYQe-0000rM-JX for guile-devel@gnu.org; Mon, 06 Jan 2020 14:52:45 -0500 Original-Received: from fanzine.igalia.com ([178.60.130.6]:52459) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ioYQd-0000mQ-W4; Mon, 06 Jan 2020 14:52:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=TZE75w1xsq0fWf+vubkvl/RVD6fYAQS+ccMGwHCgrUY=; b=hI9WXs8tqtHA+Z4gjzI1v2t/CjGUPWD99/awYiybBslTMyApU2U9axTUaPLHF1gZsfVjjdpEIPjLOwI9jQoiKKclCWUM/HmKE4d+fKKHqgNU8twfgTgbKOadTQZDvseL6oG3Ij1Rotu4oAtdOHUhREepJ6gTSE/BjQJ117y/cz/9GJZhQE1TapQryyCb801kbSOOZiyZ+0joT8Cfia/t3rNHnlPa5B65kYtpC2vfNC/59ohwMZzmncnN0to3BZiyFaeUfZ89OXev6NCSd1mNQRVqvcBaaDey/ll/7vxaSBz/ckN29cbxonf+jiTBhe07XwwutPeugB+bkrAmUhTXbQ==; Original-Received: from [88.123.12.110] (helo=sparrow) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1ioYQX-0001Y6-Dk; Mon, 06 Jan 2020 20:52:37 +0100 In-Reply-To: <875zhoex2c.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 06 Jan 2020 10:47:07 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 178.60.130.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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:20233 Archived-At: On Mon 06 Jan 2020 10:47, Ludovic Court=C3=A8s writes: > Andy Wingo skribis: > >> With cross-module inlining of "small" definitions, I think we would >> solve a lot of this kind of problem. I think we could add this during >> 3.0 and for this reason I would hesitate to apply this patch for 3.0 >> because it changes "fx+" exports to be macros rather than "normal" >> values in the ABI. WDYT? > > I agree that cross-module inlining is the better fix whereas this patch > is the immediate workaround. > > Are you confident that cross-module inlining can happen be added without > introducing incompatibilities over in the 3.0 series? (At first sight > it seems tricky to me, notably because we=E2=80=99d have to store Tree-IL= in > object files, which introduces compatibility and thus external > representation versioning considerations.) Concretely I would add a little part of the compiler to the Tree-IL phase to serialize a bytecode for the "small" definitions in the module, for declarative modules, both public and private (because public definitions may alias private definitions). This would be stored as a bytevector in an additional field of the module, and the program being compiled would be transformed to initialize the "lto" field (placeholder name) of the module, so that once the compiled module is loaded, we have the inlinable bindings. I think this can be done compatibly. > If you do, then it=E2=80=99s fine to drop this patch. If conversely > cross-module inlining might take longer, then we can have this patch in > and drop it in 3.2. Your call! (I guess I=E2=80=99m not being that help= ful > here. :-)) :) I hesitate to land this patch because we haven't shown that it significantly helps things, it would need to be undone, and it makes the ABI more fragile. So if that's OK let's do nothing :) Cheers, Andy