Where is the eln search path defined

Where is the eln search path defined

[Alex Bennée]

Hi,

I thought it was about time I started getting the native-comp branch
running on some of my aarch64 machines. The bionic version of libgccjit
for aarch64 failed so I ended up having to build the latest from master
and adding it to the search path.

Emacs seems to have built fine but when I run it I get:

  08:41:58 [alex@qemu-test:~/s/emacs] $ emacs -nw
  emacs: /usr/bin/../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln: cannot open shared object file: No such file or directory

The file in question is in my install directory ($HOME/src/emacs/install):

  install/share/emacs/28.0.50/lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln

but emacs doesn't seem to be able to find it. I'm wondering what is
different between aarch64 and x86 because in both cases all I've really
done is add $HOME/src/emacs/install/bin to me PATH.

Any pointers?

-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Hi,
>
> I thought it was about time I started getting the native-comp branch
> running on some of my aarch64 machines. The bionic version of libgccjit
> for aarch64 failed so I ended up having to build the latest from master
> and adding it to the search path.
>
> Emacs seems to have built fine but when I run it I get:
>
>   08:41:58 [alex@qemu-test:~/s/emacs] $ emacs -nw
>   emacs: /usr/bin/../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln: cannot open shared object file: No such file or directory
>
> The file in question is in my install directory ($HOME/src/emacs/install):
>
>   install/share/emacs/28.0.50/lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln
>
> but emacs doesn't seem to be able to find it. I'm wondering what is
> different between aarch64 and x86 because in both cases all I've really
> done is add $HOME/src/emacs/install/bin to me PATH.
>
> Any pointers?

Hi Alex,

Emacs thinks the binary is installed in '/usr/bin/' and the relative path
to find the eln from there is expected to be
'../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln'.

I believe of the two information the first is wrong in this case.  This
is coming from the DESTDIR value while compiling.  Is it possible that
Emacs was compiled with a certain DESTDIR value and then installed using
a different one?

This would explain even if I understand this is really not ideal.

  Andrea

-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Hi,
>>
>> I thought it was about time I started getting the native-comp branch
>> running on some of my aarch64 machines. The bionic version of libgccjit
>> for aarch64 failed so I ended up having to build the latest from master
>> and adding it to the search path.
>>
>> Emacs seems to have built fine but when I run it I get:
>>
>>   08:41:58 [alex@qemu-test:~/s/emacs] $ emacs -nw
>>   emacs: /usr/bin/../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln: cannot open shared object file: No such file or directory
<snip>
>> Any pointers?
>
> Hi Alex,
>
> Emacs thinks the binary is installed in '/usr/bin/' and the relative path
> to find the eln from there is expected to be
> '../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln'.

Hmm it was configured:

  ./configure --prefix=/home/alex/src/emacs/install \
              --with-x-toolkit=no --with-modules \
              --with-nativecomp --with-xpm=ifavailable \
              --with-gif=ifavailable --with-tiff=ifavailable

> I believe of the two information the first is wrong in this case.  This
> is coming from the DESTDIR value while compiling.  Is it possible that
> Emacs was compiled with a certain DESTDIR value and then installed using
> a different one?

I can't quite follow where the automake magic sets DESTDIR but in the
main Makefile I certainly have:

  # The default location for installation.  Everything is placed in
  # subdirectories of this directory.  The default values for many of
  # the variables below are expressed in terms of this one, so you may
  # not need to change them.  This defaults to /usr/local.
  prefix=/home/alex/src/emacs/install

Where is DESTDIR defined during the build?

> This would explain even if I understand this is really not ideal.
>
>   Andrea


-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>>> Hi,
>>>
>>> I thought it was about time I started getting the native-comp branch
>>> running on some of my aarch64 machines. The bionic version of libgccjit
>>> for aarch64 failed so I ended up having to build the latest from master
>>> and adding it to the search path.
>>>
>>> Emacs seems to have built fine but when I run it I get:
>>>
>>>   08:41:58 [alex@qemu-test:~/s/emacs] $ emacs -nw
>>>   emacs: /usr/bin/../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln: cannot open shared object file: No such file or directory
> <snip>
>>> Any pointers?
>>
>> Hi Alex,
>>
>> Emacs thinks the binary is installed in '/usr/bin/' and the relative path
>> to find the eln from there is expected to be
>> '../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln'.
>
> Hmm it was configured:
>
>   ./configure --prefix=/home/alex/src/emacs/install \
>               --with-x-toolkit=no --with-modules \
>               --with-nativecomp --with-xpm=ifavailable \
>               --with-gif=ifavailable --with-tiff=ifavailable

Mmh I see.  Would be interesting if you could check the DESTDIR value
(if any) in your build environment.

>> I believe of the two information the first is wrong in this case.  This
>> is coming from the DESTDIR value while compiling.  Is it possible that
>> Emacs was compiled with a certain DESTDIR value and then installed using
>> a different one?
>
> I can't quite follow where the automake magic sets DESTDIR but in the
> main Makefile I certainly have:
>
>   # The default location for installation.  Everything is placed in
>   # subdirectories of this directory.  The default values for many of
>   # the variables below are expressed in terms of this one, so you may
>   # not need to change them.  This defaults to /usr/local.
>   prefix=/home/alex/src/emacs/install
>
> Where is DESTDIR defined during the build?

That is a very good question.

>> This would explain even if I understand this is really not ideal.
>>
>>   Andrea

-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>
>>>> Hi,
>>>>
>>>> I thought it was about time I started getting the native-comp branch
>>>> running on some of my aarch64 machines. The bionic version of libgccjit
>>>> for aarch64 failed so I ended up having to build the latest from master
>>>> and adding it to the search path.
>>>>
>>>> Emacs seems to have built fine but when I run it I get:
>>>>
>>>>   08:41:58 [alex@qemu-test:~/s/emacs] $ emacs -nw
>>>>   emacs: /usr/bin/../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln: cannot open shared object file: No such file or directory
>> <snip>
>>>> Any pointers?
>>>
>>> Hi Alex,
>>>
>>> Emacs thinks the binary is installed in '/usr/bin/' and the relative path
>>> to find the eln from there is expected to be
>>> '../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln'.
>>
>> Hmm it was configured:
>>
>>   ./configure --prefix=/home/alex/src/emacs/install \
>>               --with-x-toolkit=no --with-modules \
>>               --with-nativecomp --with-xpm=ifavailable \
>>               --with-gif=ifavailable --with-tiff=ifavailable
>
> Mmh I see.  Would be interesting if you could check the DESTDIR value
> (if any) in your build environment.

Definitely not in env:

  19:55:42 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ + env | grep DESTDIR
  19:56:31 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ 1 +

