From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.bugs Subject: bug#41354: equal? has no sensible code path for symbols Date: Tue, 19 Jan 2021 22:53:37 +0100 Message-ID: <874kjcr3tq.fsf@fencepost.gnu.org> References: <87v9kuzvht.fsf@fencepost.gnu.org> <875zchjen4.fsf@gnu.org> <87o8q9cddl.fsf@fencepost.gnu.org> <87367kavs1.fsf@gnu.org> <87blm8c8c3.fsf@fencepost.gnu.org> <87ftbj6ua5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2352"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 41354@debbugs.gnu.org To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Tue Jan 19 22:54:46 2021 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1yxa-0000To-3h for guile-bugs@m.gmane-mx.org; Tue, 19 Jan 2021 22:54:46 +0100 Original-Received: from localhost ([::1]:43804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1yxZ-00080K-6o for guile-bugs@m.gmane-mx.org; Tue, 19 Jan 2021 16:54:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46246) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1yws-0007L1-OQ for bug-guile@gnu.org; Tue, 19 Jan 2021 16:54:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40433) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l1yws-000307-GU for bug-guile@gnu.org; Tue, 19 Jan 2021 16:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l1yws-0006Tt-FQ for bug-guile@gnu.org; Tue, 19 Jan 2021 16:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: David Kastrup Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 19 Jan 2021 21:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41354 X-GNU-PR-Package: guile Original-Received: via spool by 41354-submit@debbugs.gnu.org id=B41354.161109323224894 (code B ref 41354); Tue, 19 Jan 2021 21:54:02 +0000 Original-Received: (at 41354) by debbugs.gnu.org; 19 Jan 2021 21:53:52 +0000 Original-Received: from localhost ([127.0.0.1]:51979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l1ywh-0006TS-MX for submit@debbugs.gnu.org; Tue, 19 Jan 2021 16:53:51 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l1ywe-0006TC-A5 for 41354@debbugs.gnu.org; Tue, 19 Jan 2021 16:53:50 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34831) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1ywY-0002zK-B5; Tue, 19 Jan 2021 16:53:42 -0500 Original-Received: from dynamic-093-131-081-135.93.131.pool.telefonica.de ([93.131.81.135]:37130 helo=lola) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l1ywX-0006cJ-Q8; Tue, 19 Jan 2021 16:53:42 -0500 In-Reply-To: <87ftbj6ua5.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Fri, 29 May 2020 10:05:06 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:9955 Archived-At: Ludovic Court=C3=A8s writes: > Hi, > > David Kastrup skribis: > >> Ludovic Court=C3=A8s writes: > > [...] > >>> Thus we could go with the patch below, though I doubt it would make a >>> measurable difference (and it actually adds tests for other cases). >> >> It made a considerable measurable difference in LilyPond > > You measured with and without the patch I sent? Or something else? It made a considerable measurable difference in LilyPond to use scm_eq over scm_eqv when one variable was known to be a symbol and most comparisons would have turned out false. > >>> diff --git a/libguile/eq.c b/libguile/eq.c >>> index 627d6f09b..16c5bfb3f 100644 >>> --- a/libguile/eq.c >>> +++ b/libguile/eq.c >>> @@ -303,6 +303,8 @@ scm_equal_p (SCM x, SCM y) >>> return SCM_BOOL_F; >>> if (SCM_IMP (y)) >>> return SCM_BOOL_F; >>> + if (scm_is_symbol (x) || scm_is_symbol (y)) >>> + return SCM_BOOL_F; >>> if (scm_is_pair (x) && scm_is_pair (y)) >>> { >>> if (scm_is_false (scm_equal_p (SCM_CAR (x), SCM_CAR (y)))) >>> >> >> Yes, that looks reasonable. scm_is_symbol checks some tag subset that >> the code for equal_p later looks at closer as well: if you worry about >> the extra cost of the scm_is_symbol check, one could try folding the >> symbol check into that later code passage, which would slow down the >> symbol check and effect the more costly fallbacks less. But since those >> fallbacks _are_ more costly, I doubt it would be worth the trouble. > > Looking at eq.c, I don=E2=80=99t see what =E2=80=9Ccostly fallbacks=E2=80= =9D you=E2=80=99re referring > to. For a symbol, AIUI, we end up here: > > switch (SCM_TYP7 (x)) > { > default: > /* Check equality between structs of equal type (see cell-type test= above). */ > if (SCM_STRUCTP (x)) > { > if (SCM_INSTANCEP (x)) > goto generic_equal; > else > return scm_i_struct_equalp (x, y); > } > break; // <- here, meaning we return SCM_BOOL_F > > All the checks leading to this line are type tag comparisons. > > Am I overlooking something? That "all the checks" amount to quite a bit when the whole point of a symbol is being faster to compare than structured types? The main surprise for me was that a symbol is a non-immediate type even though on second thought it is clear that the symbol name has to be stored somewhere associated with the symbol value. However, from the performance semantics a symbol should not be markedly different from immediate types to avoid violating reasonable user expectations about the Scheme type system: their whole point is to be fast to compare, and fast comparisons are particularly important where you go through a large number of them (which usually implies that most comparisons will end up false). This is particularly important when both arguments are symbols. The normal expectation of functions like assv would be that they would be only marginally slower than assq when the search key is a symbol (and particularly so if most key/value pairs have a symbol key). Because the outcome for eqv(symbol1, symbol2)->#f takes quite longer than the outcome for eq(symbol1, symbol2)->#f, this expectation is not met. --=20 David Kastrup