Re: Enabling native compilation by default when libgccjit is present

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> I'd be curious to know where people are seeing speedups.
>>
>> In my experience nativecomp is somewhat noticeable while using lsp-mode.
>>
>> Otherwise, not much, if at all.
>
> In some micro-benchmarks, I see significant speedups.  Let's see...
> what did I test last...
>
> Right:
>
> ---
> ;; (benchmark-run 1000 (benchy))
>
> (defun benchy ()
>   (let ((syms 0))
>     (mapatoms (lambda (sym)
>               (setq syms (+ syms (length (symbol-name sym)))))
>             obarray)
>     syms))
> ---
>
> This is 50% faster with nativecomp than without.
>
> It's easy to be fooled when trying to benchmark, since an "emacs -Q"
> doesn't native-comp the bits you're trying to benchmark, necessarily.
> (Unless you've done a full AOT build, which most people don't.)
>
> But still, even when that's done correctly, the nativecomp speedups are
> pretty elusive in real world code.  For instance, I'd expect shr
> rendering to be significantly speeded up when doing table-based layouts,
> because it's doing a lot of...  stuff.  But:
>
> (benchmark-run 10 (eww-open-file "/tmp/foo.html"))
>
> stubbornly takes the same amount of time with or without nativecomp,
> and it's the same way with every real bit of code I've tested (like byte
> compilation, which I'd also expect to be faster with nativecomp).
>
> So I don't know whether something is defeating nativecomp things in more
> complex situations.

Have you tried speed 3 with native comp?

>> The reason for this is not hard to understand for anyone with a little
>> bit of knowledge about binary code optimization. For instance, if your
>> Elisp code consists on invoking opaque C primitives, the gain of
>> compiling it to machine instructions will be mostly irrelevant.
>
> My micro-benchmark up there is almost all opaque C primitives, but is
> helped a lot.

If I remember old days before native-comp, anonymous lambads were not
byte-compiled? I maybe missunderstand, but that means the above lambda is
running interpretted without native comp, but with native comp it gets compiled
(update 8: https://akrl.sdf.org/gccemacs.html#orga9203de) and update 9 talkes
something about lambda performance. I am not sure that kicks in to be honest,
maybe I missunderstand.

After second thought I also think that Helm is getting help a lot by lambda
performance, which might explain why Emacs feels snappier in my case.