>>> I believe of the two information the first is wrong in this case.  This
>>> is coming from the DESTDIR value while compiling.  Is it possible that
>>> Emacs was compiled with a certain DESTDIR value and then installed using
>>> a different one?
>>
>> I can't quite follow where the automake magic sets DESTDIR but in the
>> main Makefile I certainly have:
>>
>>   # The default location for installation.  Everything is placed in
>>   # subdirectories of this directory.  The default values for many of
>>   # the variables below are expressed in terms of this one, so you may
>>   # not need to change them.  This defaults to /usr/local.
>>   prefix=/home/alex/src/emacs/install
>>
>> Where is DESTDIR defined during the build?
>
> That is a very good question.

I can't see it set, although LISP and BIN DESTDIRS are set:

  19:58:13 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ + remake
  remake -C lib all
  remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/lib'
  remake[1]: Nothing to be done for 'all'.
  remake[1]: Leaving directory '/home/alex/src/emacs/emacs.git/lib'
  remake -C lib-src all
  remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/lib-src'
  remake[1]: Nothing to be done for 'all'.
  remake[1]: Leaving directory '/home/alex/src/emacs/emacs.git/lib-src'
  remake -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' BIN_DESTDIR='/home/alex/src/emacs/install/bin/' \
           LISP_DESTDIR='/home/alex/src/emacs/install/share/emacs/28.0.50/lisp/' all
  remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/src'


>
>>> This would explain even if I understand this is really not ideal.
>>>
>>>   Andrea


-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>>> Andrea Corallo <akrl@sdf.org> writes:
>>>
>>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> I thought it was about time I started getting the native-comp branch
>>>>> running on some of my aarch64 machines. The bionic version of libgccjit
>>>>> for aarch64 failed so I ended up having to build the latest from master
>>>>> and adding it to the search path.
>>>>>
>>>>> Emacs seems to have built fine but when I run it I get:
>>>>>
>>>>>   08:41:58 [alex@qemu-test:~/s/emacs] $ emacs -nw
>>>>>   emacs: /usr/bin/../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln: cannot open shared object file: No such file or directory
>>> <snip>
>>>>> Any pointers?
>>>>
>>>> Hi Alex,
>>>>
>>>> Emacs thinks the binary is installed in '/usr/bin/' and the relative path
>>>> to find the eln from there is expected to be
>>>> '../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln'.
>>>
>>> Hmm it was configured:
>>>
>>>   ./configure --prefix=/home/alex/src/emacs/install \
>>>               --with-x-toolkit=no --with-modules \
>>>               --with-nativecomp --with-xpm=ifavailable \
>>>               --with-gif=ifavailable --with-tiff=ifavailable
>>
>> Mmh I see.  Would be interesting if you could check the DESTDIR value
>> (if any) in your build environment.
>
> Definitely not in env:
>
>   19:55:42 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ + env | grep DESTDIR
>   19:56:31 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ 1 +
>
>>>> I believe of the two information the first is wrong in this case.  This
>>>> is coming from the DESTDIR value while compiling.  Is it possible that
>>>> Emacs was compiled with a certain DESTDIR value and then installed using
>>>> a different one?
>>>
>>> I can't quite follow where the automake magic sets DESTDIR but in the
>>> main Makefile I certainly have:
>>>
>>>   # The default location for installation.  Everything is placed in
>>>   # subdirectories of this directory.  The default values for many of
>>>   # the variables below are expressed in terms of this one, so you may
>>>   # not need to change them.  This defaults to /usr/local.
>>>   prefix=/home/alex/src/emacs/install
>>>
>>> Where is DESTDIR defined during the build?
>>
>> That is a very good question.
>
> I can't see it set, although LISP and BIN DESTDIRS are set:
>
>   19:58:13 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ + remake
>   remake -C lib all
>   remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/lib'
>   remake[1]: Nothing to be done for 'all'.
>   remake[1]: Leaving directory '/home/alex/src/emacs/emacs.git/lib'
>   remake -C lib-src all
>   remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/lib-src'
>   remake[1]: Nothing to be done for 'all'.
>   remake[1]: Leaving directory '/home/alex/src/emacs/emacs.git/lib-src'
>   remake -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' BIN_DESTDIR='/home/alex/src/emacs/install/bin/' \
>            LISP_DESTDIR='/home/alex/src/emacs/install/share/emacs/28.0.50/lisp/' all
>   remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/src'

Regardless the DESTDIRS Unix mystery (!?) BIN_DESTDIR and LISP_DESTDIR
are set correctly.  But looking at you original error apparently Emacs
is convinced to start from '/usr/bin/' and not
'/home/alex/src/emacs/install/bin/'.

