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 09:09:40 +0000 Message-ID: <877cpzl357.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9311"; 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 11:10:10 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 1qV76w-0002Fm-4G for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Aug 2023 11:10:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qV76A-00046c-FF; Sun, 13 Aug 2023 05:09:22 -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 1qV768-00046B-RF for emacs-devel@gnu.org; Sun, 13 Aug 2023 05:09:20 -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 1qV765-0001me-Rm for emacs-devel@gnu.org; Sun, 13 Aug 2023 05:09:19 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 89C12240028 for ; Sun, 13 Aug 2023 11:09:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1691917755; bh=JBHnzCnQ/OddGlZDmHQx6YZoHtsJ5JrUV6C+j+uh2O4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=jLvB2+jHLpueGPbkd+cu/7de67OqNnbRjpz+u+xalMfb0tWf8KU+I8eMzghV7+lBg CxgLHRX+U0BnPo4wrm5CMJZ9XMEhAblSuYVTPPQHZiDQM401DXUG2hXTSUsFMVo2/L M8nrlvhBm1DDpZP91/p9xuZAlkoMfKMeQQiBHLcDQDzkA/CfR75i6i9uaGcV/BwfoL 4w/NfRLKYCmfP5l+ET0BsSOaiNMtiGu8RmnXvAmhmhscVi6Zsr4vMIUYZDc+uEz8Pa ywMf/7B63vLMkm3deKT/lN6XCEitLCDavt6qZZ35RuwpzU4TKUq0cKo4MxiDXGbFLY ugu+g2JUciMWw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RNsCt61K6z6tw8; Sun, 13 Aug 2023 11:09:14 +0200 (CEST) In-Reply-To: <871qg8l03q.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:308658 Archived-At: Emanuel Berg writes: >> It tells that normal int operations are much, much faster >> compared to bigint. So, your benchmark is rather esoteric if >> we consider normal usage patterns. > > Didn't you provide a whole set of benchmarks with an > approximated gain of 10%? Maybe some esoteric nature is > built-in in the benchmark concept ... 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. 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. 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at