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 19:15:44 +0000 Message-ID: <87h6ot7cf3.fsf@localhost> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30987"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: "Alfred M. Szmidt" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 20 21:15:58 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 1qXnu1-0007tD-A5 for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 21:15:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXntW-0001Ww-Js; Sun, 20 Aug 2023 15:15:26 -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 1qXntU-0001Wg-6A for emacs-devel@gnu.org; Sun, 20 Aug 2023 15:15:24 -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 1qXntR-0006u5-C9 for emacs-devel@gnu.org; Sun, 20 Aug 2023 15:15:23 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4BCDB24002A for ; Sun, 20 Aug 2023 21:15:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692558919; bh=0MtmK9Jcs0ER5bW4Yt8gWNwWA4PcYUGid7pTHgQ/HdQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ScDfTtZfpcKoIEPKms/wsi0l9Ve22SiXAlcuRO4aLiwu0G8QrYdpdLiQtLS7+MUeU tY5Q3E2CJVxa6IpBRSjfsCJm30vOQfdizowcdDfb3+WJ3CGVhqmJaZEq00xGA2fa6Q tDT57JcI+rk8IhIhmXqjO3kDZK27bL5usxYoHUxmUcI3Do6BclD2efkuUTKryyqZWv CuNUmxYaJErxLleSqKPNgNPv7i6tJB/+rkE4l+/WRfsc4yG5vrj+HpxR5TVDKviWkc gC/rV1JQ/2Yq/VgeGBgQPKKnhxp3lx1gARCsoj8CVZiykNhYxkyOruWzKd1Tnh5MHC qs2/asu5lR0fA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RTQKy4R32z9rxB; Sun, 20 Aug 2023 21:15:18 +0200 (CEST) In-Reply-To: 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:308987 Archived-At: "Alfred M. Szmidt" writes: > 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. Native compilation provides the necessary information about Elisp to GCC. Otherwise, native compilation would be useless. You may check out the details in https://zenodo.org/record/3736363 and https://toobnix.org/w/1f997b3c-00dc-4f7d-b2ce-74538c194fa7 > 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? At least some of these questions are answered by the code on Emacs side. Native compiler transforms the Elisp byte code, using its knowledge about function purity, types, and maybe other things, into LIMP that can be fed to GCC JIT. Then, GCC JIT uses the provided info to do actual optimization. > 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... AFAIK, users cannot specify type info manually, but types are tracked when transforming Elisp byte code into LIMP representation. The only problem (AFAIU) is that GCC JIT cannot reach inside subr level, so all these information does not benefit Emacs functions implemented in C. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at