This '/usr/bin/' should be the value of `invocation-directory' while
executing pdumper.c:5312.  Is this value wrong or we are missing
something else?

  Andrea
  
-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Eli Zaretskii]

> From: Alex Bennée <alex.bennee@linaro.org>
> Date: Fri, 15 May 2020 22:19:49 +0100
> Cc: emacs-devel@gnu.org
> 
> > Mmh I see.  Would be interesting if you could check the DESTDIR value
> > (if any) in your build environment.
> 
> Definitely not in env:
> 
>   19:55:42 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ + env | grep DESTDIR
>   19:56:31 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ 1 +
> 
> >>> I believe of the two information the first is wrong in this case.  This
> >>> is coming from the DESTDIR value while compiling.  Is it possible that
> >>> Emacs was compiled with a certain DESTDIR value and then installed using
> >>> a different one?
> >>
> >> I can't quite follow where the automake magic sets DESTDIR but in the
> >> main Makefile I certainly have:
> >>
> >>   # The default location for installation.  Everything is placed in
> >>   # subdirectories of this directory.  The default values for many of
> >>   # the variables below are expressed in terms of this one, so you may
> >>   # not need to change them.  This defaults to /usr/local.
> >>   prefix=/home/alex/src/emacs/install
> >>
> >> Where is DESTDIR defined during the build?
> >
> > That is a very good question.
> 
> I can't see it set, although LISP and BIN DESTDIRS are set:

I think this is looking in the wrong direction: DESTDIR is almost
_never_ defined.  It exists for a corner use case, so much so that I
even don't think it will help to describe that use cased here.

My guess is something else is causing this.

Of course, I could be wrong, since I don't know enough about these
details of native compilation.  Apologies if I cause more confusion
than help.

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>
>>>> Andrea Corallo <akrl@sdf.org> writes:
>>>>
>>>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I thought it was about time I started getting the native-comp branch
>>>>>> running on some of my aarch64 machines. The bionic version of libgccjit
>>>>>> for aarch64 failed so I ended up having to build the latest from master
>>>>>> and adding it to the search path.
>>>>>>
>>>>>> Emacs seems to have built fine but when I run it I get:
>>>>>>
>>>>>>   08:41:58 [alex@qemu-test:~/s/emacs] $ emacs -nw
>>>>>>   emacs: /usr/bin/../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln: cannot open shared object file: No such file or directory
>>>> <snip>
>>>>>> Any pointers?
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>> Emacs thinks the binary is installed in '/usr/bin/' and the relative path
>>>>> to find the eln from there is expected to be
>>>>> '../lisp/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd/custom.eln'.
>>>>
>>>> Hmm it was configured:
>>>>
>>>>   ./configure --prefix=/home/alex/src/emacs/install \
>>>>               --with-x-toolkit=no --with-modules \
>>>>               --with-nativecomp --with-xpm=ifavailable \
>>>>               --with-gif=ifavailable --with-tiff=ifavailable
>>>
>>> Mmh I see.  Would be interesting if you could check the DESTDIR value
>>> (if any) in your build environment.
>>
>> Definitely not in env:
>>
>>   19:55:42 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ + env | grep DESTDIR
>>   19:56:31 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ 1 +
>>
>>>>> I believe of the two information the first is wrong in this case.  This
>>>>> is coming from the DESTDIR value while compiling.  Is it possible that
>>>>> Emacs was compiled with a certain DESTDIR value and then installed using
>>>>> a different one?
>>>>
>>>> I can't quite follow where the automake magic sets DESTDIR but in the
>>>> main Makefile I certainly have:
>>>>
>>>>   # The default location for installation.  Everything is placed in
>>>>   # subdirectories of this directory.  The default values for many of
>>>>   # the variables below are expressed in terms of this one, so you may
>>>>   # not need to change them.  This defaults to /usr/local.
>>>>   prefix=/home/alex/src/emacs/install
>>>>
>>>> Where is DESTDIR defined during the build?
>>>
>>> That is a very good question.
>>
>> I can't see it set, although LISP and BIN DESTDIRS are set:
>>
>>   19:58:13 [alex@qemu-test:~/s/e/emacs.git] native-comp|✔ + remake
>>   remake -C lib all
>>   remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/lib'
>>   remake[1]: Nothing to be done for 'all'.
>>   remake[1]: Leaving directory '/home/alex/src/emacs/emacs.git/lib'
>>   remake -C lib-src all
>>   remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/lib-src'
>>   remake[1]: Nothing to be done for 'all'.
>>   remake[1]: Leaving directory '/home/alex/src/emacs/emacs.git/lib-src'
>>   remake -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' BIN_DESTDIR='/home/alex/src/emacs/install/bin/' \
>>            LISP_DESTDIR='/home/alex/src/emacs/install/share/emacs/28.0.50/lisp/' all
>>   remake[1]: Entering directory '/home/alex/src/emacs/emacs.git/src'
>
> Regardless the DESTDIRS Unix mystery (!?) BIN_DESTDIR and LISP_DESTDIR
> are set correctly.  But looking at you original error apparently Emacs
> is convinced to start from '/usr/bin/' and not
> '/home/alex/src/emacs/install/bin/'.
>
> This '/usr/bin/' should be the value of `invocation-directory' while
> executing pdumper.c:5312.  Is this value wrong or we are missing
> something else?

Heh - so I patched pdumper to dump the variables at that point and
re-built:

  dump_do_dump_relocation: installation_state:2  ivoncation_dir:

and now the built emacs boots up fine. So I'm guessing there
must have been a stale pdumper.o that didn't get built for some reason.

Sorry for the noise.

-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Heh - so I patched pdumper to dump the variables at that point and
> re-built:
>
>   dump_do_dump_relocation: installation_state:2  ivoncation_dir:
>
> and now the built emacs boots up fine. So I'm guessing there
> must have been a stale pdumper.o that didn't get built for some reason.
>
> Sorry for the noise.

Hi Alex,

no issue.  Is very good somebody tests Aarch64, thanks for that!

  Andrea

-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Heh - so I patched pdumper to dump the variables at that point and
>> re-built:
>>
>>   dump_do_dump_relocation: installation_state:2  ivoncation_dir:
>>
>> and now the built emacs boots up fine. So I'm guessing there
>> must have been a stale pdumper.o that didn't get built for some reason.
>>
>> Sorry for the noise.
>
> Hi Alex,
>
> no issue.  Is very good somebody tests Aarch64, thanks for that!

While on that subject is there any sort of benchmarking used to see if a
given arch is generating good code? Certainly on x86 I noticed a
speed-up in gnus but that is more subjective than objective.

-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>>> Heh - so I patched pdumper to dump the variables at that point and
>>> re-built:
>>>
>>>   dump_do_dump_relocation: installation_state:2  ivoncation_dir:
>>>
>>> and now the built emacs boots up fine. So I'm guessing there
>>> must have been a stale pdumper.o that didn't get built for some reason.
>>>
>>> Sorry for the noise.
>>
>> Hi Alex,
>>
>> no issue.  Is very good somebody tests Aarch64, thanks for that!
>
> While on that subject is there any sort of benchmarking used to see if a
> given arch is generating good code? Certainly on x86 I noticed a
> speed-up in gnus but that is more subjective than objective.

Hi Alex,

I believe so far what we have is this:

https://elpa.gnu.org/packages/elisp-benchmarks.html

Note that you have to native compile by hand the tests because this
package doesn't know about native compilation.

Bests

  Andrea

-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>
>>>> Heh - so I patched pdumper to dump the variables at that point and
>>>> re-built:
>>>>
>>>>   dump_do_dump_relocation: installation_state:2  ivoncation_dir:
>>>>
>>>> and now the built emacs boots up fine. So I'm guessing there
>>>> must have been a stale pdumper.o that didn't get built for some reason.
>>>>
>>>> Sorry for the noise.
>>>
>>> Hi Alex,
>>>
>>> no issue.  Is very good somebody tests Aarch64, thanks for that!
>>
>> While on that subject is there any sort of benchmarking used to see if a
>> given arch is generating good code? Certainly on x86 I noticed a
>> speed-up in gnus but that is more subjective than objective.
>
> Hi Alex,
>
> I believe so far what we have is this:
>
> https://elpa.gnu.org/packages/elisp-benchmarks.html
>
> Note that you have to native compile by hand the tests because this
> package doesn't know about native compilation.

I did C-h f elisp-benchmark-run and navigated to the file and executed
(native-compile (buffer-file-name)) and waited for it to dump the .eln
filename. The results don't seem that impressive so I don't know if I
did something wrong or if libgccjit is just being poor on Aarch64. The
machine is a TX1 so the individual cores aren't supper powerful anyway
but I was hoping for better:

