From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Sun, 20 Aug 2023 14:54:46 -0400 Message-ID: References: <20230809094655.793FC18A4654@snark.thyrsus.com> <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> <87jztqdw2l.fsf@localhost> <87msym9i4r.fsf@dataswamp.org> <877cpp914t.fsf@localhost> <83fs4dwwdo.fsf@gnu.org> <874jkt90a5.fsf@localhost> <87y1i57jqi.fsf@localhost> <87pm3h7h8k.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 20 20:55:45 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 1qXnaS-0003lT-0A for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 20:55:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXnZc-00050q-Fr; Sun, 20 Aug 2023 14:54:52 -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 1qXnZX-00050M-Ve for emacs-devel@gnu.org; Sun, 20 Aug 2023 14:54:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXnZX-0002mN-Gt; Sun, 20 Aug 2023 14:54:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=lZHi2smJImeujwPdPZhMDhlFKF2q2xhGi1DKQBStkyw=; b=F15BgLELsGUY hvvWcOtqA3Tx43sO/FCDW7XfTjcNkyNXyEESZdDlXNhVrARGhJr/rK1GqQ8/sZ41BhBzYEgvTvo4x Elx1YXa3vc6kOlxVfYPnelyacS9PWXqUehSFSy30XOwlkPCA/47f6AkBCFkwMtl929NqppLWLhDWx g8sEPJgF+tHuFgINFcwavwkc6PDtu6Bn9j2iK+nV8MBIF++o/RT/dCEu68KusTMzw5GIROHIZE65d whS89nCOFfjtTU8F/nz3pxU6JnPSA6dy4N3omekjVZqcZ26fS+cDrd10bmMv39RMF9ndDrbwBVGFK 9dlbvbuaCkRhJ2ZaWsjFxw==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qXnZW-00006Y-S0; Sun, 20 Aug 2023 14:54:47 -0400 In-Reply-To: <87pm3h7h8k.fsf@localhost> (message from Ihor Radchenko on Sun, 20 Aug 2023 17:31:39 +0000) 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:308983 Archived-At: "Alfred M. Szmidt" writes: > Not really. Native compilation already uses GCC. At least on the byte > code instructions and, separately, in subr code. > There is more than just GCC vs byte code VM in it. > > It is not about native compilation! It is about what OPTIMIZATIONS > can be done to the actual code flow. Just using GCC doesn't do ANY > optimizations to how the Lisp code is optimized or how its flow is > changed due to optimizations! Then, what does GCC do? AFAIK, GCC JIT takes the Elisp byte code, transforms it into JIT pseudocode, and optimizes the actual code flow. What does GCC do _WHERE_? What backend? What language? You're speaking in such broad terms that it makes it impossible to continue this discussion. I don't know how the native compilation works, but no matter what you feed to GCC it cannot do magic and any optimization should be done on what the Emacs compiler does. For example, when I write (when (> x y) (when (> x y) x)) I expect GCC JIT to throw away the duplicate comparison. Why do you expect that? Why do you think it is duplicate? Where are the guarantees that > or WHEN don't have side-effects? Do you know the exact type of X and Y so you can skip a cascade of type checks to pick the right comparison operator? Can you use fixnum comparison of a specific bit width? Do you need to use bignum comparison? That is the type of information SBCL knows about, or allows the user to specify. Emacs does not have that today, and that incures one set of overhead. There are plenty more...