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: Thu, 18 Aug 2022 08:17:02 -0400 Message-ID: References: <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="8401"; 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 Thu Aug 18 14:19: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 1oOeUk-0001xc-6a for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Aug 2022 14:19:30 +0200 Original-Received: from localhost ([::1]:38214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOeUi-0000XE-E9 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Aug 2022 08:19:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50398) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOeSf-00083v-0S for emacs-devel@gnu.org; Thu, 18 Aug 2022 08:17:25 -0400 Original-Received: from mail-pj1-x1031.google.com ([2607:f8b0:4864:20::1031]:41782) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oOeSd-0000sL-7K; Thu, 18 Aug 2022 08:17:20 -0400 Original-Received: by mail-pj1-x1031.google.com with SMTP id t2-20020a17090a4e4200b001f21572f3a4so1683768pjl.0; Thu, 18 Aug 2022 05:17:17 -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=xP/swimujm+rbLiRXMGlu8RQVwsFn4fWdXki7vpdsi8=; b=DDZwpMe5j+VboAPcvbzB3tDNFP01gF1wJ/CvT4Zrojrq4nRnLTynsl/Eeak1cNI33C 5Oqmvml/xwHKAsSNdG3UH/y9Oz6EMmqHZQqwXixGe9Mztw0/e1YfT97EM07Awq1Dcoy4 XB7+3HAadzCMgPIK1QJx0IvUVx81NeZxj1X5ETAwsqjc3QyZOnicDZrQaM4SmglDfC5x 7IDQvOeE1AaIFYL+I3FaLcvlNIFk932x7SJmSsjFSLVwLyYjuPOTqtvE0uiY2ooM4O9w V4OT74pVl4uW/ztoo2ZdARLEebU/twy3RNhLlSlNtXkCrY9npCmuQlqTLgN3TmadkJNs BrMA== 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=xP/swimujm+rbLiRXMGlu8RQVwsFn4fWdXki7vpdsi8=; b=2cvMUU4Il8dUNIDc2yoqus+vVOmco3oCB6IRLKeAr5MFNq+Wztp8tI21o9Oolih/OM 0NkEgNSoltUY+6vObT+8lXo353pK00VFenZR+K53daMAZQ8oP6oIwfMbV6rG6oLJ2Sq5 LirCUkhC8Gt8jHA1ruYGrwrpNIGwIJJ0fQqGMPr0RtnG1WQ33NMfejvYy4tr5Xwgs4RQ bD4B+7Y39vLrA815oF3IGYem958CQgGPsdZ0IkkxgfuaYvyy6lU1xSUlOlh3iObZIj8s 333EAq3G0ZT2nSlbirGToKLioa7wQVdVaqvFA0i1EuWiXnYIDQxaDSifa9snt2rnwuRs DUSw== X-Gm-Message-State: ACgBeo28+hT3DJRxUUlSA2TsYGPLGHdwSMp+WyI4H1gSUpaKw64SodIl jx6flPkhPV62PAnZzrGDxobtNFziBtDsgtKYj7c= X-Google-Smtp-Source: AA6agR7Bz6ZDz1tgFZPv8zWM/+l7HO8ZyY/KeH3NvamW5x0jUVcJGRGTCMhbO3mK04k6Mac7w/f2eiIqUAiYUb66c10= X-Received: by 2002:a17:903:50e:b0:170:d829:b3bb with SMTP id jn14-20020a170903050e00b00170d829b3bbmr2306886plb.93.1660825036923; Thu, 18 Aug 2022 05:17:16 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::1031; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1031.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:293601 Archived-At: On Wed, Aug 17, 2022 at 10:18 AM Andrea Corallo wrote: > Lynn Winebarger writes: > > > 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? > > ATM LAP (apart from some exception) relies on calling primitive > functions, those do not manipulate unboxed objects. > > But yeah in principle changing LAP, exposing it and exposing through a > number of functions capable of working on unboxed objects might be > useful for writing some optimized code, *but*... > > ...this is a ton of changes for what? Having an non easy to use DSL > that is capable of optimizing only some very specific case? The original question for this subthread was around whether there could be a way to inline C snippets in Elisp the way assembler (usually, and in an implementation-specific way) can be included in C programs. Assuming that any such extension would have to provide a meaningful semantics for users that don't have libgccjit, it seems a lot more useful to me to define access to the equivalent of assembly language in a way both implementations can make use of it. Then anyone can layer a DSL targeting that core, whether for a C-like syntax or whatever, and get defined behavior on all platforms Emacs supports. I mean, *if* you (or anyone) were going to implement low level facilities, I'd rather end up with something like this I could use to extend or replace the compiler dynamically than some partial recreation of C semantics, for whatever that is worth. I'm not suggesting it should be the first on anyone's list. OTOH, as you noted, providing the ability to inline LAP or LIMPLE is relatively low-hanging fruit. Then it would be on whoever wanted to use that facility to implement any extensions required to do so. Anyone who is using such targets is pretty much declaring that optimizations by the native compiler passes (other than those by/following libgccjit) are of no interest. > Don't want to sound harsh, but the thing about these discussions IMO is > that typically is more about writing the longest and last mail in other > to prove to be right, more than implementing real changes and > improvements. I'm not a big fun of this, my personal preference goes > for seeing a definitely higher LOC/discussion ratio. You're entitled to your preferences, but the last word in these discussions is what's checked into the code base. And, unfortunately, due to the nature of employment law in the US and the expense involved to verify the enforceability or non-enforceability of broadly written contracts of adhesion by employers, I am unable to contribute any LOC for the time being. OTOH, the same lack of value you see in discussing design points is what allows me to engage in them. It's an odd fact that usable code might be claimed as IP, but merely describing the required modifications (so long as they only involve publically available software and well-known techniques apparent to anyone with the appropriate expertise) isn't subject to such claims. Or, at least, I'm not willing to countenance the possibility that such an act would be subject to IP claims or ownership by an employer. So the best I can do is try to clarify any misinterpretation of what I've written (presumably due to non-intentional opaqueness on my part), or correct errors in things I've written. As a general rule, I prefer to ask people about why code is a certain way, or what their preferences are for solving a particular issue, before embarking on extensive rework of a piece of code. I can, have, and do speculate on what their answers might be based on the code as I work with it, but I just think it's better to simply ask and let them speak for themselves than to reverse-engineer (potentially incorrectly) their intentions. Personally, I'm a little discouraged that I've reported issues that have been ignored or dismissed, then see them discussed later as though they were a surprise. I assume it's because the maintainers don't know me from Adam, and my discussion points are on the idiosyncratic side. But I'm contributing what I can at the moment. Lynn