* Before Results (byte-compiled)

  | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | bubble-no-cons |         217.03 |       0.00 |       0 |      217.03 |            2.66 |
  | bubble         |          91.18 |      53.77 |      68 |      144.95 |            3.37 |
  | dhrystone      |         289.30 |      85.21 |     106 |      374.51 |            3.80 |
  | fibn-rec       |         139.91 |       0.00 |       0 |      139.91 |            0.58 |
  | fibn-tc        |         164.23 |       0.00 |       0 |      164.23 |            4.53 |
  | fibn           |         189.61 |       0.00 |       0 |      189.61 |            2.42 |
  | inclist        |         281.67 |       0.00 |       0 |      281.67 |            5.13 |
  | listlen-tc     |         263.80 |       0.00 |       0 |      263.80 |           10.06 |
  | nbody          |          70.62 |      92.60 |     114 |      163.23 |            4.30 |
  | pidigits       |         180.40 |      64.86 |      62 |      245.26 |            3.08 |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | total          |        1887.75 |     296.44 |     350 |     2184.19 |           14.67 |
  |                |                |            |         |             |                 |

* After Results (native-compiled)

  | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | bubble-no-cons |         206.13 |       0.00 |       0 |      206.13 |            4.67 |
  | bubble         |          88.84 |      48.20 |      65 |      137.05 |            0.73 |
  | dhrystone      |         301.94 |      75.30 |     102 |      377.24 |            4.91 |
  | fibn-rec       |         143.44 |       0.00 |       0 |      143.44 |            3.26 |
  | fibn-tc        |         165.60 |       0.00 |       0 |      165.60 |            1.99 |
  | fibn           |         186.95 |       0.00 |       0 |      186.95 |            6.08 |
  | inclist        |         270.98 |       0.00 |       0 |      270.98 |            1.57 |
  | listlen-tc     |         248.98 |       0.00 |       0 |      248.98 |            5.37 |
  | nbody          |          71.46 |      82.83 |     110 |      154.30 |            2.88 |
  | pidigits       |         192.83 |      61.80 |      59 |      254.63 |            2.56 |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | total          |        1877.15 |     268.14 |     336 |     2145.29 |           12.01 |


I guess it's time to start looking at the generated code?

-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>>> Andrea Corallo <akrl@sdf.org> writes:
>>>
>>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>>
>>>>> Heh - so I patched pdumper to dump the variables at that point and
>>>>> re-built:
>>>>>
>>>>>   dump_do_dump_relocation: installation_state:2  ivoncation_dir:
>>>>>
>>>>> and now the built emacs boots up fine. So I'm guessing there
>>>>> must have been a stale pdumper.o that didn't get built for some reason.
>>>>>
>>>>> Sorry for the noise.
>>>>
>>>> Hi Alex,
>>>>
>>>> no issue.  Is very good somebody tests Aarch64, thanks for that!
>>>
>>> While on that subject is there any sort of benchmarking used to see if a
>>> given arch is generating good code? Certainly on x86 I noticed a
>>> speed-up in gnus but that is more subjective than objective.
>>
>> Hi Alex,
>>
>> I believe so far what we have is this:
>>
>> https://elpa.gnu.org/packages/elisp-benchmarks.html
>>
>> Note that you have to native compile by hand the tests because this
>> package doesn't know about native compilation.
>
> I did C-h f elisp-benchmark-run and navigated to the file and executed
> (native-compile (buffer-file-name)) and waited for it to dump the .eln
> filename. The results don't seem that impressive so I don't know if I
> did something wrong or if libgccjit is just being poor on Aarch64. The
> machine is a TX1 so the individual cores aren't supper powerful anyway
> but I was hoping for better:
>
> * Before Results (byte-compiled)
>
>   | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
>   |----------------+----------------+------------+---------+-------------+-----------------|
>   | bubble-no-cons |         217.03 |       0.00 |       0 |      217.03 |            2.66 |
>   | bubble         |          91.18 |      53.77 |      68 |      144.95 |            3.37 |
>   | dhrystone      |         289.30 |      85.21 |     106 |      374.51 |            3.80 |
>   | fibn-rec       |         139.91 |       0.00 |       0 |      139.91 |            0.58 |
>   | fibn-tc        |         164.23 |       0.00 |       0 |      164.23 |            4.53 |
>   | fibn           |         189.61 |       0.00 |       0 |      189.61 |            2.42 |
>   | inclist        |         281.67 |       0.00 |       0 |      281.67 |            5.13 |
>   | listlen-tc     |         263.80 |       0.00 |       0 |      263.80 |           10.06 |
>   | nbody          |          70.62 |      92.60 |     114 |      163.23 |            4.30 |
>   | pidigits       |         180.40 |      64.86 |      62 |      245.26 |            3.08 |
>   |----------------+----------------+------------+---------+-------------+-----------------|
>   | total          |        1887.75 |     296.44 |     350 |     2184.19 |           14.67 |
>   |                |                |            |         |             |                 |
>
> * After Results (native-compiled)
>
>   | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
>   |----------------+----------------+------------+---------+-------------+-----------------|
>   | bubble-no-cons |         206.13 |       0.00 |       0 |      206.13 |            4.67 |
>   | bubble         |          88.84 |      48.20 |      65 |      137.05 |            0.73 |
>   | dhrystone      |         301.94 |      75.30 |     102 |      377.24 |            4.91 |
>   | fibn-rec       |         143.44 |       0.00 |       0 |      143.44 |            3.26 |
>   | fibn-tc        |         165.60 |       0.00 |       0 |      165.60 |            1.99 |
>   | fibn           |         186.95 |       0.00 |       0 |      186.95 |            6.08 |
>   | inclist        |         270.98 |       0.00 |       0 |      270.98 |            1.57 |
>   | listlen-tc     |         248.98 |       0.00 |       0 |      248.98 |            5.37 |
>   | nbody          |          71.46 |      82.83 |     110 |      154.30 |            2.88 |
>   | pidigits       |         192.83 |      61.80 |      59 |      254.63 |            2.56 |
>   |----------------+----------------+------------+---------+-------------+-----------------|
>   | total          |        1877.15 |     268.14 |     336 |     2145.29 |           12.01 |
>
>
> I guess it's time to start looking at the generated code?

Hi Alex,

I suspect for some reason we are looking at two byte compiled runs.  For
One option to verify that is to hack a little the code or other option
is to run this version instead:

https://gitlab.com/koral/elisp-benchmarks

I probably should update the official one to handle native compilation,
haven't done it so far due to lack of time and because native
compilation "officially" does not exists :)

Thanks

  Andrea

