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: Shrinking the C core Date: Sun, 20 Aug 2023 07:14:42 +0000 Message-ID: <87jztqdw2l.fsf@localhost> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <87fs4pkkqi.fsf@dataswamp.org> <87jztzkgct.fsf@dataswamp.org> <87y1if8j8t.fsf@linux-m68k.org> <87y1ifi9fv.fsf@dataswamp.org> <87zg2uqdmv.fsf@localhost> <87edk3gbh3.fsf@dataswamp.org> <87jztvnuyb.fsf@localhost> <875y5bdutt.fsf@dataswamp.org> <87y1i6e1uh.fsf@localhost> <874jkub40o.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="10974"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Emanuel Berg , "Alfred M. Szmidt" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 20 09:15:20 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 1qXcee-0002ek-5v for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 09:15:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXcdh-0007rW-72; Sun, 20 Aug 2023 03:14:21 -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 1qXcdf-0007qx-S6 for emacs-devel@gnu.org; Sun, 20 Aug 2023 03:14:19 -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 1qXcdc-0004og-Um for emacs-devel@gnu.org; Sun, 20 Aug 2023 03:14:19 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id AAF29240028 for ; Sun, 20 Aug 2023 09:14:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692515654; bh=vpmex9Pq1T1R2e9EFTi8rJQz+rDbJypa6O2o95k9UjE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=GZKRmFfOh339EyNXBByNVXrQF6m3X+dWJd+3wPvsp05lLbzm7KDqOW8zsYNKy/EF+ 9y3ZnNLcymzsYRWA+Sk1fwYiVtZG2rOaoq0YZl8GBT0IiYwtb0OWg2vnBAxznWf7PD NjM4Fe5UOiy48uenKezdn1tvrkp+zS3c7Qt4rjDAjB15rSYjvUdVJczVlkRdXIHCg2 iX3L98YROmacBCheuiN+uPxD4ClAmqZhzRVulE8xc5WpH5DDKX5y/Q6pVaJSjy98rd LcpakJyV5Y5ZClr55LhgoOEcE8lIOY0O40kRdiRE7G869+Ip3hQ/5bCDs9vy1WQHBz x0OAWXcvnktSA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RT6Ky0L9Zz9rxB; Sun, 20 Aug 2023 09:14:13 +0200 (CEST) In-Reply-To: <874jkub40o.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:308954 Archived-At: Emanuel Berg writes: >> The discussion about floor started from Alfred using `floor' >> as an example where CL uses system-dependent optimizations >> and thus being much faster. > > So the answer to the question, Why is SBCL faster? > is "optimizations". And the answer to the question, Why don't > we have those optimizations? is "they are not portable"? Looking at https://github.com/sbcl/sbcl/blob/master/src/code/numbers.lisp#L390, they employ certain x86-64-, x86-, ppc64-specific optimizations. Althrough, Elisp's rounding_driver is not too bad actually. It also does shortcuts depending on the argument type. AFAIU, the main difference in SBCL vs. Elisp is that Elisp type checks are often called repetitively on the same values. Even though the checks are rather fast (typecheck is usually just a single xor + equal operation), repetitive calls do add up. And even this is not a definitive answer. I do not think that we can point out a single reason why SBCL is faster. I am not even sure if SBCL is _always_ faster. > But isn't that what we do already with compilation and in > particular native compilation, why can't that add > optimizations for the native system? If we talk about type checking, Elisp uses dynamic typing and compilation cannot do much about it. Native compilation also does not touch C subroutines - the place where typechecks are performed. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at