[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Where is the eln search path defined
From: |
Alex Bennée |
Subject: |
Re: Where is the eln search path defined |
Date: |
Mon, 18 May 2020 17:34:50 +0100 |
User-agent: |
mu4e 1.4.6; emacs 28.0.50 |
Andrea Corallo <address@hidden> writes:
> Alex Bennée <address@hidden> writes:
>
>> Andrea Corallo <address@hidden> writes:
>>
>>> Alex Bennée <address@hidden> writes:
>>>
>>>> Andrea Corallo <address@hidden> writes:
>>>>
>>>>> Alex Bennée <address@hidden> 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, (continued)
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/15
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/15
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/15
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/15
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/17
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/17
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/17
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/17
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/18
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/18
- Re: Where is the eln search path defined,
Alex Bennée <=
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/18
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/19
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/19
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/19
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/19
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/19
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/20
- Re: Where is the eln search path defined, Alex Bennée, 2020/05/25
- Re: Where is the eln search path defined, Gong-Yi Liao 廖宮毅, 2020/05/25
- Re: Where is the eln search path defined, Andrea Corallo, 2020/05/25