-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>
>>>> Andrea Corallo <akrl@sdf.org> writes:
>>>>
>>>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>>>
>>>>>> Heh - so I patched pdumper to dump the variables at that point and
>>>>>> re-built:
>>>>>>
>>>>>>   dump_do_dump_relocation: installation_state:2  ivoncation_dir:
>>>>>>
>>>>>> and now the built emacs boots up fine. So I'm guessing there
>>>>>> must have been a stale pdumper.o that didn't get built for some reason.
>>>>>>
>>>>>> Sorry for the noise.
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>> no issue.  Is very good somebody tests Aarch64, thanks for that!
>>>>
>>>> While on that subject is there any sort of benchmarking used to see if a
>>>> given arch is generating good code? Certainly on x86 I noticed a
>>>> speed-up in gnus but that is more subjective than objective.
>>>
>>> Hi Alex,
>>>
>>> I believe so far what we have is this:
>>>
>>> https://elpa.gnu.org/packages/elisp-benchmarks.html
>>>
>>> Note that you have to native compile by hand the tests because this
>>> package doesn't know about native compilation.
>>
>> I did C-h f elisp-benchmark-run and navigated to the file and executed
>> (native-compile (buffer-file-name)) and waited for it to dump the .eln
>> filename. The results don't seem that impressive so I don't know if I
>> did something wrong or if libgccjit is just being poor on Aarch64. The
>> machine is a TX1 so the individual cores aren't supper powerful anyway
>> but I was hoping for better:
>>
>> * Before Results (byte-compiled)
>>
>>   | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
>>   |----------------+----------------+------------+---------+-------------+-----------------|
>>   | bubble-no-cons |         217.03 |       0.00 |       0 |      217.03 |            2.66 |
>>   | bubble         |          91.18 |      53.77 |      68 |      144.95 |            3.37 |
>>   | dhrystone      |         289.30 |      85.21 |     106 |      374.51 |            3.80 |
>>   | fibn-rec       |         139.91 |       0.00 |       0 |      139.91 |            0.58 |
>>   | fibn-tc        |         164.23 |       0.00 |       0 |      164.23 |            4.53 |
>>   | fibn           |         189.61 |       0.00 |       0 |      189.61 |            2.42 |
>>   | inclist        |         281.67 |       0.00 |       0 |      281.67 |            5.13 |
>>   | listlen-tc     |         263.80 |       0.00 |       0 |      263.80 |           10.06 |
>>   | nbody          |          70.62 |      92.60 |     114 |      163.23 |            4.30 |
>>   | pidigits       |         180.40 |      64.86 |      62 |      245.26 |            3.08 |
>>   |----------------+----------------+------------+---------+-------------+-----------------|
>>   | total          |        1887.75 |     296.44 |     350 |     2184.19 |           14.67 |
>>   |                |                |            |         |             |                 |
>>
>> * After Results (native-compiled)
>>
>>   | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
>>   |----------------+----------------+------------+---------+-------------+-----------------|
>>   | bubble-no-cons |         206.13 |       0.00 |       0 |      206.13 |            4.67 |
>>   | bubble         |          88.84 |      48.20 |      65 |      137.05 |            0.73 |
>>   | dhrystone      |         301.94 |      75.30 |     102 |      377.24 |            4.91 |
>>   | fibn-rec       |         143.44 |       0.00 |       0 |      143.44 |            3.26 |
>>   | fibn-tc        |         165.60 |       0.00 |       0 |      165.60 |            1.99 |
>>   | fibn           |         186.95 |       0.00 |       0 |      186.95 |            6.08 |
>>   | inclist        |         270.98 |       0.00 |       0 |      270.98 |            1.57 |
>>   | listlen-tc     |         248.98 |       0.00 |       0 |      248.98 |            5.37 |
>>   | nbody          |          71.46 |      82.83 |     110 |      154.30 |            2.88 |
>>   | pidigits       |         192.83 |      61.80 |      59 |      254.63 |            2.56 |
>>   |----------------+----------------+------------+---------+-------------+-----------------|
>>   | total          |        1877.15 |     268.14 |     336 |     2145.29 |           12.01 |
>>
>>
>> I guess it's time to start looking at the generated code?
>
> Hi Alex,
>
> I suspect for some reason we are looking at two byte compiled runs.

Ahh yes - all I managed to do was compile the main function as the
benchmarks themselves are in separate files.

> For
> One option to verify that is to hack a little the code or other option
> is to run this version instead:
>
> https://gitlab.com/koral/elisp-benchmarks
>
> I probably should update the official one to handle native compilation,
> haven't done it so far due to lack of time and because native
> compilation "officially" does not exists :)

Can it not be made to fail gracefully (and perhaps add the
interpreted/bytecode/compiled status to the output table?)

>
> Thanks
>
>   Andrea


-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:


>> For
>> One option to verify that is to hack a little the code or other option
>> is to run this version instead:
>>
>> https://gitlab.com/koral/elisp-benchmarks
>>
>> I probably should update the official one to handle native compilation,
>> haven't done it so far due to lack of time and because native
>> compilation "officially" does not exists :)
>
> Can it not be made to fail gracefully (and perhaps add the
> interpreted/bytecode/compiled status to the output table?)

Yes I guess we should do something like that.  Either add a table or
support the native compilation when available and the entry function is
called with the compile parameter set to t.

  Andrea

-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>
>>> For
>>> One option to verify that is to hack a little the code or other option
>>> is to run this version instead:
>>>
>>> https://gitlab.com/koral/elisp-benchmarks
>>>
>>> I probably should update the official one to handle native compilation,
>>> haven't done it so far due to lack of time and because native
>>> compilation "officially" does not exists :)
>>
>> Can it not be made to fail gracefully (and perhaps add the
>> interpreted/bytecode/compiled status to the output table?)
>
> Yes I guess we should do something like that.  Either add a table or
> support the native compilation when available and the entry function is
> called with the compile parameter set to t.

