From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Bignum performance (was: Shrinking the C core) Date: Wed, 16 Aug 2023 00:33:33 +0200 Message-ID: <87o7j8ey0y.fsf@dataswamp.org> References: <87bkfartof.fsf@localhost> <175cf474-29c8-a482-072e-0de784ac59e8@gmail.com> <87o7jaqc31.fsf@localhost> <2d419e12-9239-de3e-47d0-38815a00025f@gmail.com> <87cyzqq7sx.fsf@localhost> <875y5gh075.fsf@dataswamp.org> <87zg2spcxo.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36029"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:kUw6LrLcru6Gsxox8cIWZbVAenw= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 16 04:22:22 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qW6Au-000972-BC for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Aug 2023 04:22:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qW69X-0007IG-JD; Tue, 15 Aug 2023 22:20:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qW2bm-0003cV-79 for emacs-devel@gnu.org; Tue, 15 Aug 2023 18:33:50 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qW2bj-0005O7-KP for emacs-devel@gnu.org; Tue, 15 Aug 2023 18:33:49 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qW2bh-0006lp-KC for emacs-devel@gnu.org; Wed, 16 Aug 2023 00:33:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 15 Aug 2023 22:20:53 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308787 Archived-At: Ihor Radchenko wrote: > Yes, but when CBCL is orders of magnitude faster, it > indicates something conceptually wrong in the algo. Indeed, I'll remove it, thanks. But my CL skills aren't at that level so someone else added it. A strange optimization indeed, that breaks the code. Hm, maybe not that unusual when I think about it. But that is for normal code, not supposed benchmarks ... So this is the explanation for the +78 875% speed disadvantage for Elisp! As reported a long time ago when comparing Elisp and CL. I.e., what is documented in this file https://dataswamp.org/~incal/emacs-init/fib.el and discussed here (or be it gnu.emacs.help) several months ago. \o/ Fires up a cigar! Always a pleasure when a mystery gets solved ... but TBH I actually believed Elisp was that much slower. Turns out, the CL implementation wasn't even correct. Bummer, but ultimately good for us as it turned out. > 3x is a matter of variation in the internal details (like > extra type checking in Elisp that Po Lu outlined). I'll remove the supposed optimization, and we'll take it from there. We (you) have already improved the bignum object allocation reuse and Mr. Möllmann solved this issue, so we have a positive trajectory already. But 78 875% or 3x doesn't matter in principle, we do it until we are done regardless ... -- underground experts united https://dataswamp.org/~incal