[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On elisp running native
From: |
Andrea Corallo |
Subject: |
Re: On elisp running native |
Date: |
Sun, 01 Dec 2019 10:34:06 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (berkeley-unix) |
Stefan Monnier <address@hidden> writes:
> I'm not sure what those 11s-12s come from, but I think it's safe to take
> the "1.9x" as the more relevant measure in terms of measuring the impact
> of native compilation on the speed of bytecomp.el.
I've got some time to repeat the measure trying to understand better
what's going on.
I've repeated the same test but running it 10 times.
(benchmark 10 '(mapc #'byte-compile-file (directory-files
"~/emacs/lisp" t "el$")))
I've discovered that my previous measure made not much sense because the
time spent into GC is much bigger during the byte-code runs.
-bytecode
"Elapsed time: 156.960728s (77.049537s in 3421 GCs)"
-native speed 2
"Elapsed time: 94.538094s (46.362582s in 1737 GCs)"
-native speed 3
"Elapsed time: 92.288413s (47.509687s in 1816 GCs)"
My explanation for that (you'll tell me if it makes sense) is that
having to load by hand all the .eln we start the test native compiled
tests with a bigger heap:
(heap 1024 1065 464) vs (heap 1024 7561 376)
As a consequence GC triggers way less often and in the total result
count less. This makes a huge difference in a test like this where GC
time contribute to ~50% of the perf result.
It's not easy to start we with a comparable status for the GC in this
situation so I think makes sense to compare just the execution time
having removed the GC form the equation. If we do this:
| | bytecode | native | native | speed 3 vs |
| | | speed 2 | speed 3 | bytecode |
|-------------+----------+---------+---------+------------|
| non GC time | 80 | 49 | 44 | 1.8x |
| GC time | 77 | 46 | 48 | |
| Total | 157 | 95 | 92 | |
So ~1.8x of execution time excluding GC for the native compiler in the
current statu.
Please let me know if something looks wrong.
There's an heap of room for improvements but I think I'll leave the perf
focus for now to continue the bring-up of the missing essential
features.
Andrea
--
address@hidden
- Re: On elisp running native,
Andrea Corallo <=
- Re: On elisp running native, Andrea Corallo, 2019/12/08
- Re: On elisp running native, Andrea Corallo, 2019/12/26
- Re: On elisp running native, Eli Zaretskii, 2019/12/26
- Re: On elisp running native, Andrea Corallo, 2019/12/26
- Re: On elisp running native, Eli Zaretskii, 2019/12/26
- Re: On elisp running native, Andrea Corallo, 2019/12/26
- Re: On elisp running native, Eli Zaretskii, 2019/12/27
- Re: On elisp running native, Andrea Corallo, 2019/12/27
- Re: On elisp running native, Eli Zaretskii, 2019/12/27