I added elisp-benchmarks.git to my .emacs.d and included in the
load-path but it fell over:

  (require 'elisp-benchmark)
  (elb-run)

But Messages show:

   Compiling nbody.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/nbody.elc
   Compiling bubble.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/bubble.elc
   Compiling bubble-no-cons.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/bubble-no-cons.elc
   Compiling fibn.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/fibn.elc
   Compiling fibn-rec.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/fibn-rec.elc
   Compiling fibn-tc.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/fibn-tc.elc
   Compiling inclist-tc.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/inclist-tc.elc
   Compiling listlen-tc.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/listlen-tc.elc
   Compiling inclist-no-type-hints.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/inclist-no-type-hints.elc
   Compiling inclist-type-hints.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/inclist-type-hints.elc
   Compiling dhrystone.el
  Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/dhrystone.elc
  Loading /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/nbody.elc...done
  Running /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/nbody.el byte compiled...
  res: -0.16908075525401578
  and: Cannot open load file: No such file or directory, /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/nbody.eln

However there I do have a directory with eln files in it:

  /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd

  ~/.emacs.d/elisp-benchmarks.git/benchmarks/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd $ ls -l
  total 221
  -rwxrwxr-x   1 alex           alex     13464 2020-05-19 06:39 bubble-no-cons.eln
  -rwxrwxr-x   1 alex           alex     13416 2020-05-19 06:39 bubble.eln
  -rwxrwxr-x   1 alex           alex     70616 2020-05-19 06:42 dhrystone.eln
  -rwxrwxr-x   1 alex           alex     13416 2020-05-19 06:39 fibn-rec.eln
  -rwxrwxr-x   1 alex           alex     13424 2020-05-19 06:39 fibn-tc.eln
  -rwxrwxr-x   1 alex           alex     13408 2020-05-19 06:39 fibn.eln
  -rwxrwxr-x   1 alex           alex     13480 2020-05-19 06:39 inclist-no-type-hints.eln
  -rwxrwxr-x   1 alex           alex     13440 2020-05-19 06:39 inclist-tc.eln
  -rwxrwxr-x   1 alex           alex     13464 2020-05-19 06:39 inclist-type-hints.eln
  -rwxrwxr-x   1 alex           alex     13440 2020-05-19 06:39 listlen-tc.eln
  -rwxrwxr-x   1 alex           alex     35016 2020-05-19 06:39 nbody.eln

So I guess this is another path searching problem?

>
>   Andrea


-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>>
>>>> For
>>>> One option to verify that is to hack a little the code or other option
>>>> is to run this version instead:
>>>>
>>>> https://gitlab.com/koral/elisp-benchmarks
>>>>
>>>> I probably should update the official one to handle native compilation,
>>>> haven't done it so far due to lack of time and because native
>>>> compilation "officially" does not exists :)
>>>
>>> Can it not be made to fail gracefully (and perhaps add the
>>> interpreted/bytecode/compiled status to the output table?)
>>
>> Yes I guess we should do something like that.  Either add a table or
>> support the native compilation when available and the entry function is
>> called with the compile parameter set to t.
>
> I added elisp-benchmarks.git to my .emacs.d and included in the
> load-path but it fell over:
>
>   (require 'elisp-benchmark)
>   (elb-run)
>
> But Messages show:
>
>    Compiling nbody.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/nbody.elc
>    Compiling bubble.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/bubble.elc
>    Compiling bubble-no-cons.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/bubble-no-cons.elc
>    Compiling fibn.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/fibn.elc
>    Compiling fibn-rec.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/fibn-rec.elc
>    Compiling fibn-tc.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/fibn-tc.elc
>    Compiling inclist-tc.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/inclist-tc.elc
>    Compiling listlen-tc.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/listlen-tc.elc
>    Compiling inclist-no-type-hints.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/inclist-no-type-hints.elc
>    Compiling inclist-type-hints.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/inclist-type-hints.elc
>    Compiling dhrystone.el
>   Wrote /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/dhrystone.elc
>   Loading /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/nbody.elc...done
>   Running /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/nbody.el byte compiled...
>   res: -0.16908075525401578
>   and: Cannot open load file: No such file or directory, /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/nbody.eln
>
> However there I do have a directory with eln files in it:
>
>   /home/alex/.emacs.d/elisp-benchmarks.git/benchmarks/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd
>
>   ~/.emacs.d/elisp-benchmarks.git/benchmarks/eln-aarch64-unknown-linux-gnu-e59b16aa72ffe0cd $ ls -l
>   total 221
>   -rwxrwxr-x   1 alex           alex     13464 2020-05-19 06:39 bubble-no-cons.eln
>   -rwxrwxr-x   1 alex           alex     13416 2020-05-19 06:39 bubble.eln
>   -rwxrwxr-x   1 alex           alex     70616 2020-05-19 06:42 dhrystone.eln
>   -rwxrwxr-x   1 alex           alex     13416 2020-05-19 06:39 fibn-rec.eln
>   -rwxrwxr-x   1 alex           alex     13424 2020-05-19 06:39 fibn-tc.eln
>   -rwxrwxr-x   1 alex           alex     13408 2020-05-19 06:39 fibn.eln
>   -rwxrwxr-x   1 alex           alex     13480 2020-05-19 06:39 inclist-no-type-hints.eln
>   -rwxrwxr-x   1 alex           alex     13440 2020-05-19 06:39 inclist-tc.eln
>   -rwxrwxr-x   1 alex           alex     13464 2020-05-19 06:39 inclist-type-hints.eln
>   -rwxrwxr-x   1 alex           alex     13440 2020-05-19 06:39 listlen-tc.eln
>   -rwxrwxr-x   1 alex           alex     35016 2020-05-19 06:39 nbody.eln
>
> So I guess this is another path searching problem?

I see, I realize this code was written with the old layout directory
arrangement.

Try this hack...

./emacs -batch -l /tmp/elisp-benchmarks/elisp-benchmark.el --eval '(progn (setq comp-speed 3) (setq comp-native-path-postfix nil) (elb-run))'

I really have to update elisp-benchmarks on elpa.

  Andrea

-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> I really have to update elisp-benchmarks on elpa.

Hi Alex, with the latest elpa elisp-benchamrks (1.5) just

.../emacs -batch -l .../elisp-benchmarks.el -f elisp-benchmarks-run 

should now do everything automatically, using native-comp if available
or the byte-compiler otherwise.

  Andrea

-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> I really have to update elisp-benchmarks on elpa.
>
> Hi Alex, with the latest elpa elisp-benchamrks (1.5) just
>
> .../emacs -batch -l .../elisp-benchmarks.el -f elisp-benchmarks-run 
>
> should now do everything automatically, using native-comp if available
> or the byte-compiler otherwise.

That's better:

* Results

  | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | bubble-no-cons |          12.92 |       0.05 |       1 |       12.97 |            0.05 |
  | bubble         |          10.40 |       1.06 |       1 |       11.46 |            1.04 |
  | dhrystone      |          16.78 |       0.00 |       0 |       16.78 |            0.21 |
  | fibn-rec       |          11.39 |       0.00 |       0 |       11.39 |            0.02 |
  | fibn-tc        |           7.94 |       0.00 |       0 |        7.94 |            0.03 |
  | fibn           |          23.42 |       0.00 |       0 |       23.42 |            0.03 |
  | inclist        |           8.17 |       0.04 |       1 |        8.21 |            0.04 |
  | listlen-tc     |           0.86 |       0.00 |       0 |        0.86 |            0.01 |
  | nbody          |           9.30 |       0.88 |       1 |       10.18 |            0.14 |
  | pidigits       |          29.79 |       5.77 |       1 |       35.57 |            7.13 |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | total          |         130.97 |       7.81 |       5 |      138.78 |            7.21 |

I guess I need to enable async compilation now to ensure all the various
elpa/melpa packages are compiled.

-- 
Alex Bennée

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> I really have to update elisp-benchmarks on elpa.
>>
>> Hi Alex, with the latest elpa elisp-benchamrks (1.5) just
>>
>> .../emacs -batch -l .../elisp-benchmarks.el -f elisp-benchmarks-run 
>>
>> should now do everything automatically, using native-comp if available
>> or the byte-compiler otherwise.
>
> That's better:
>
> * Results
>
>   | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
>   |----------------+----------------+------------+---------+-------------+-----------------|
>   | bubble-no-cons |          12.92 |       0.05 |       1 |       12.97 |            0.05 |
>   | bubble         |          10.40 |       1.06 |       1 |       11.46 |            1.04 |
>   | dhrystone      |          16.78 |       0.00 |       0 |       16.78 |            0.21 |
>   | fibn-rec       |          11.39 |       0.00 |       0 |       11.39 |            0.02 |
>   | fibn-tc        |           7.94 |       0.00 |       0 |        7.94 |            0.03 |
>   | fibn           |          23.42 |       0.00 |       0 |       23.42 |            0.03 |
>   | inclist        |           8.17 |       0.04 |       1 |        8.21 |            0.04 |
>   | listlen-tc     |           0.86 |       0.00 |       0 |        0.86 |            0.01 |
>   | nbody          |           9.30 |       0.88 |       1 |       10.18 |            0.14 |
>   | pidigits       |          29.79 |       5.77 |       1 |       35.57 |            7.13 |
>   |----------------+----------------+------------+---------+-------------+-----------------|
>   | total          |         130.97 |       7.81 |       5 |      138.78 |            7.21 |

Does that means that we are observing a 15x perf uplift?

What's the uarch are we looking at?

Simple uarch usually benefit more, 15x is a lot tho.

> I guess I need to enable async compilation now to ensure all the various
> elpa/melpa packages are compiled.

Yes, on top of your .emacs

(setq comp-deferred-compilation t)

Thanks

  Andrea
  
-- 
akrl@sdf.org

Re: Where is the eln search path defined

[Thomas Fitzsimmons]

Andrea Corallo <akrl@sdf.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> I really have to update elisp-benchmarks on elpa.
>
> Hi Alex, with the latest elpa elisp-benchamrks (1.5) just
>
> .../emacs -batch -l .../elisp-benchmarks.el -f elisp-benchmarks-run 
>
> should now do everything automatically, using native-comp if available
> or the byte-compiler otherwise.

Here are results on GNU/Linux ppc64le, since I haven't seen any posted
for this architecture yet.

elisp-benchmarks commit fe6aa3ec9ca5f7568d7a1e5005382343b3bd9143.

Emacs commit cd4ef52c8673a76c6fcb0efd7d2c74778522038c, configured with:

./configure --with-x-toolkit=lucid --with-nativecomp

against Debian's libgccjit-9-dev.

* Results

  | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | bubble-no-cons |           7.83 |       0.02 |       1 |        7.85 |            0.03 |
  | bubble         |           4.38 |       0.15 |       1 |        4.53 |            0.02 |
  | dhrystone      |          19.03 |       0.00 |       0 |       19.03 |            0.03 |
  | fibn-rec       |           9.09 |       0.00 |       0 |        9.09 |            0.00 |
  | fibn-tc        |           5.94 |       0.00 |       0 |        5.94 |            0.00 |
  | fibn           |          17.65 |       0.00 |       0 |       17.65 |            0.00 |
  | inclist        |           1.52 |       0.02 |       1 |        1.54 |            0.01 |
  | listlen-tc     |           0.22 |       0.00 |       0 |        0.22 |            0.00 |
  | nbody          |           3.77 |       0.29 |       1 |        4.07 |            0.03 |
  | pidigits       |           8.11 |       1.83 |       1 |        9.94 |            0.32 |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | total          |          77.54 |       2.32 |       5 |       79.86 |            0.32 |

versus an Emacs built from master on 2020-04-25:

* Results

  | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | bubble-no-cons |          46.69 |       0.06 |       4 |       46.76 |            0.00 |
  | bubble         |          18.82 |       7.63 |     488 |       26.46 |            0.02 |
  | dhrystone      |          27.19 |       0.00 |       0 |       27.19 |            0.01 |
  | fibn-rec       |          19.63 |       0.00 |       0 |       19.63 |            0.00 |
  | fibn-tc        |          19.66 |       0.00 |       0 |       19.66 |            0.01 |
  | fibn           |          50.97 |       0.00 |       0 |       50.97 |            0.01 |
  | inclist        |          71.17 |       0.02 |       1 |       71.18 |            0.07 |
  | listlen-tc     |          17.77 |       0.00 |       0 |       17.77 |            0.00 |
  | nbody          |           7.67 |      13.22 |     839 |       20.89 |            0.02 |
  | pidigits       |           9.86 |       9.60 |     457 |       19.46 |            0.00 |
  |----------------+----------------+------------+---------+-------------+-----------------|
  | total          |         289.43 |      30.53 |    1789 |      319.96 |            0.07 |

The build on the native-comp branch without --with-nativecomp fails with
a segfault during "GEN loaddefs.el".

Thomas

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> Andrea Corallo <akrl@sdf.org> writes:
>>>
>>>> I really have to update elisp-benchmarks on elpa.
>>>
>>> Hi Alex, with the latest elpa elisp-benchamrks (1.5) just
>>>
>>> .../emacs -batch -l .../elisp-benchmarks.el -f elisp-benchmarks-run 
>>>
>>> should now do everything automatically, using native-comp if available
>>> or the byte-compiler otherwise.
>>
>> That's better:
>>
>> * Results
>>
>>   | test           | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
>>   |----------------+----------------+------------+---------+-------------+-----------------|
>>   | bubble-no-cons |          12.92 |       0.05 |       1 |       12.97 |            0.05 |
>>   | bubble         |          10.40 |       1.06 |       1 |       11.46 |            1.04 |
>>   | dhrystone      |          16.78 |       0.00 |       0 |       16.78 |            0.21 |
>>   | fibn-rec       |          11.39 |       0.00 |       0 |       11.39 |            0.02 |
>>   | fibn-tc        |           7.94 |       0.00 |       0 |        7.94 |            0.03 |
>>   | fibn           |          23.42 |       0.00 |       0 |       23.42 |            0.03 |
>>   | inclist        |           8.17 |       0.04 |       1 |        8.21 |            0.04 |
>>   | listlen-tc     |           0.86 |       0.00 |       0 |        0.86 |            0.01 |
>>   | nbody          |           9.30 |       0.88 |       1 |       10.18 |            0.14 |
>>   | pidigits       |          29.79 |       5.77 |       1 |       35.57 |            7.13 |
>>   |----------------+----------------+------------+---------+-------------+-----------------|
>>   | total          |         130.97 |       7.81 |       5 |      138.78 |            7.21 |
>
> Does that means that we are observing a 15x perf uplift?
>
> What's the uarch are we looking at?

It's a ThunderX1 from Packet which I think is Caviums own uarch
confirming to Armv8.1:

./tests/tcg/aarch64-linux-user/sysregs
Checking Counter registers
ctr_el0             : 0x0000000095558005
cntvct_el0          : 0x0002f01fe6ef26fc
cntfrq_el0          : 0x0000000005f5e100
Checking CPUID registers
id_aa64isar0_el1    : 0x0000000000011120
id_aa64isar1_el1    : 0x0000000000000000
id_aa64mmfr0_el1    : 0x00000000ff000000
id_aa64pfr0_el1     : 0x0000000000000011
id_aa64pfr1_el1     : 0x0000000000000000
id_aa64dfr0_el1     : 0x0000000000000006
midr_el1            : 0x00000000431f0a11
mpidr_el1           : 0x0000000080000000
Remaining registers should fail
id_mmfr0_el1        : 0x00000000deadbeef
id_mmfr1_el1        : 0x00000000deadbeef
id_mmfr2_el1        : 0x00000000deadbeef
id_mmfr3_el1        : 0x00000000deadbeef
mvfr0_el1           : 0x00000000deadbeef
mvfr1_el1           : 0x00000000deadbeef

> Simple uarch usually benefit more, 15x is a lot tho.

I'm about to upgrade the box to a more recent Ubuntu so hopefully will
be able to use the stock libgccjit instead of a checkout. I'll see how
it looks then and also compare it to the stock Emacs.

>
>> I guess I need to enable async compilation now to ensure all the various
>> elpa/melpa packages are compiled.
>
> Yes, on top of your .emacs
>
> (setq comp-deferred-compilation t)
>
> Thanks
>
>   Andrea


-- 
Alex Bennée

Re: Where is the eln search path defined

[Alex Bennée]

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> Andrea Corallo <akrl@sdf.org> writes:
>>>
<snip>
>>   |----------------+----------------+------------+---------+-------------+-----------------|
>>   | total          |         130.97 |       7.81 |       5 |      138.78 |            7.21 |
>
> Does that means that we are observing a 15x perf uplift?
>
> What's the uarch are we looking at?
>
> Simple uarch usually benefit more, 15x is a lot tho.

I've recently updated the host OS to the latest Ubuntu LTS so I was
trying to gather details with the system emacs for comparison:

  "GNU Emacs 26.3 (build 2, aarch64-unknown-linux-gnu)
   of 2020-03-26, modified by Debian"

But I don't seem to be able to get through one iteration. Could it be a
.elc breakage between 26 and master or something else?

  Compiling... /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.el
  Compiling /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.el...done
  Wrote /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.elc
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.elc...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/bubble-no-cons...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/bubble...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/dhrystone...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn-rec...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn-tc...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/inclist...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/listlen-tc...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/nbody...done
  Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits...done
  Iteration number: 1
  Running bubble-no-cons...
  Running bubble...
  Running dhrystone...
  Running fibn-rec...
  Running fibn-tc...
  Running fibn...
  Running inclist...
  Running listlen-tc...
  Re-entering top level after C stack overflow

I've tried various combinations of:

  (setq max-specpdl-size 650)
  (setq max-lisp-eval-depth 400)

but I'm mainly just guessing without any concrete idea of what numbers I
should be going for. Any ideas?

-- 
Alex Bennée

Re: Where is the eln search path defined

[Gong-Yi Liao 廖宮毅]

[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]

Can (native-comp-speed 3) help here?

On Mon, May 25, 2020, 09:16 Alex Bennée <alex.bennee@linaro.org> wrote:

>
> Andrea Corallo <akrl@sdf.org> writes:
>
> > Alex Bennée <alex.bennee@linaro.org> writes:
> >
> >> Andrea Corallo <akrl@sdf.org> writes:
> >>
> >>> Andrea Corallo <akrl@sdf.org> writes:
> >>>
> <snip>
> >>
>  |----------------+----------------+------------+---------+-------------+-----------------|
> >>   | total          |         130.97 |       7.81 |       5 |
> 138.78 |            7.21 |
> >
> > Does that means that we are observing a 15x perf uplift?
> >
> > What's the uarch are we looking at?
> >
> > Simple uarch usually benefit more, 15x is a lot tho.
>
> I've recently updated the host OS to the latest Ubuntu LTS so I was
> trying to gather details with the system emacs for comparison:
>
>   "GNU Emacs 26.3 (build 2, aarch64-unknown-linux-gnu)
>    of 2020-03-26, modified by Debian"
>
> But I don't seem to be able to get through one iteration. Could it be a
> .elc breakage between 26 and master or something else?
>
>   Compiling...
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.el
>   Compiling
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.el...done
>   Wrote
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.elc
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.elc...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/bubble-no-cons...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/bubble...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/dhrystone...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn-rec...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn-tc...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/inclist...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/listlen-tc...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/nbody...done
>   Loading
> /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits...done
>   Iteration number: 1
>   Running bubble-no-cons...
>   Running bubble...
>   Running dhrystone...
>   Running fibn-rec...
>   Running fibn-tc...
>   Running fibn...
>   Running inclist...
>   Running listlen-tc...
>   Re-entering top level after C stack overflow
>
> I've tried various combinations of:
>
>   (setq max-specpdl-size 650)
>   (setq max-lisp-eval-depth 400)
>
> but I'm mainly just guessing without any concrete idea of what numbers I
> should be going for. Any ideas?
>
> --
> Alex Bennée
>
>

[-- Attachment #2: Type: text/html, Size: 3689 bytes --]

Re: Where is the eln search path defined

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>>> Andrea Corallo <akrl@sdf.org> writes:
>>>
>>>> Andrea Corallo <akrl@sdf.org> writes:
>>>>
> <snip>
>>>   |----------------+----------------+------------+---------+-------------+-----------------|
>>>   | total          |         130.97 |       7.81 |       5 |      138.78 |            7.21 |
>>
>> Does that means that we are observing a 15x perf uplift?
>>
>> What's the uarch are we looking at?
>>
>> Simple uarch usually benefit more, 15x is a lot tho.
>
> I've recently updated the host OS to the latest Ubuntu LTS so I was
> trying to gather details with the system emacs for comparison:
>
>   "GNU Emacs 26.3 (build 2, aarch64-unknown-linux-gnu)
>    of 2020-03-26, modified by Debian"
>
> But I don't seem to be able to get through one iteration. Could it be a
> .elc breakage between 26 and master or something else?
>
>   Compiling... /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.el
>   Compiling /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.el...done
>   Wrote /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.elc
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits.elc...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/bubble-no-cons...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/bubble...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/dhrystone...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn-rec...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn-tc...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/fibn...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/inclist...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/listlen-tc...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/nbody...done
>   Loading /home/alex/.emacs.d/elpa/elisp-benchmarks-1.5/benchmarks/pidigits...done
>   Iteration number: 1
>   Running bubble-no-cons...
>   Running bubble...
>   Running dhrystone...
>   Running fibn-rec...
>   Running fibn-tc...
>   Running fibn...
>   Running inclist...
>   Running listlen-tc...
>   Re-entering top level after C stack overflow
>
> I've tried various combinations of:
>
>   (setq max-specpdl-size 650)
>   (setq max-lisp-eval-depth 400)
>
> but I'm mainly just guessing without any concrete idea of what numbers I
> should be going for. Any ideas?

Hi Alex,

I believe for some reason this kernel is giving less room for the stack.
The only think you can do is to remove listlen-tc.el* or trim down
elb-listlen-tc-len in it.

  Andrea

-- 
akrl@sdf.org