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: Mon, 14 Aug 2023 04:20:18 +0200 Message-ID: <877cpyicv1.fsf@dataswamp.org> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <83fs4rjq9j.fsf@gnu.org> <87jzu2tvfc.fsf@dataswamp.org> <87y1ih3mc1.fsf@localhost> <87h6p5kcek.fsf@dataswamp.org> <87msyxoj2t.fsf@localhost> <875y5lkb4b.fsf@dataswamp.org> <87bkfdsmde.fsf@localhost> <87v8dlihc5.fsf@dataswamp.org> <87il9l1i59.fsf@localhost> <87edk9icis.fsf@dataswamp.org> <871qg84qij.fsf@localhost> <871qg8l03q.fsf@dataswamp.org> <877cpzl357.fsf@localhost> <87sf8ni85u.fsf@dataswamp.org> <87ttt3fdjt.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13921"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:r21/ts0ejvngtRcgiTyGSxf4WPo= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 14 04:23:16 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 1qVNEg-0003JI-6J for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Aug 2023 04:23:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qVNEJ-00017g-K6; Sun, 13 Aug 2023 22:22:51 -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 1qVNC4-0000s6-Pp for emacs-devel@gnu.org; Sun, 13 Aug 2023 22:20:33 -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 1qVNC2-0002SI-W3 for emacs-devel@gnu.org; Sun, 13 Aug 2023 22:20:32 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qVNC0-000ARx-IU for emacs-devel@gnu.org; Mon, 14 Aug 2023 04:20:28 +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: Sun, 13 Aug 2023 22:22:49 -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:308695 Archived-At: Ihor Radchenko wrote: >>> In practice, as more generic benchmarks demonstrated, we >>> only had 10% performance hit. Not something to claim that >>> Elisp is much slower compared to CL. >> >> What do you mean, generic +10% is a huge improvement. > > It is, but it is also tangent to comparison between Elisp > and CL. The main (AFAIU) difference between Elisp and CL is > in how the bignums are stored. Elisp uses its own internal > object type while CL uses GMP's native format. GMP = GNU Multiple Precision Arithmetic Library. https://en.wikipedia.org/wiki/GNU_Multiple_Precision_Arithmetic_Library > And we have huge overheads converting things back-and-forth > between GMP and Elisp formats. It is by choice. And my patch > did not do anything about this difference. But that's all the better, your patch solved (very likely) the problem and did so without causing havoc by trying to forcibly merge opposing solutions. And the method was: instead of reallocating new objects for bignums, we are no reusing existing allocations for new data? >>> It would be more useful to compare CL with Elisp using >>> less specialized benchmarks that do not involve bignums. >>> As Mattias commented, we do not care much about bignum >>> performance in Elisp - it is a rarely used feature; we are >>> content that it simply works, even if not fast, and the >>> core contributors (at least, Mattias) are not seeing >>> improving bignums as their priority. >> >> But didn't your patch do that already? > > No. The benchmark only compared between Elisp before/after > the patch. Not with CL. No, that much I understood. It was Elisp before and after the patch, as you say. Isn't before/after all data you need? Nah, it can be useful to have an external reference as well and here were are also hoping we can use the benchmarks to answer they question if CL is just so much faster in general, or if there are certain areas where it excels - and if so - what those areas are and what they contain to unlock all that speed. >> Instead of relying on a single benchmark, one should have >> a set of benchmarks and every benchmark should have >> a purpose, this doesn't have to be so involved tho, for >> example "bignums" could be the purpose of my benchmark, so >> one would have several, say a dozen, each with the purpose >> of slowing the computer down with respect to some aspect or >> known situation that one would try to provoke ... It can be >> well-known algorithms for that matter. >> >> One would then do the same thing in CL and see, where do CL >> perform much better? The next question would be, why? > > Sure. Feel free to share such benchmark for Elisp vs. CL. > I only know the benchmark library for Elisp. No equivalent > comparable benchmark for CL. I'm working on it! This will be very interesting, for sure. The need for speed - but in a very methodical way ... -- underground experts united https://dataswamp.org/~incal