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: Ideal performance of ELisp Date: Wed, 17 Aug 2022 09:04:48 -0400 Message-ID: References: <838rnxvdcq.fsf@gnu.org> <83r11ptksn.fsf@gnu.org> <83a68dti6w.fsf@gnu.org> <874jykzvx9.fsf@yahoo.com> <83fsi4sttn.fsf@gnu.org> <838rnws5c7.fsf@gnu.org> <838rntocb8.fsf@gnu.org> <875yiw92p2.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15519"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Ihor Radchenko , Eli Zaretskii , luangruo@yahoo.com, acm@muc.de, emacs-devel@gnu.org, casouri@gmail.com To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 17 15:06:57 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 1oOIl7-0003qQ-BK for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 15:06:57 +0200 Original-Received: from localhost ([::1]:56502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOIl6-00068v-8H for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 09:06:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOIjJ-0004gL-Fk for emacs-devel@gnu.org; Wed, 17 Aug 2022 09:05:05 -0400 Original-Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]:45783) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oOIjH-0000ug-Jk; Wed, 17 Aug 2022 09:05:05 -0400 Original-Received: by mail-pl1-x630.google.com with SMTP id u22so3690169plq.12; Wed, 17 Aug 2022 06:05:02 -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; bh=pSb2RdRbfKOPbCpRSr4hauhI3XzXLf7JDVAG2ENMXME=; b=F3FRMxGTs2vBi5Q9/1wOgyVzD8R2hZtNxLm0TLy2Qn4EE7/EKoNs2+SkNBEqCl09IU Chq9N9ZgD36f1udIBRn11SQ0h1EBxqUUTdcoWHk9esHk7qwAZECWrBoMRNKFXRP+/eBa hlGglCF3VjNPEcHtXRSTJxxkHXaGys7mbYbGN7DqAsBZ4nomzxcT+jgOSyFT8sPGr6SZ BnebImm6dmjlLk2d+uvRCBnqLO/X9tZVjPWSHKem7tyuAFC87Q86oPCNCPuDo/TzLezf Al2iLd3F8KLOQTpaPV8B4ACfGQ2IRVKgj6WwqVVeDcus4zRM9D/qlcp+4bkKbwe7ktXv uEFA== 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; bh=pSb2RdRbfKOPbCpRSr4hauhI3XzXLf7JDVAG2ENMXME=; b=6pCKYbmufE89ucvjNFuZszITvu190dfU6UAJ/GRlnA4sOG2+0SVc4tF8ajCEwgalfq 39GB8LISg+XTyUHG9ljzo8mK69NM8vbXoK04+rjdHKXWJ6Bap+NTSPC5wVRXxsrcflZP 94uaZWxAcKqLV58RVy5UNObrYDKZlRJ9cvn7bMnKGh1qEhVykdbTTiH507t7kimkIq78 7nz8nsJd6YGQ3gz4Cv+nGN+r0Cm4UuRwom+mLiFytwrULdIyvxIS7hr7tKQmpiezTPOh 2mfpIr+v3Ej3qJYFIly3hyeaY8K/NYa9a/yFbUFlLxe2Bg3dji06kIpnqMD7DZLTXT6p f/Pw== X-Gm-Message-State: ACgBeo1ORiBLmAYo+gDXMd0iU3SfAsYTJZCw5/3OxVGmUvkr3WtTq31e 9IPxkYA3zXpe1ODJ8Q8I3vU5+K6Kkp9wYQ2g2pU= X-Google-Smtp-Source: AA6agR6wYY0/ZxVuNX7cFs0dG9vX8ECWldieVcQYApMuZYnfW6+8pymps1jNIHOlVtesBSct/hSplVJ4Zf1gN+gbppU= X-Received: by 2002:a17:902:ce11:b0:172:6f2c:a910 with SMTP id k17-20020a170902ce1100b001726f2ca910mr14743786plg.156.1660741501449; Wed, 17 Aug 2022 06:05:01 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::630; envelope-from=owinebar@gmail.com; helo=mail-pl1-x630.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:293556 Archived-At: On Tue, Aug 16, 2022 at 2:24 PM Andrea Corallo wrote: > > Lynn Winebarger writes: > > > On Tue, Aug 16, 2022 at 4:59 AM Andrea Corallo wrote: > >> > >> Stefan Monnier writes: > >> > > > > Ugh. Why not inline LAP blocks? > > You could inline LAP or even LIMPLE relatively easily but I don't see > any perf opportunity to take advantage from in doing that. I suppose it depends on what type of instructions/machine model are operated on by the respective IRs (there's no spec for Emacs LAP code). Assuming one of them allows you to operate directly on machine values, without any implicit type-tagging/untagging, then you should be able to do all the same kind of abstraction-breaking-but-difficult-or-impossible-for-the-compiler-to-prove-safe operations that C code could perform. That is the point of the proposed feature, isn't it? Assuming LIMPLE is required, I'm not sure how the feature would be incorporated for users without access to libgccjit. Perhaps an additional byte-code operator like "execute-limple-insn" could be implemented that would support a set of supported "unsafe" LIMPLE instructions? Lynn