From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Bignum performance (was: Shrinking the C core) Date: Sun, 13 Aug 2023 10:21:26 +0000 Message-ID: <87ttt3fdjt.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23551"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Emanuel Berg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 13 12:21:37 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 1qV8E4-0005wW-Uz for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Aug 2023 12:21:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qV8De-0003Hw-6f; Sun, 13 Aug 2023 06:21:10 -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 1qV8Dc-0003Hf-B3 for emacs-devel@gnu.org; Sun, 13 Aug 2023 06:21:08 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qV8DY-00064b-25 for emacs-devel@gnu.org; Sun, 13 Aug 2023 06:21:08 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 09E3A240027 for ; Sun, 13 Aug 2023 12:21:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1691922062; bh=RyMe5G3kQqy68kM6RH+hCOIuuwlYxXcVyfcAz3epKiY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=WlWEqAN6VFQLrkn761UfnxrWze4ZA27ZT1d4hKxXrzd6U8UvOGptqwBvSBaJZtiC6 yg59odcrkhlk9ZL9WziTYBwLHjAkVTkAfsgR0SWFjWFORSJmjKfLM7ZWGLWrVqAAfk mmO4S251NpJsMu1m09tcFkLM0f4924a8Ko+0uBot+MfSbPM3m0CHbb1KzALMwkaYsz KEzsI/n5OCCS+LIx9csjAebJuqzbTbM1wKHjfCTj1PztQBlTXe7dpM7Nl2IXfk4S1X NurHnVoKjMIo1t9Z7V7MzM82d4m9INlw0a+umJlFKMbW62N4m32yWQuUgEZ/xgNFBp h0c3AFX9e9zMg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RNtpj1z6Bz9rxB; Sun, 13 Aug 2023 12:21:00 +0200 (CEST) In-Reply-To: <87sf8ni85u.fsf@dataswamp.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:308667 Archived-At: Emanuel Berg writes: >> 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. 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. Also, +10% is just on my machine. We need someone else to test things before jumping to far-reaching conclusions. I plan to submit the patch in a less ad-hoc state later, as a separate ticket. >> 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. > 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at