From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Ideal performance of ELisp Date: Wed, 17 Aug 2022 14:18:40 +0000 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35292"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Stefan Monnier , Ihor Radchenko , Eli Zaretskii , luangruo@yahoo.com, acm@muc.de, emacs-devel@gnu.org, casouri@gmail.com To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 17 16:21:09 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 1oOJut-0008tT-Lr for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 16:21:07 +0200 Original-Received: from localhost ([::1]:57528 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOJus-00027u-P3 for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 10:21:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOJsk-0000aR-61 for emacs-devel@gnu.org; Wed, 17 Aug 2022 10:18:54 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:51189) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOJsh-0001T5-Iv; Wed, 17 Aug 2022 10:18:53 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 27HEIePE029541 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 17 Aug 2022 14:18:41 GMT In-Reply-To: (Lynn Winebarger's message of "Wed, 17 Aug 2022 09:04:48 -0400") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:293562 Archived-At: Lynn Winebarger writes: > 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). LAP ATM is defined by the current implementation, so when we talk about that this is what we refer to. > 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? I think there are better ways to improve in this area. 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. Andrea