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: Mon, 14 Aug 2023 07:20:30 +0000 Message-ID: <875y5irsxt.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> <87ttt3fdjt.fsf@localhost> <877cpyicv1.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="23193"; 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 Mon Aug 14 09:20:27 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 1qVRsI-0005sN-Tw for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Aug 2023 09:20:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qVRs3-0004xr-7L; Mon, 14 Aug 2023 03:20:11 -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 1qVRs1-0004xZ-Gq for emacs-devel@gnu.org; Mon, 14 Aug 2023 03:20:09 -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 1qVRrz-00024e-MX for emacs-devel@gnu.org; Mon, 14 Aug 2023 03:20:09 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B568E240028 for ; Mon, 14 Aug 2023 09:20:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1691997605; bh=uhxoHor7C6pHa9u8w9NHo2zCWcxQUPGV5hRglJfWDYw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=n+lIZjYMj5HY51d4OmhdU+z3csLpbUnbkPyXvoRt6hi3miSby+A2KiA+SpG87zElN Bd9OAH9YXRQ+OG8Szvs1+leOwNaTVGZK1vKQe8LovJ/D4mkzlcKv3AnNPx3PopWypI 9pEO2YtXAonmckXKa5a8Jjfo3GIUA0+QsX4D82kBRdb3Rl/0uOFn72Zf4ADzuYwYLe zFoFbSrr6ik/4lfyzlckCcSfL67hu6gQXpOZmKT/kJG9654AoyRS7BuhalTxvwl1xe 2MI5pjgCqBn0atpgjZQh81jp2t/ay/7a83eL8oOzYUteXTE8SjYG8WxCdnyWf0prPD z0VluZj0lAmiw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RPQlT0sQwz9rxK; Mon, 14 Aug 2023 09:20:04 +0200 (CEST) In-Reply-To: <877cpyicv1.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: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.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=-1, RCVD_IN_MSPIKE_WL=-0.01, 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:308704 Archived-At: Emanuel Berg writes: > And the method was: instead of reallocating new objects for > bignums, we are no reusing existing allocations for new data? Nope. Reusing existing allocations was already in place. I just optimized how Elisp searches if there are any existing allocations that can be reused. >> 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 ... Yup. It is always better to give very specific benchmark than bluntly claiming that Elisp is slow. Because detailed benchmark provides concrete data on what might be improved (or not; but we can at least discuss without degrading the discussion quality). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at