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: Mon, 28 Aug 2023 11:27:03 +0000 Message-ID: <877cpf2yrc.fsf@localhost> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <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> <87h6ot7cf3.fsf@localhost> <87edjx7c0b.fsf@localhost> <87jztfrd6v.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="29004"; 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 Mon Aug 28 13:27:30 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 1qaaP3-0007I2-Sg for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Aug 2023 13:27:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaaOK-00084o-Nu; Mon, 28 Aug 2023 07:26:44 -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 1qaaOH-00084f-GF for emacs-devel@gnu.org; Mon, 28 Aug 2023 07:26:41 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qaaOE-0002bJ-Tr for emacs-devel@gnu.org; Mon, 28 Aug 2023 07:26:41 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id BB832240104 for ; Mon, 28 Aug 2023 13:26:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1693221996; bh=LehxDIj4YygSmJBbbxvfgLhONMo9gdw0gS3h5TXWRKw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=e39kdZgqV4mEyXxiXEwAYhMKvdlKb5oDZ0Gu2Fcji0wb/2TBm4q+W37c5NhRUDqY/ YYdHagfA6evaaofQ8PISSaofnMNkwzxsorN962JNMB/IwUnqjNGx5KAqj/NmZZDtsM wTrM2gdGqEcDGU3bxvR7wHtnjHffhfEg+9LrsGbFLINv+mUmsfbvP16s0yC/LJMsSx sGhR9L33NaHZsDzjZTNmPW5Hd5FcxEXkldXUn9XeETZIFgIiKUSpQSVb7CM/OesQzh 7JPJ8iL947uH8akLtDTuQLQXfkUsfGTcd/Kb4+QtENCSe9wBTiRxE2/rAB9Y2b2CzL mztj6WSfgkVGA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RZ7YN6SFfz9sFZ; Mon, 28 Aug 2023 13:26:32 +0200 (CEST) In-Reply-To: <87jztfrd6v.fsf@dataswamp.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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:309425 Archived-At: Emanuel Berg writes: >> During native compilation, if type information and n and >> d is available, GCC might have a chance to cut a number of >> branches away from the above code. > > Does this indicate a tendency where one can foresee a future > where Elisp is as fast as C to the point C could be > dropped completely? No. Low-level memory management must still be in C. And some performance-critical that uses internals for efficiency. For example, `transpose-regions' directly modifies internal buffer array holding byte stream of the buffer text, suing memcpy. There is no way this low-level structure is exposed to Elisp level. (Otherwise, bad Elisp can simply crash Emacs). > Still, I wonder if those typechecks in C really slow things > down to the point it matters. Maybe for really huge > number-crunching computations? As with many other things, it depends. We saw for bignums that typechecks are taking most time. Typechecks also take significant time in fib benchmarks. However, for example, Org parser spends most of the time in Emacs regexp engine, not in typechecks. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at