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: Sun, 13 Aug 2023 11:49:33 +0200 Message-ID: <87sf8ni85u.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37044"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:FEziVqfcIir/dXGfujAUHbfE08w= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 13 12:06:40 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 1qV7zc-0009Op-2C for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Aug 2023 12:06:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qV7yi-0000dh-AZ; Sun, 13 Aug 2023 06:05:44 -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 1qV7jK-0007Nq-Tu for emacs-devel@gnu.org; Sun, 13 Aug 2023 05:49:52 -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 1qV7jI-0000cS-Kb for emacs-devel@gnu.org; Sun, 13 Aug 2023 05:49:50 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qV7jG-00099Z-9A for emacs-devel@gnu.org; Sun, 13 Aug 2023 11:49:46 +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 06:05:41 -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:308665 Archived-At: Ihor Radchenko wrote: > The main problem your benchmark demonstrated is with bignum. > By accident, it also revealed slight inefficiency in vector > allocation, but this inefficiency is nowhere near SBCL 0.007 > sec vs. Elisp 2.5 sec. Yeah, we can't have that. > 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 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? It would indicate that it is possible to do it all in/to Elisp, which would be the best way to solve this problem _and_ not have any of the integration, maybe portability issues described ... So 1, the first explanation why CL is much faster is another implementation of bignums handling which is faster in CL, if that has already been solved here absolutely no reason not to include it as 10% is a huge gain, even more so for a whole set of benchmarks. 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? If it is just about piling up +10%, let's do it! -- underground experts united https://dataswamp.org/~incal