Re: Ideal performance of ELisp

[Lynn Winebarger]

On Wed, Aug 17, 2022 at 10:18 AM Andrea Corallo <akrl@sdf.org> wrote:
> Lynn Winebarger <owinebar@gmail.com> 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