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: Mon, 21 Aug 2023 03:52:30 -0400 Message-ID: References: <20230809094655.793FC18A4654@snark.thyrsus.com> <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> <87jztqdw2l.fsf@localhost> <87msym9i4r.fsf@dataswamp.org> <87a5ula1zt.fsf@dataswamp.org> <87jzto6hct.fsf@localhost> <87bkf06enk.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22671"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Mon Aug 21 09:53: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 1qXzix-0005cY-CV for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 09:53:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXziD-0000ts-98; Mon, 21 Aug 2023 03:52:33 -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 1qXziB-0000p9-Fs for emacs-devel@gnu.org; Mon, 21 Aug 2023 03:52:32 -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 1qXziA-0001e7-FK; Mon, 21 Aug 2023 03:52:30 -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=WPvuh4rApJXU46s+sTUqj41J7leYqQLBbQ0L90cdLoE=; b=gVNYNwBM0Q6/ fK/kCxrQ5XljzjYXa00bOemloIMI/fTaEwLTRWGYFBA95Wl8QD3XZcQdhbbmPDJCBHpzjjv5qlgv0 twsMq8/CwJ35Ii0WNstBnDOpdlr6dmWV1VXlgpW8LygoiLhhELaoJb0PDPT37hdKlV0UPW7sZ0eE+ 4eA29f4yHtudlRzmKZv8WdLGaEkpHlcz/F+U/W3p0UrapjJt79oRx3fO2RjtnFjKpwP3fuQgRjy7z sJuOY0I+oz96Er0vSqDDE6afgd5LXJWGrjzclTyPHvyQUVuEGYc/7FnLSdd+cIl9P9PIQ+OoOENGS jTya+rjfnpZ93CtyFE36NQ==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qXziA-00022E-90; Mon, 21 Aug 2023 03:52:30 -0400 In-Reply-To: <87bkf06enk.fsf@localhost> (message from Ihor Radchenko on Mon, 21 Aug 2023 07:25:03 +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:309035 Archived-At: > > ... In Lisp you > > never know the types of things. > > This is not true. > > It is absolutley true, you cannot know what the value of a variable is > without checking the type of it at run time. Variables have no type > information. What about (progn (setq x (list 'a 'b 'c)) (listp x)) `listp' call can definitely be optimized once the compiler knows that `list' returns a list. A sufficiently smart compiler would optimize that to T sure, the Emacs Lisp compiler doesn't. And that is one of the issues, native compilation or not, since right now native compilation gets this to work with, and it cannot do magic no matter how much magic dust you give it. byte code for foo: args: nil 0 constant a 1 constant b 2 constant c 3 list3 4 dup 5 varset x 6 listp 7 return Native compilation will not help you when you need to figure out what is to be done in: (defun foo (x) (assoc x '((123 . a) (456 . b) (798 c)))) E.g., to call ASSQ instead, since it is just fixnums, and ASSOC uses EQUAL which is "slow". The Emacs Lisp compiler cannot optimize that code today, and native compilation will get whatever the compiler produced, with the call to ASSOC no matter what. That is what it means to optimize Lisp code.