Re: Ideal performance of ELisp

[Andrea Corallo <akrl@sdf.org>]

Lynn Winebarger <owinebar@gmail.com> writes:

> On Tue, Aug 16, 2022 at 2:24 PM Andrea Corallo <akrl@sdf.org> wrote:
>>
>> Lynn Winebarger <owinebar@gmail.com> writes:
>>
>> > On Tue, Aug 16, 2022 at 4:59 AM Andrea Corallo <akrl@sdf.org> wrote:
>> >>
>> >> Stefan Monnier <monnier@iro.umontreal.ca> 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