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 10:25:52 -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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000013e94f05e670a5bb" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25248"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Po Lu , Alan Mackenzie , emacs-devel , Yuan Fu To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 17 16:27:07 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 1oOK0g-0006Ni-Q5 for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 16:27:06 +0200 Original-Received: from localhost ([::1]:35042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOK0f-0002B2-NQ for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 10:27:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOJzj-0000tN-8H for emacs-devel@gnu.org; Wed, 17 Aug 2022 10:26:07 -0400 Original-Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]:35348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oOJzh-0003F1-H5; Wed, 17 Aug 2022 10:26:06 -0400 Original-Received: by mail-pj1-x1034.google.com with SMTP id m10-20020a17090a730a00b001fa986fd8eeso1994984pjk.0; Wed, 17 Aug 2022 07:26:04 -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=kiXrynYzU6V424W7nPHKUGqWqtOkf2Z23OadBuN0ui4=; b=MCsAJta1Eh/30m9Q2myiHOSdd7mcVIwo4hNGuq/FsA2EOUtcrA9WBb2cugILpgQZMB qGTiqHOY9kR0am0f9ghgQFIC0NqrRk8/09vGH4OmETHZ52DLLsqRKzZZOAJ4gQZQhV6e eLSnULys+Tw5Z+L9EYSaUV/B3UzLEpUak5qH9Rou1raHZhHffLS1/WAPv81ep8JpFTWu dUv6G8OBB+1dUIPtV2AueSGc5NR0Q9PS5V1aqVr0wt/HPl6inQtXahmvqqizKYZIBfAe sTSqH42SPJe039j/iYXX+uR0/BdPZQBAZkZxlTJZ7SLPWXBO6VEdB3zHMbC4+p8xUSmX tZIA== 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=kiXrynYzU6V424W7nPHKUGqWqtOkf2Z23OadBuN0ui4=; b=1SLddGg3z/EaioAcGnCmfkDePbIe262CO4RO/OWWFEnImKmfm88mC0iVita3ndSgTn zMTDDkHKU0F5KHVTXpOp9d1j/kTVlC0+6+JXVMRCUy+S2OPAdkLDwAvUjAN8dC2oUPtb t2/MDu/FQ5ysGxiS5TfbQjN/9b0jqZ4T9WkN5sHJwNd1cEMJb5TlDiLF7J9GAq5g5hmR 1q8VLGU6mRmPA7N6/ZPDJVlcupta0Um3i/uiiJ/xt2USkNeD5nznB14NjDfN1E2O90Kz IcFSP9O7j1eLGmPPYJk+5Ukv0sMlJOFpMaVQd4TScFB73n+frkJ4/a2GgvoUCukVmiLC 72rQ== X-Gm-Message-State: ACgBeo2r+wj2uuZB1NZF7RwFyvXI06vuiv2GPJEOZAJKSNFLKs312str MqwpP6wBSPq7f+1u5tv8RjHbhnzdvzfUOsOIAdI= X-Google-Smtp-Source: AA6agR5v8zVhRbTf3gvRZHMMVcmceJCe5rASZ+JX5Rdg/KxfH6cx8/sa2kNc6vMphTyWsG80aJClgzcPXTdtxYm0R84= X-Received: by 2002:a17:903:50e:b0:170:d829:b3bb with SMTP id jn14-20020a170903050e00b00170d829b3bbmr26215555plb.93.1660746363823; Wed, 17 Aug 2022 07:26:03 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::1034; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1034.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, 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:293565 Archived-At: --00000000000013e94f05e670a5bb Content-Type: text/plain; charset="UTF-8" On Wed, Aug 17, 2022, 10:04 AM Stefan Monnier wrote: > >> Not sure how well it works for very large tables where we risk bumping > >> into the 32K limit of bytecode jumps. > > That did occur to me. > > Perhaps one way to address that limitation without completely > > overhauling the VM would be to introduce a form of segmented memory > > for byte strings. > > IIRC the limitation is only in the size of relative jumps, so we might > be able to fix it just by adding a new "longbranch" instruction, The issue there is that (IIRC) the relative branch opcodes haven't been used since v20, and are marked as obsolete/slated for removal. So, the compiler would have to be altered to use long branches initially, with some later phase replacing them with either relative or short absolute branch codes currently emitted if applicable. The trampoline extension wouldn't require alterations to any construct that is already correctly compiled. The other potential bonus of the trampoline approach is that it could be used to "link" byte code vectors at some point in the future or provide a form of compilation unit for byte-code. Lynn --00000000000013e94f05e670a5bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 17, 2022, 10:04 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
=
>> Not sure how well it works fo= r very large tables where we risk bumping
>> into the 32K limit of bytecode jumps.
> That did occur to me.
> Perhaps one way to address that limitation without completely
> overhauling the VM would be to introduce a form of segmented memory > for byte strings.

IIRC the limitation is only in the size of relative jumps, so we might
be able to fix it just by adding a new "longbranch" instruction,<= /blockquote>

The i= ssue there is that (IIRC) the relative branch opcodes haven't been used= since v20, and are marked as obsolete/slated for removal.=C2=A0 So, the co= mpiler would have to be altered to use long branches initially, with some l= ater phase replacing them with either relative or short absolute branch cod= es currently emitted if applicable.=C2=A0 The trampoline extension wouldn&#= 39;t require alterations to any construct that is already correctly compile= d.
The other potential bonus of the trampoline appro= ach is that it could be used to "link" byte code vectors at some = point in the future or provide a form of compilation unit for byte-code.

Lynn


--00000000000013e94f05e670a5bb--