Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen <larsi@gnus.org>]

Ó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.

> 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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no