From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sat, 15 Oct 2022 10:10:23 -0400 Message-ID: References: <87ill8paw7.fsf@trouble.defaultvalue.org> <83o7uzivey.fsf@gnu.org> <3ac9d2b9632f75018327a1bcde0c373f152c404a.camel@gmail.com> <835ygob7ja.fsf@gnu.org> <8335bra2rl.fsf@gnu.org> <87ilkncugg.fsf@gnus.org> <83zgdz7x8u.fsf@gnu.org> <83leph7e4c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006b239605eb134e40" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25216"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Andrea Corallo , Lars Ingebrigtsen , liliana.prikler@gmail.com, rlb@defaultvalue.org, emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 15 16:11:31 2022 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 1ojhsx-0006Ny-0y for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 16:11:31 +0200 Original-Received: from localhost ([::1]:47992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojhsv-0005Bd-HN for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 10:11:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34418) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojhs8-0004T3-Ch for emacs-devel@gnu.org; Sat, 15 Oct 2022 10:10:40 -0400 Original-Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]:36552) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ojhs6-00021k-ES; Sat, 15 Oct 2022 10:10:39 -0400 Original-Received: by mail-pg1-x52a.google.com with SMTP id s196so5413526pgs.3; Sat, 15 Oct 2022 07:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hzl7TV1VKfigM+zgderqLQPnPUhGUV1cF1+l/DVOK7Q=; b=FsmTsYsfyDNcTNd0YFlIhaF3sxvVhF9hVRBlS1m1XFYL4Zd0RLRuANNndmoV8nuK2N 5l40woPCDsQVTQq7B03d9gW+P7SiWPx6/v7WeNMaiFWIx5MMk9Y1WQJw+BdiUJRIeuMV YNWZ5Wxad7jpb1DZUQauvsidVDRTekY0bUkgp0E+SkrRVJampjaSBZAdsc2y9YmiwNoA BQbeqDvrmGZvK/GmuerCtpY61Oac6S6egHju3xdxIKvc9g77jcgtYZRCXoYHU/tMuj7J cUy+o7EXP8HPXdDPv01pgbder2vwGnuNBC/xFFQ6WVTttu1O8pBABmWGSOMXmAA9LjNL 807A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hzl7TV1VKfigM+zgderqLQPnPUhGUV1cF1+l/DVOK7Q=; b=1kmLE/HWjN9CQ6fNiCQEFAol5hvooeIUMha2IyZ+jTuqa9SaH8pyUYaY2c9j1R3NEL T5REfFsHupTR0xlOn2ZeNdIz4y+ZFwORWxfD8wqcJZhia3W8ZsdzfiwTVCefFqpsG5Vn hElQU8dM+7JW7tYCKdJza+9w5fSwHOg6VeXddWFVF1+tK6KtU8Yr7QKuSnyOTzN9qmS3 I0Ft+Fvq5naMKrL8UzNKT+ZZdXh8FHsV94g870zzbZRbW6BNsthxEj28ymgV7JYeEipp KEsE3K4YhODZtjqKqwc7W0jTC0JaTmshOqgDFDR9yElzgaz2GUYHEgpHx1GqOLJ4lsQc Q6hA== X-Gm-Message-State: ACrzQf22FxCsgqWOyucnWLoIfrTvewqixBNAOuXyNFyv2s6w9kf9zKr7 Ib5PqohFaFzO9ZM70XyYcrTWj+D40xAW+zmriXw= X-Google-Smtp-Source: AMsMyM6UgPbeMQFimpP5yPO9UaOXXjkaVe6U9HYmtZeyXOkaID/bPT9AYQ9Kerf+kPuWYmr0ROEs5eYnCt+3Pwqc9hU= X-Received: by 2002:aa7:8686:0:b0:565:8597:40e with SMTP id d6-20020aa78686000000b005658597040emr2989306pfo.35.1665843036102; Sat, 15 Oct 2022 07:10:36 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::52a; envelope-from=owinebar@gmail.com; helo=mail-pg1-x52a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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" Xref: news.gmane.io gmane.emacs.devel:297777 Archived-At: --0000000000006b239605eb134e40 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 15, 2022, 10:02 AM Stefan Monnier wrote: > > > I don't think we should depend on architecture-dependent code. It > > would mean we don't support new platforms until someone writes such > > code for them, for starters. It's against our development tendencies > > for the past 10 years at least. > > I know, I know. From a technical point of view, it's The Right Thing to > do, I think, tho: it will eliminate all the other issues surrounding > trampolines (e.g. disk space to store trampolines, dependence on > libgccjit for the creation of those trampolines, fork bombs) and will be > much more efficient both in CPU time and memory use (we don't care too > much, because trampolines are hopefully not too frequents, so we live > with them being quite inefficient in the time to create them (and set > them up, via dyn-linking) and in their memory use). > > But yes, the architecture-dependence is a serious problem, which is why > we've so far avoided that solution. Didn't you, a couple of years ago, suggest generating generic trampolines (per function signature), compile those with gccjit, then just use them as needed rather than compiling separate trampolines for every subr? Presumably the system would still occasionally need to compile a trampoline for a new signature, but the generic trampoline would not be named so it couldn't cause an infinite recursion by being advised before being compiled. Lynn --0000000000006b239605eb134e40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 15, 2022, 10:02 AM Stefan Monnier <monnier@iro.umontreal.ca> wr= ote:

> I don't think we should depend on architecture-dependent code.=C2= =A0 It
> would mean we don't support new platforms until someone writes suc= h
> code for them, for starters.=C2=A0 It's against our development te= ndencies
> for the past 10 years at least.

I know, I know.=C2=A0 From a technical point of view, it's The Right Th= ing to
do, I think, tho: it will eliminate all the other issues surrounding
trampolines (e.g. disk space to store trampolines, dependence on
libgccjit for the creation of those trampolines, fork bombs) and will be much more efficient both in CPU time and memory use (we don't care too<= br> much, because trampolines are hopefully not too frequents, so we live
with them being quite inefficient in the time to create them (and set
them up, via dyn-linking) and in their memory use).

But yes, the architecture-dependence is a serious problem, which is why
we've so far avoided that solution.

Didn't you, a couple of years ago, s= uggest generating generic trampolines (per function signature), compile tho= se with gccjit, then just use them as needed rather than compiling separate= trampolines for every subr?
Presumably the system w= ould still occasionally need to compile a trampoline for a new signature, b= ut the generic trampoline would not be named so it couldn't cause an in= finite recursion by being advised before being compiled.

Lynn

--0000000000006b239605eb134e40--