path: root/2021/captions/emacsconf-2021-native--emacs-lisp-native-compiler-current-status-and-future-developments--andrea-corallo--main.vtt

WEBVTT

00:00.200 --> 00:02.340
Hi everybody, my name is Andrea Corallo,

00:02.440 --> 00:03.280
and this presentation is about

00:03.382 --> 00:05.802
the Emacs Lisp Native Compiler --

00:05.904 --> 00:07.083
having GNU Emacs able to

00:07.184 --> 00:08.805
compile and run Emacs Lisp as native code.

00:08.907 --> 00:11.565
This project has been my hobby project

00:11.667 --> 00:14.009
for the last about two years and a half

00:14.111 --> 00:15.408
And we will see a little bit

00:15.509 --> 00:16.969
where this project is coming from,

00:17.070 --> 00:18.913
where we are, and where we want to go.

00:19.015 --> 00:20.571
So essentially everything you need to know

00:20.672 --> 00:22.132
about the Emacs Lisp Native Compiler,

00:22.232 --> 00:23.416
and probably a little more.

00:23.521 --> 00:26.535
Just a little bit of context on Emacs Lisp.

00:26.635 --> 00:30.175
Well, Emacs Lisp is a programming language,

00:30.278 --> 00:33.544
it's indeed a Lisp,

00:33.647 --> 00:36.619
and one year ago I looked for some statistics,

00:36.722 --> 00:38.742
and I was kind of pleased to see

00:38.842 --> 00:40.030
-- surprised to see actually --

00:40.132 --> 00:40.972
that it's still kind of popular

00:41.073 --> 00:42.844
as a programming language.

00:42.944 --> 00:43.684
It doesn't rank that bad

00:43.785 --> 00:45.554
against other programming languages.

00:45.658 --> 00:48.387
Also, the other important fact about Emacs Lisp

00:48.487 --> 00:51.518
is that there is a lot of Emacs Lisp out there,

00:51.622 --> 00:55.922
and this will have an impact [on this project.]

00:56.025 --> 00:57.632
It's a programming language that is capable

00:57.734 --> 00:59.320
of almost any task, so it's

00:59.420 --> 01:01.728
almost a general-purpose programming language,

01:01.831 --> 01:04.116
and this reflects on Emacs itself,

01:04.217 --> 01:07.232
that it's capable of almost any task.

01:07.335 --> 01:09.679
Indeed this "almost" is something we want to fix,

01:09.781 --> 01:10.720
because we want to do everything,

01:10.820 --> 01:14.218
we want [to do] all of our computing [with Emacs].

01:14.321 --> 01:16.523
Also, an interesting aspect for me

01:16.625 --> 01:18.903
is that it's not specified by any standard.

01:19.005 --> 01:22.507
This implies it can evolve in a more agile way

01:22.609 --> 01:25.667
without having to change the standard, etc.

01:25.770 --> 01:27.870
And, in fact, it's kind of improving,

01:27.970 --> 01:30.370
I believe relatively fast.

01:30.473 --> 01:32.791
A little bit about Lisp in general.

01:32.892 --> 01:34.952
First, it's the best programming language ever,

01:35.052 --> 01:35.712
we all know it.

01:35.813 --> 01:37.833
It has a lot of very nice properties,

01:37.934 --> 01:40.356
like it's dynamic, it's homoiconic, etc.

01:40.462 --> 01:42.394
But the interesting thing for implementors,

01:42.496 --> 01:43.476
is that, in theory,

01:43.576 --> 01:46.716
it can be implemented with very few primitives.

01:46.817 --> 01:49.485
You build very few primitives that are like magic,

01:49.590 --> 01:51.838
and on top of this,

01:51.938 --> 01:53.770
you can implement the whole language.

01:53.873 --> 01:55.759
This sounds very nice,

01:55.860 --> 01:57.280
and very appealing for implementors

01:57.381 --> 02:00.175
meaning to implement a new Lisp implementation,

02:00.279 --> 02:02.539
or improving or modifying an existing one.

02:02.641 --> 02:04.163
So the question is:

02:04.263 --> 02:07.663
how many primitives do we have to implement

02:07.764 --> 02:09.384
if we want to change

02:09.485 --> 02:13.203
the GNU Emacs Lisp implementation?

02:13.308 --> 02:20.128
Unfortunately, not really as few as we would like.

02:20.234 --> 02:25.294
In GNU Emacs, we have about 1500 primitives,

02:25.400 --> 02:27.970
and the main reason for that is performance.

02:28.071 --> 02:30.961
Actually, GNU Emacs was written

02:31.064 --> 02:34.292
when performance was a big issue,

02:34.393 --> 02:36.493
and nowadays certain parts

02:36.594 --> 02:38.486
are still performance-critical.

02:38.591 --> 02:40.295
We have a lot of C code;

02:40.395 --> 02:46.331
30% of the GNU Emacs codebase is C code,

02:46.435 --> 02:49.177
and we have to maintain this.

02:49.279 --> 02:52.859
But not only that, this is the main barrier

02:52.959 --> 02:55.579
for people that tried in the past

02:55.681 --> 02:57.663
to change the Emacs Lisp implementation.

02:57.765 --> 02:59.101
Because not only do you have to

02:59.202 --> 03:01.582
replace these primitives,

03:01.683 --> 03:03.907
all of them or part of them,

03:04.012 --> 03:06.384
but sometimes they also share (these primitives),

03:06.484 --> 03:07.952
internal data structures.

03:08.055 --> 03:09.745
For instance, it's very difficult to say:

03:09.846 --> 03:12.826
Now I want to go from C

03:12.926 --> 03:13.906
to a different programming language

03:14.006 --> 03:15.638
for implementing these primitives.

03:15.740 --> 03:17.028
So this has been, effectively,

03:17.128 --> 03:20.380
the main barrier for doing this work.

03:20.486 --> 03:22.090
Another interesting aspect

03:22.190 --> 03:23.870
about the GNU Emacs implementation

03:23.970 --> 03:26.190
is that Lisp can run interpreted

03:26.291 --> 03:28.647
or byte-compiled for performance,

03:28.752 --> 03:30.632
and the byte compiler itself

03:30.733 --> 03:32.673
is written in Emacs Lisp.

03:32.773 --> 03:35.033
This implies that GNU Emacs has to go through

03:35.134 --> 03:37.214
a bootstrap procedure in order to be built.

03:37.319 --> 03:38.715
But it's kind of interesting

03:38.815 --> 03:41.835
for something that started as a text editor,

03:41.937 --> 03:43.101
or something like it.

03:43.203 --> 03:47.877
The byte-code that is Emacs Lisp

03:47.979 --> 03:50.279
when it's been byte compiled,

03:50.379 --> 03:53.079
it's running on a stack-based virtual machine

03:53.180 --> 03:55.146
that is implemented in C.

03:55.253 --> 03:59.741
OK, so I've listed a bunch of areas

03:59.842 --> 04:02.074
where Emacs Lisp could improve:

04:02.178 --> 04:06.924
Namespace, Extensibility, Performance,

04:07.025 --> 04:11.239
and Debuggability, and Diagnostic, we could say.

04:11.346 --> 04:14.326
This activity, this project in particular,

04:14.428 --> 04:17.088
is affecting primarily Performance

04:17.189 --> 04:21.314
and the performance area the Execution Engine.

04:21.414 --> 04:22.570
That said,

04:22.671 --> 04:25.855
I think it has an impact also on Extensibility,

04:25.957 --> 04:27.811
and I hope it will have an impact also

04:27.913 --> 04:29.779
on programming diagnostics,

04:29.881 --> 04:32.501
so giving better warnings, [unknown].

04:32.604 --> 04:36.694
So which are the benefits

04:36.795 --> 04:39.215
of increasing the Emacs Lisp performance?

04:39.316 --> 04:42.976
Indeed, we will have, if we do that,

04:43.078 --> 04:45.668
programs that run faster.

04:45.774 --> 04:48.738
But the main implication of that

04:48.840 --> 04:50.760
is that we could write less C;

04:50.860 --> 04:52.940
we could maintain and debug less C.

04:53.041 --> 04:56.437
That is kind of a time-consuming task.

04:56.542 --> 04:59.502
And we could also allow for

04:59.603 --> 05:01.723
writing performance-critical extensions

05:01.824 --> 05:03.804
directly in Lisp

05:03.909 --> 05:06.305
without having to use systems like

05:06.406 --> 05:09.686
[I think there's a bunch.]

05:09.927 --> 05:14.791
These are very consistent benefits.

05:14.899 --> 05:16.669
OK, Project Goals,

05:16.769 --> 05:18.829
but I think the title of this slide

05:18.930 --> 05:21.520
maybe should be Project Requirements.

05:21.623 --> 05:23.231
So when I started this activity,

05:23.331 --> 05:26.943
I set some requirements for the project,

05:27.049 --> 05:29.469
with the main goal in mind: to go upstream.

05:29.570 --> 05:31.494
So I wanted to create something,

05:31.594 --> 05:34.250
a modified implementation of GNU Emacs,

05:34.353 --> 05:36.675
that was compatible

05:36.776 --> 05:38.596
as close to 100% as possible

05:38.696 --> 05:40.514
to the current implementation.

05:40.620 --> 05:42.720
And when I say "current implementation,"

05:42.820 --> 05:44.758
I don't refer to what

05:44.859 --> 05:46.879
the Emacs Lisp Programming Manual specifies

05:46.980 --> 05:49.804
as expected behavior of the implementation,

05:49.907 --> 05:52.207
but really the implementation itself.

05:52.309 --> 05:53.841
This is because there are a lot of corner cases

05:53.942 --> 05:56.390
that are not specified by the manual,

05:56.493 --> 05:58.093
but programs do rely on that,

05:58.193 --> 06:00.523
and given there is a ton of Emacs Lisp

06:00.625 --> 06:01.935
already around,

06:02.037 --> 06:05.437
compatibility was definitely a major requirement.

06:05.541 --> 06:07.727
I wanted to produce something that had

06:07.827 --> 06:09.587
reduced impact on the Emacs codebase,

06:09.687 --> 06:11.543
at least as much as possible.

06:11.644 --> 06:14.724
So I didn't want to rewrite all of GNU Emacs.

06:14.827 --> 06:17.609
Indeed, because it would have been

06:17.710 --> 06:21.068
too much work for one single person,

06:21.171 --> 06:25.371
but also still thinking

06:25.473 --> 06:29.153
to an upstream outcome all of this time.

06:29.258 --> 06:31.974
Another requirement was to have

06:32.076 --> 06:34.700
no, or very reduced, impact on the user,

06:34.804 --> 06:36.456
so I didn't want to change

06:36.556 --> 06:38.604
the way Emacs is used by you.

06:38.708 --> 06:40.618
And last but not least,

06:40.718 --> 06:42.848
introducing new dependencies,

06:42.951 --> 06:45.379
those dependencies had to be Free Software,

06:45.479 --> 06:47.191
possibly GPL,

06:47.295 --> 06:49.995
and also an important requirement

06:50.097 --> 06:52.941
is that these dependencies had to be

06:53.043 --> 06:55.143
some kind of trusted software that we know

06:55.243 --> 06:56.681
is going to be maintained in the future.

06:56.781 --> 06:59.261
Given Emacs has been around since forever,

06:59.363 --> 07:01.183
and will be around forever and ever,

07:01.285 --> 07:05.265
this was another very important point.

07:05.367 --> 07:08.707
A little bit of history of this project/

07:08.808 --> 07:10.648
a quick timeline.

07:10.748 --> 07:14.388
2019, in May, I did my first commit,

07:14.490 --> 07:17.110
I think it was when I tried to write

07:17.210 --> 07:20.230
my first primitive function ever in C,

07:20.332 --> 07:21.752
in GNU Emacs.

07:21.852 --> 07:24.832
And this was an attempt to try to compile

07:24.934 --> 07:30.314
a function that, once executed, returning [?]

07:30.415 --> 07:33.755
That was it. Six months after (about),

07:33.857 --> 07:37.057
I had something that was kind of working,

07:37.157 --> 07:42.797
So I was able to start up a semi-standard Emacs

07:42.899 --> 07:44.879
and then to compile and load,

07:44.981 --> 07:47.221
and replacing most of the functions

07:47.321 --> 07:50.921
that I had defined floating in my Lisp universe.

07:51.022 --> 07:54.202
Those functions are the functions

07:54.304 --> 07:55.944
that are essentially composing Emacs,

07:56.044 --> 07:57.884
at least the Lisp side of Emacs.

07:57.984 --> 08:01.084
A lot of features were missing,

08:01.186 --> 08:03.426
like I had no Garbage Collector support,

08:03.526 --> 08:07.006
no bootstrap, I was not optimizing these functions

08:07.108 --> 08:10.068
Because optimization [would be broken].

08:10.169 --> 08:12.749
No image dump support, etc.

08:12.850 --> 08:16.330
But I think this proved the design could work.

08:16.431 --> 08:19.171
So I sent to email to emacs-devel. I said

08:19.272 --> 08:20.852
I have this stuff I'm working on,

08:20.953 --> 08:24.613
and I wanted some feedback from the upstream

08:24.714 --> 08:27.534
to see if there was some interest.

08:27.635 --> 08:30.455
I believe the outcome of this was positive

08:30.557 --> 08:32.837
because about one month after,

08:32.937 --> 08:35.697
I pushed my branch within the Emacs git

08:35.798 --> 08:38.438
as a feature branch, and shortly after,

08:38.539 --> 08:42.679
we started to use the bug tracker to track bugs.

08:42.779 --> 08:45.479
So essentially we moved the development

08:45.580 --> 08:50.040
on the upstream infrastructure.

08:50.140 --> 08:55.620
I believe two years after the first commit,

08:55.721 --> 08:57.781
the project was merged

08:57.882 --> 09:00.922
after literally hundreds of bugs solved,

09:01.022 --> 09:03.842
and improvements, suggestions [unknown]

09:03.943 --> 09:08.623
and this was about six months ago.

09:08.723 --> 09:12.363
Before discussing how the native compiler works,

09:12.464 --> 09:14.224
I think it's worth looking at

09:14.324 --> 09:17.644
how Lisp is implemented in GNU Emacs.

09:17.745 --> 09:19.305
We have Lisp_Objects

09:19.405 --> 09:21.945
floating around our Lisp universe,

09:22.045 --> 09:23.905
and they are internally represented in this way.

09:24.006 --> 09:25.606
We have what is called a tagged pointer,

09:25.706 --> 09:27.406
that is just a regular pointer

09:27.506 --> 09:29.286
that is pointing to the area of memory

09:29.386 --> 09:31.926
where we hold the real data of the object.

09:32.027 --> 09:34.187
But within this tagged pointer,

09:34.287 --> 09:36.747
we reserve a few bits

09:36.848 --> 09:38.968
to indicate the type of object we are pointing to.

09:39.068 --> 09:40.528
This is important because

09:40.628 --> 09:42.288
each time we access an object,

09:42.388 --> 09:46.168
we have to typically check those bits

09:46.269 --> 09:49.029
to check that the object we are manipulating

09:49.129 --> 09:50.529
is of the right kind,

09:50.630 --> 09:52.530
remove those bits, and, if we are happy,

09:52.630 --> 09:55.810
access the object, otherwise [unknown].

09:55.910 --> 09:57.690
All the objects are like this,

09:57.791 --> 09:59.731
except for typically Fixnums,

09:59.831 --> 10:01.031
that are small integers

10:01.131 --> 10:04.891
that we manage to fit directly within the pointer.

10:04.992 --> 10:07.292
Also for manipulating Fixnums,

10:07.392 --> 10:09.412
we have to check the tag bits each time.

10:09.513 --> 10:13.173
Whenever we are not sure of the type of object

10:13.273 --> 10:16.493
we are manipulating (read: almost every time),

10:16.594 --> 10:18.914
we have to check those bits and remove those bits

10:19.014 --> 10:21.754
before doing any manipulation on the Fixnum.

10:21.854 --> 10:26.014
How Emacs Lisp is byte-compiled and executed

10:26.115 --> 10:27.775
in, let's call it, "Vanilla".

10:27.875 --> 10:30.055
If we have a Lisp expression of this kind:

10:30.156 --> 10:32.776
We take the variable 'a' we do plus 2,

10:32.876 --> 10:34.876
and then we multiply the result by 3,

10:34.976 --> 10:37.376
the byte compiler will produce this LAP code.

10:37.477 --> 10:38.497
LAP code is essentially

10:38.597 --> 10:40.017
the assembly for the byte-code,

10:40.117 --> 10:43.697
so it's the "intermediate representation"

10:43.798 --> 10:48.458
that will assembled into byte-code. (.elc files)

10:48.558 --> 10:50.738
How is this program executed?

10:50.839 --> 10:53.639
As I mentioned, it's executed in a virtual machine

10:53.739 --> 10:55.699
that is stack-based,

10:55.800 --> 10:58.540
but we start with an execution stack that's empty,

10:58.640 --> 11:01.680
and a stack pointer pointing to its bottom.

11:01.780 --> 11:04.280
And we execute the first instruction,

11:04.380 --> 11:07.120
that is pushing in the stack the value of 'a',

11:07.220 --> 11:10.360
in this case, 100. Then we push the constant 2.

11:10.460 --> 11:12.400
Then we do the summation,

11:12.500 --> 11:14.040
and we have the result in the stack.

11:14.140 --> 11:16.860
Same: we push the constant 3,

11:16.960 --> 11:17.620
we do the multiplication,

11:17.720 --> 11:19.260
and we will be able to return.

11:19.360 --> 11:22.700
Now, what's good and what's bad about this?

11:22.800 --> 11:25.800
A good thing is that it's very simple

11:25.900 --> 11:27.460
to start from Lisp

11:27.560 --> 11:31.320
and compile this kind of LAP output.

11:31.420 --> 11:34.240
At least it's reasonably simple.

11:34.340 --> 11:36.240
The compiler is not that complex.

11:36.340 --> 11:39.000
The bad thing is that all this machinery

11:39.100 --> 11:40.660
-- push and pop, etc. --

11:40.760 --> 11:44.320
it's very different from how a modern CPU works.

11:44.420 --> 11:45.720
Because modern CPUs,

11:45.820 --> 11:47.660
they are not stack-based anymore

11:47.760 --> 11:50.900
but they have instead a fixed number of registers,

11:51.000 --> 11:54.020
and they work with assignment and operation

11:54.120 --> 11:55.040
within these registers

11:55.140 --> 11:57.040
that are generally called "general-purpose."

11:57.140 --> 11:59.260
So to execute this LAP program,

11:59.360 --> 12:00.760
there is another program,

12:00.860 --> 12:02.600
that is the implementation of the VM itself

12:02.700 --> 12:06.400
that is doing conversion during runtime.

12:06.500 --> 12:08.320
So it's interpreting the LAP program

12:08.420 --> 12:11.360
and it's converting it into instructions

12:11.460 --> 12:13.180
that we can execute on the CPU.

12:13.280 --> 12:14.940
This conversion is done each time

12:15.040 --> 12:17.100
we will run some byte-code.

12:17.200 --> 12:19.760
And it's something that we want to avoid.

12:19.860 --> 12:21.560
Instead of this live conversion,

12:21.660 --> 12:26.220
we want to convert once:

12:26.320 --> 12:28.920
our Lisp program into native code,

12:29.020 --> 12:32.380
that is, a binary program that can be executed

12:32.480 --> 12:34.400
directly by our CPU.

12:34.500 --> 12:36.680
We want to save all this unnecessary conversion

12:36.780 --> 12:39.000
that we do each time we are running a program

12:39.100 --> 12:39.760
while we are running it.

12:39.860 --> 12:42.060
And we want to do this process just once,

12:42.160 --> 12:43.740
when we are compiling.

12:43.840 --> 12:46.240
That's the main goal of this activity.

12:46.340 --> 12:50.200
How is the byte compiler implemented?

12:50.300 --> 12:53.940
As any compiler it's a pipeline of transformations.

12:54.040 --> 12:58.560
We go through macro expansion, closure conversion,

12:58.660 --> 13:02.120
we have a bunch of source level optimization.

13:02.220 --> 13:03.940
Then we go into LAP,

13:04.040 --> 13:06.800
that's the transformation we are interested in,

13:06.900 --> 13:10.600
and after a few optimizations on LAP,

13:10.700 --> 13:14.140
LAP is assembled into byte-code.

13:14.240 --> 13:16.880
So if we [list it]

13:16.980 --> 13:19.320
in terms of intermediate representations,

13:19.420 --> 13:23.600
we can simplify this pipeline like this.

13:23.700 --> 13:26.100
We start with Lisp, and at a certain point

13:26.200 --> 13:29.520
we are manipulating the program in LAP form,

13:29.620 --> 13:31.980
and then at the end we produce the byte-code

13:32.080 --> 13:34.560
that is the .elc file that [you run]

13:34.660 --> 13:37.660
What I wanted to realize was something like this.

13:37.760 --> 13:41.200
I wanted to start from LAP, do something,

13:41.300 --> 13:44.600
and jump into GCC using libgccjit

13:44.700 --> 13:45.560
and in particular

13:45.660 --> 13:48.000
the libgccjit Intermediate Representation

13:48.100 --> 13:50.340
that we will discuss.

13:50.440 --> 13:53.120
Now, why I wanted to do something like this?

13:53.220 --> 13:57.300
Essentially, writing a compiler from scratch

13:57.400 --> 14:01.520
for Emacs Lisp would have been a very big task.

14:01.620 --> 14:05.120
So I wanted to rely on, as much as I could,

14:05.220 --> 14:07.180
the Emacs Lisp byte compiler,

14:07.280 --> 14:10.280
because I had to produce something

14:10.380 --> 14:12.920
that was as compatible as possible

14:13.020 --> 14:14.240
to the current implementation.

14:14.340 --> 14:18.340
So this was (I believe) a very good idea

14:18.440 --> 14:20.520
to save an enormous quantity of work

14:20.620 --> 14:22.340
and to produce something

14:22.440 --> 14:24.940
that was compatible in terms of semantics

14:25.040 --> 14:26.820
with the original implementation.

14:26.920 --> 14:30.660
Also, I didn't want to implement a code generator

14:30.760 --> 14:32.860
for each architecture we were targeting,

14:32.960 --> 14:35.900
nor wanted to implement all these optimizations

14:36.000 --> 14:37.840
that are already in GCC,

14:37.940 --> 14:40.120
so I thought it was a good idea

14:40.220 --> 14:44.720
to rely on an existing compiler like GCC [?].

14:44.820 --> 14:47.240
Let's talk about libgccjit.

14:47.340 --> 14:50.180
It was added by David Malcolm in GCC 5

14:50.280 --> 14:55.680
It allows you to describe a C-ish semantic to GCC

14:55.780 --> 14:57.380
and have it compile.

14:57.480 --> 15:01.400
It's good for [reading] Jitters or AoT compilers.

15:01.500 --> 15:04.400
And if we talk about GCC:

15:04.500 --> 15:07.180
it's a compiler, it's a very good one,

15:07.280 --> 15:09.340
it has support for a remarkable number

15:09.440 --> 15:11.640
of target architectures.

15:11.740 --> 15:15.080
It's also very good at generating [fast code],

15:15.180 --> 15:17.980
and it's been around for a long time;

15:18.080 --> 15:21.200
I believe it's like 1 year younger than Emacs.

15:21.300 --> 15:23.220
It's still very well maintained,

15:23.320 --> 15:25.840
and we can assume it will be maintained

15:25.940 --> 15:28.920
for quite a while. And, as I mentioned,

15:29.020 --> 15:31.120
this was a very important point.

15:31.220 --> 15:33.860
Also, it's GPL; it's Free Software,

15:33.960 --> 15:36.120
and it's developed under the GNU umbrella,

15:36.220 --> 15:40.360
so I thought it was a very good option.

15:40.460 --> 15:43.300
So we can imagine a simple translation

15:43.400 --> 15:46.400
that goes from LAP to this subset of C

15:46.500 --> 15:48.880
that we can describe to libgccjit.

15:48.980 --> 15:52.880
This simple translation we can see here,

15:52.980 --> 15:55.680
it's actually pretty trivial.

15:55.780 --> 15:58.500
Instead of doing operations

15:58.600 --> 16:02.060
within the execution stack we have seen before,

16:02.160 --> 16:05.080
we have just an array that is replacing it,

16:05.180 --> 16:07.380
and it's called 'local' in this case,

16:07.480 --> 16:12.360
and we have assignments within this array,

16:12.460 --> 16:15.140
so that they are done in place of the original

16:15.240 --> 16:17.100
push and pop activity of the stack.

16:17.200 --> 16:18.280
The nice thing is that,

16:18.380 --> 16:20.260
when you have done this translation,

16:20.360 --> 16:23.160
GCC will be able to optimize this,

16:23.260 --> 16:25.840
and remove all the unnecessary operations,

16:25.940 --> 16:27.180
and generate code

16:27.280 --> 16:29.660
for the specific CPU you are targeting,

16:29.760 --> 16:32.020
[which will be running your code].

16:32.120 --> 16:34.920
This sounds great; it sounds like

16:35.020 --> 16:37.440
a very simple and effective translation,

16:37.540 --> 16:39.920
and in fact the first iteration of my compiler

16:40.020 --> 16:41.120
was doing just this.

16:41.220 --> 16:45.320
It was essentially a big C function

16:45.420 --> 16:48.240
that was taking LAP and doing this conversion

16:48.340 --> 16:50.120
describing the output to libgccjit.

16:50.220 --> 16:53.720
Unfortunately, if you do this,

16:53.820 --> 16:55.740
you will discover that you have

16:55.840 --> 17:00.080
a performance upper bound limit of about 3x.

17:00.180 --> 17:04.360
So it was an option,

17:04.460 --> 17:06.560
but I thought it was a good occasion

17:06.660 --> 17:08.980
for trying to do something more.

17:09.080 --> 17:11.640
And doing something more means

17:11.740 --> 17:13.680
implementing a smarter compiler

17:13.780 --> 17:17.180
that is doing some advanced analysis on the code,

17:17.280 --> 17:18.640
and will be able to perform

17:18.740 --> 17:20.700
Lisp-specific optimizations

17:20.800 --> 17:22.480
-- optimizations that take advantage of

17:22.580 --> 17:24.960
the specific Lisp semantics,

17:25.060 --> 17:27.760
something that GCC is not aware of.

17:27.860 --> 17:31.240
And while I was thinking about that,

17:31.340 --> 17:34.000
I thought that having a smarter compiler

17:34.100 --> 17:38.120
had also other advantages, like a smarter compiler

17:38.220 --> 17:40.120
that understands the semantics

17:40.220 --> 17:41.820
of the programming language being compiled

17:41.920 --> 17:43.680
would be also capable of

17:43.780 --> 17:45.620
giving feedback to the programmers,

17:45.720 --> 17:47.920
like better warnings and errors.

17:48.020 --> 17:51.360
So I was really fascinated about this idea,

17:51.460 --> 17:53.240
and I wanted to change my implementation

17:53.340 --> 17:55.920
because I was not really happy about it.

17:56.020 --> 17:58.320
I had a lot of C code in terms of

17:58.420 --> 18:02.100
lines that were not doing any smart job.

18:02.200 --> 18:07.380
And I wanted to write all the interesting logic

18:07.480 --> 18:09.940
[in Lisp].

18:10.040 --> 18:12.560
So optimizing outside GCC

18:12.660 --> 18:15.840
before jumping into GCC,

18:15.940 --> 18:20.500
as I mentioned, has two main targets:

18:20.600 --> 18:23.060
Either optimize the code before going into GCC,

18:23.160 --> 18:25.380
or present to GCC some code

18:25.480 --> 18:27.740
that we know GCC can optimize effectively.

18:27.840 --> 18:30.800
And also, this will give, as I mentioned,

18:30.900 --> 18:32.660
better options for the compiler

18:32.760 --> 18:34.420
to provide warnings, errors

18:34.520 --> 18:36.340
-- better diagnostics.

18:36.440 --> 18:38.200
So this is pretty much

18:38.300 --> 18:40.640
what the native compiler looks like nowadays,

18:40.740 --> 18:42.720
in terms of passes.

18:42.820 --> 18:44.560
We have a list of passes,

18:44.660 --> 18:46.620
each of which is taking an input

18:46.720 --> 18:48.120
and producing an output.

18:48.220 --> 18:51.040
So it's doing either analysis on the program

18:51.140 --> 18:52.640
that's being passed,

18:52.740 --> 18:54.760
or it's performing a transformation.

18:54.860 --> 18:57.900
All of these passes are implemented in Lisp,

18:58.000 --> 19:00.440
and only the last pass is implemented in C.

19:00.540 --> 19:05.060
That is the one that is talking to libgccjit.

19:05.160 --> 19:07.760
To do that, I have introduced

19:07.860 --> 19:10.640
a new intermediate representation

19:10.740 --> 19:13.960
that I call LIMPLE, as a tribute to GCC GIMPLE,

19:14.060 --> 19:17.220
that is the main internal representation of GCC,

19:17.320 --> 19:20.600
at least one of the main ones.

19:20.700 --> 19:25.080
Introducing a new intermediate representation

19:25.180 --> 19:27.720
-- a new way of representing my program --

19:27.820 --> 19:29.540
solved a bunch of problems.

19:29.640 --> 19:33.200
First, it allowed me to implement

19:33.300 --> 19:37.280
non-trivial analysis and transformations,

19:37.380 --> 19:40.000
the ones I needed in my compiler pipeline.

19:40.100 --> 19:42.160
But also, it solved the problem of

19:42.260 --> 19:43.840
what was the boundary between

19:43.940 --> 19:46.120
what I had to implement in Lisp,

19:46.220 --> 19:48.040
and what in C.

19:48.140 --> 19:49.040
Because once I had

19:49.140 --> 19:51.860
my intermediate representation defined,

19:51.960 --> 19:53.780
essentially the boundary between Lisp and C

19:53.880 --> 19:55.640
is just a function, that is,

19:55.740 --> 19:57.780
the one that is implementing the final pass.

19:57.880 --> 19:59.220
That is taking, as an input,

19:59.320 --> 20:01.620
all of my programs in LIMPLE representation

20:01.720 --> 20:03.880
and it's doing [his bit].

20:03.980 --> 20:07.980
So I was convinced this design at least had sense.

20:08.080 --> 20:10.120
When we go through some of these passes,

20:10.220 --> 20:12.600
just to give you an idea of what these are doing:

20:12.700 --> 20:14.560
the first pass is just responsible for

20:14.660 --> 20:18.100
spilling the LAP from the byte compiler

20:18.200 --> 20:20.160
that effectively here we are using as a front end

20:20.260 --> 20:21.780
for our compiler pipeline.

20:21.880 --> 20:24.040
The second pass, called 'limplify',

20:24.140 --> 20:27.920
will be in charge of converting LAP into LIMPLE.

20:28.020 --> 20:31.260
LIMPLE is an intermediate representation

20:31.360 --> 20:32.860
that is Control Flow Graph based,

20:32.960 --> 20:34.700
and it's capable of SSA.

20:34.800 --> 20:38.640
So we can have a look to what this means.

20:38.740 --> 20:41.300
Let's assume we have our LAP program,

20:41.400 --> 20:42.520
as any program,

20:42.620 --> 20:43.960
that's a simple list of instructions

20:44.060 --> 20:45.640
that we will execute one after the other.

20:45.740 --> 20:47.360
Some of these instructions

20:47.460 --> 20:49.200
are special instructions

20:49.300 --> 20:51.240
that we call conditional branches,

20:51.340 --> 20:52.800
where we check for a condition,

20:52.900 --> 20:54.320
and if this is verified,

20:54.420 --> 20:56.940
we jump to a different address within the program.

20:57.040 --> 20:59.580
(Addresses that here we are calling 'labels'.)

20:59.680 --> 21:03.440
So we can split our program in chunks,

21:03.540 --> 21:08.200
and those chunks we execute without interruption,

21:08.300 --> 21:10.460
so we always enter from the top of those,

21:10.560 --> 21:12.600
and we exit from the bottom.

21:12.700 --> 21:15.980
We can name those, and split them apart,

21:16.080 --> 21:18.980
and these are what we call basic blocks.

21:19.080 --> 21:22.360
And now we have a bunch of these basic blocks

21:22.460 --> 21:23.380
that are floating,

21:23.480 --> 21:25.020
and they are not any more sorted.

21:25.120 --> 21:25.920
This is what is called

21:26.020 --> 21:28.680
a Control Flow Graph based representation.

21:28.780 --> 21:31.400
Now we can get into the SSA topic.

21:31.500 --> 21:33.900
That stands for Static Single Assignment.

21:34.000 --> 21:35.860
I don't want to get into the details,

21:35.960 --> 21:36.720
but just give you a feeling.

21:36.820 --> 21:38.480
I added into our basic blocks

21:38.580 --> 21:41.400
in our Control Flow Graph a few assignments.

21:41.500 --> 21:43.840
We will transform this into SSA

21:43.940 --> 21:45.040
just for the variable 'x',

21:45.140 --> 21:47.360
just for the sake of demonstrating it.

21:47.460 --> 21:49.760
This is done through a number of phases

21:49.860 --> 21:51.760
that are essentially some analysis,

21:51.860 --> 21:52.600
mainly renaming.

21:52.700 --> 21:55.560
But the outcome, the one we see here,

21:55.660 --> 21:59.120
looks quite similar to the original one,

21:59.220 --> 22:01.120
but we can see that the variable 'x'

22:01.220 --> 22:01.960
has been renamed.

22:02.060 --> 22:03.400
And now we don't have anymore just one,

22:03.500 --> 22:06.140
but a number of these variables.

22:06.240 --> 22:08.000
The interesting property is that

22:08.100 --> 22:10.880
each of these variables is assigned just once.

22:10.980 --> 22:13.240
And this allows for the compiler

22:13.340 --> 22:16.760
to do prediction of the value of that variable,

22:16.860 --> 22:19.040
depending on the position

22:19.140 --> 22:19.840
within the Control Flow Graph.

22:19.940 --> 22:21.980
This is very important. For instance,

22:22.080 --> 22:23.440
a very simple case is 'x1'

22:23.540 --> 22:27.440
that we see is assigned once by definition,

22:27.540 --> 22:29.300
in particular here at the beginning.

22:29.400 --> 22:31.040
Here it's very simple to understand

22:31.140 --> 22:33.080
that x1 will have the value 3.

22:33.180 --> 22:35.380
While, for instance, it's more difficult to prove

22:35.480 --> 22:37.060
what is going to be the value of x5,

22:37.160 --> 22:38.620
because it's calling a function,

22:38.720 --> 22:41.940
or we don't know at the moment what x4 is.

22:42.040 --> 22:46.240
So the compiler will gain the capability

22:46.340 --> 22:48.460
to do prediction on all the variables,

22:48.560 --> 22:50.620
and the more we get information on one variable,

22:50.720 --> 22:54.980
the more we can prove about the others.

22:55.460 --> 22:57.280
Coming back to our passes, the next one

22:57.380 --> 22:59.320
is forward propagation.

22:59.420 --> 23:00.600
This pass is responsible for

23:00.700 --> 23:03.240
doing what I briefly mentioned just before:

23:03.340 --> 23:07.160
doing proof over all the different variables

23:07.260 --> 23:09.620
in different positions of the Control Flow Graph,

23:09.720 --> 23:12.700
about the values, types, or ranges.

23:12.800 --> 23:15.080
This pass is also responsible for

23:15.180 --> 23:16.920
executing functions

23:17.020 --> 23:18.640
when we know that the function has no side effect

23:18.740 --> 23:20.520
and the pass managed to

23:20.620 --> 23:22.440
prove all the values of its argument.

23:22.540 --> 23:24.800
So the function is then executed at compile time

23:24.900 --> 23:26.700
and it doesn't even exist anymore

23:26.800 --> 23:27.880
in the produced code.

23:27.980 --> 23:30.300
Then we have another pass, this is

23:30.400 --> 23:33.420
an example of a pass that is very specific:

23:33.520 --> 23:36.120
it's trying to remove the call to funcall

23:36.220 --> 23:38.040
when those are not necessary.

23:38.140 --> 23:39.760
There are a couple situations

23:39.860 --> 23:42.200
where this is very useful.

23:42.300 --> 23:45.240
And not only is this beneficial

23:45.340 --> 23:47.560
because we are generating better code,

23:47.660 --> 23:49.245
but when we manage to do that,

23:49.345 --> 23:52.000
we allow GCC better analysis over the code,

23:52.100 --> 23:54.440
because GCC knows nothing about funcall.

23:54.540 --> 23:57.400
So if we are calling, from 'foo', directly, 'bar',

23:57.500 --> 24:01.280
for GCC it's way easier to do its analysis

24:01.380 --> 24:03.360
on top of this code.

24:03.460 --> 24:06.240
Another interesting pass we can mention is 'tco'.

24:06.340 --> 24:08.800
This is performing Tail Recursion Elimination.

24:08.900 --> 24:11.880
It allows a more functional programming style,

24:11.980 --> 24:13.220
if you want.

24:13.320 --> 24:14.280
We can jump to the last pass

24:14.380 --> 24:16.200
that is called 'final', and as I mentioned,

24:16.300 --> 24:17.520
this one is responsible for

24:17.620 --> 24:19.880
taking our program in LIMPLE representation

24:19.980 --> 24:24.900
and describing it to libgccjit in the gccjit IR.

24:25.000 --> 24:27.480
That's the main task. It's also

24:27.580 --> 24:29.520
defining inline functions

24:29.620 --> 24:32.400
for accessing fundamental data types, and so on.

24:32.500 --> 24:34.460
This pass is also responsible for

24:34.560 --> 24:36.280
using some of the predictions

24:36.380 --> 24:39.560
done by previous passes to generate better code.

24:39.660 --> 24:41.320
Things we had to add

24:41.420 --> 24:43.880
to have all of this machinery work

24:43.980 --> 24:45.240
and to be controllable:

24:45.340 --> 24:47.480
The first one is an opt called 'native-comp-speed'

24:47.580 --> 24:49.920
and it's equivalent to Common Lisp's 'speed'.

24:50.020 --> 24:51.920
It represents the optimization level.

24:52.020 --> 24:53.400
The default is 2 and is

24:53.500 --> 24:55.400
the maximum optimization level

24:55.500 --> 24:58.600
that is meant to reflect

24:58.700 --> 25:00.860
all the original semantics of Emacs Lisp.

25:00.960 --> 25:02.480
So it's the one that should be used by default.

25:02.580 --> 25:04.640
The second one is 'compilation unit'

25:04.740 --> 25:05.960
and it's a kind of new object

25:06.060 --> 25:11.080
that has been added to Emacs.

25:11.180 --> 25:12.960
Let's have a look to

25:13.060 --> 25:14.360
how the Garbage Collector works in this case.

25:14.460 --> 25:15.840
The GNU Emacs Garbage Collector

25:15.940 --> 25:18.660
is a simple mark-and-sweep garbage collector.

25:18.760 --> 25:21.420
It does a tree walk through all the objects

25:21.520 --> 25:25.100
and follows references from one object to another.

25:25.200 --> 25:27.960
All the objects reachable during the mark phase

25:28.060 --> 25:31.240
will be kept in our Lisp universe.

25:31.340 --> 25:33.680
All the other ones will be freed.

25:33.780 --> 25:35.080
In this case we have a bunch of functions,

25:35.180 --> 25:38.760
'foo1', 'foo2', 'bar1', etc., that are defined.

25:38.860 --> 25:40.320
When a function is defined,

25:40.420 --> 25:42.400
it's accessible through its symbol,

25:42.500 --> 25:44.360
so we have the symbol referring to the function.

25:44.460 --> 25:47.720
The function, in this case a native-compiled one,

25:47.820 --> 25:50.040
is referring to the compilation unit.

25:50.140 --> 25:53.020
The compilation unit is essentially

25:53.120 --> 25:58.600
the ELF file that has been compiled,

25:58.700 --> 26:01.160
and contains all those functions

26:01.260 --> 26:03.240
that came from the original .el file,

26:03.340 --> 26:05.100
and that we have loaded into memory.

26:05.200 --> 26:10.000
If, for instance, 'bar1 and 'bar2 are undefined,

26:10.100 --> 26:14.200
functions [3] and 4 will be no longer reachable,

26:14.300 --> 26:16.040
and we will be able to free them

26:16.140 --> 26:18.160
and unload the compilation unit.

26:18.260 --> 26:21.200
We discussed quite a lot about Control Flow Graph,

26:21.300 --> 26:23.560
SSA, and a lot of boring stuff,

26:23.660 --> 26:25.400
and I promised you that we are doing

26:25.500 --> 26:27.320
a lot of interesting proofs over variables,

26:27.420 --> 26:30.220
So let's have some examples of them.

26:30.320 --> 26:31.840
Let's jump into a quick demo

26:31.940 --> 26:34.480
to see what all of this abstract theory

26:34.580 --> 26:37.680
and this esoteric propagation engine can do for us

26:37.780 --> 26:39.240
and how the user can interact with it.

26:39.340 --> 26:42.100
I've defined a bunch of functions,

26:42.200 --> 26:45.240
and I will native-compile and load it.

26:47.500 --> 26:48.840
Alright, Emacs Lisp native compiled and loaded.

26:48.940 --> 26:52.320
At this point, I can disassemble 'foo1'

26:52.420 --> 26:56.320
to make sure it's native code and I'm not lying.

26:56.420 --> 26:58.500
These are the instructions

26:58.600 --> 27:01.320
that will be executed directly by my CPU

27:01.420 --> 27:03.620
when I call this function.

27:03.720 --> 27:07.520
Alright, very cool.

27:07.620 --> 27:16.080
Now, [Lisp:] (symbol-function #'foo1)

27:16.180 --> 27:19.720
Interestingly, this is returning a subroutine,

27:19.820 --> 27:21.820
as it would be a primitive function.

27:21.920 --> 27:23.700
Because this is native code,

27:23.800 --> 27:24.840
even if it's written in Lisp,

27:24.940 --> 27:26.340
has been converted to native code

27:26.440 --> 27:29.200
as if it's a primitive function.

27:29.300 --> 27:31.560
But we can do also a new thing:

27:31.660 --> 27:34.440
asking for the type of the subroutine.

27:34.540 --> 27:38.360
Alright, very cool. It says this is a function,

27:38.460 --> 27:40.280
it's taking one argument of type 't'

27:40.380 --> 27:41.560
(that means anything

27:41.660 --> 27:42.960
because we don't have any information),

27:43.060 --> 27:45.200
and is returning a type 't',

27:45.300 --> 27:47.380
so also there we don't have much information.

27:47.480 --> 27:49.700
OK, very cool, but not very useful.

27:49.800 --> 27:53.680
Let's see #'foo2. #'foo2 is slightly different,

27:53.780 --> 27:55.840
it doesn't take any argument, but it's returning

27:55.940 --> 27:58.040
an integer included between 3 and 3.

27:58.140 --> 28:01.360
Wow, amazing!

28:01.460 --> 28:04.040
Let's get into something a little more complex:

28:04.140 --> 28:09.440
#'foo3 takes one argument we know nothing about,

28:09.540 --> 28:11.740
but it's returning a number.

28:11.840 --> 28:13.280
And why it's returning a number?

28:13.380 --> 28:16.320
Essentially because 1+ is returning a number,

28:16.420 --> 28:18.880
and in all the other cases,

28:18.980 --> 28:20.640
it would signal an error

28:20.740 --> 28:23.380
if it's not happy about its input argument.

28:23.480 --> 28:27.760
Let's have a look to #'foo4.

28:27.860 --> 28:32.920
#'foo4 is a little bit more complex.

28:33.020 --> 28:34.680
It will return nil

28:34.780 --> 28:37.400
if the 'when' condition is not satisfied,

28:37.500 --> 28:39.720
so it's type 'null' here.

28:39.820 --> 28:41.200
It can return a floating point;

28:41.300 --> 28:43.600
we don't do propagation of floating point so far,

28:43.700 --> 28:47.080
or it can return any integer between 4 and 9.

28:47.180 --> 28:52.840
Wow. Let's go on with #'foo5.

28:52.940 --> 28:55.760
#'foo5 is even more complex

28:55.860 --> 28:57.200
because other than

28:57.300 --> 28:59.180
having to satisfy this condition,

28:59.280 --> 29:02.280
we can see that the result of the propagation

29:02.380 --> 29:03.800
of this complex condition

29:03.900 --> 29:05.460
is propagated also across the 'plus'.

29:05.560 --> 29:08.240
So this foo5 can return nil,

29:08.340 --> 29:09.720
a floating point we know nothing about,

29:09.820 --> 29:13.560
or an integer included between 12 and 24.

29:13.660 --> 29:18.080
Let's go on with #'foo6.

29:18.180 --> 29:23.320
#'foo6 is returning anything but an integer.

29:23.420 --> 29:26.520
I think it should be pretty obvious why,

29:26.620 --> 29:28.120
because if it's not an integer we return it,

29:28.220 --> 29:30.000
otherwise we signal an error.

29:30.100 --> 29:32.880
Let's finish with #'foo7 very quickly.

29:32.980 --> 29:37.920
#'foo7 has another very complex condition,

29:38.020 --> 29:40.320
at least for me, but it's also interesting to see

29:40.420 --> 29:42.200
that we are also propagating values for symbols.

29:42.300 --> 29:45.160
So we can return the symbol 'big,

29:45.260 --> 29:46.980
the symbol 'small,

29:47.080 --> 29:51.200
or an integer included between -100 and 100.

29:51.300 --> 29:54.440
Now, the question is: why all of this is useful

29:54.540 --> 29:56.800
other than having Andrea very happy

29:56.900 --> 29:59.560
when he's playing with this all day?

29:59.660 --> 30:01.440
Well, we have to come back one second

30:01.540 --> 30:04.920
to how Lisp_Objects are represented within Emacs.

30:05.020 --> 30:09.480
Lisp_Objects are represented as machine words,

30:09.580 --> 30:12.580
where we reserve a few bits to indicate the type.

30:12.680 --> 30:15.560
And every time we access the object,

30:15.660 --> 30:17.120
when this is a Fixnum,

30:17.220 --> 30:19.920
or a regular object where this is a pointer,

30:20.020 --> 30:21.600
we always have to extract these bits,

30:21.700 --> 30:24.520
make sure that they satisfy a condition,

30:24.620 --> 30:27.120
so make sure that we are going to manipulate

30:27.220 --> 30:28.580
the object of the type we expect,

30:28.680 --> 30:31.040
and then we can extract the object

30:31.140 --> 30:32.540
and do the manipulation.

30:32.640 --> 30:34.420
If the compiler managed to prove

30:34.620 --> 30:37.400
that the contained object is of the right type,

30:37.500 --> 30:42.440
it will be able to not emit the type check,

30:42.540 --> 30:44.500
and save a lot of instructions.

30:44.600 --> 30:48.560
This is a very powerful optimization.

30:48.660 --> 30:50.760
Let's discuss some potential future development

30:50.860 --> 30:52.000
in this area.

30:52.100 --> 30:53.360
First I think it would be extremely nice

30:53.460 --> 30:54.920
to extend the propagation

30:55.020 --> 30:56.920
to types that are not built in.

30:57.020 --> 30:58.160
There are a lot of cases

30:58.260 --> 31:00.600
where we could optimize effectively.

31:00.700 --> 31:02.520
For instance when we do

31:02.620 --> 31:05.720
a lot of accesses to structures

31:05.820 --> 31:06.920
-- lots of stuff like that --

31:07.020 --> 31:08.880
where we keep on checking and checking

31:08.980 --> 31:10.640
the same object for the type

31:10.740 --> 31:13.080
where it's obvious, where it should be trivial

31:13.180 --> 31:14.720
to prove that it's the right type

31:14.820 --> 31:16.360
after the first access or things like that.

31:16.460 --> 31:18.920
So I believe this is a low-hanging fruit

31:19.020 --> 31:21.180
in terms of performance.

31:21.280 --> 31:23.080
Also I think it would be really nice

31:23.180 --> 31:24.720
to extend the declare mechanism

31:24.820 --> 31:27.600
to allow the user to declare argument types.

31:27.700 --> 31:30.480
(Optionally. Indeed, optionally.)

31:30.580 --> 31:32.880
Doing that would give the compiler

31:32.980 --> 31:35.120
a lot of information to propagate value types

31:35.220 --> 31:36.360
within the function.

31:36.460 --> 31:38.840
But those will allow the compiler

31:38.940 --> 31:43.040
to give the user really good diagnostics

31:43.140 --> 31:45.400
during compile time. Like the compiler could say:

31:45.500 --> 31:47.000
Hey, here you are calling a function

31:47.100 --> 31:49.200
that is expecting this argument of this type,

31:49.300 --> 31:52.000
but I'm proving that you are calling it

31:52.100 --> 31:55.200
with an argument that is of THIS type,

31:55.300 --> 31:57.840
and is not a subtype of the expected one.

31:57.940 --> 32:00.240
So you are doing something not coherent.

32:00.340 --> 32:02.800
This kind of interprocedural logic.

32:02.900 --> 32:05.000
And I think the compiler should also take advantage

32:05.100 --> 32:06.640
(under certain circumstances)

32:06.740 --> 32:08.760
of this interprocedural analysis

32:08.860 --> 32:12.520
in order to optimize even more, when possible.

32:12.620 --> 32:13.720
Also I think we should

32:13.820 --> 32:15.480
work on our [?] to improve the code generation

32:15.580 --> 32:17.100
depending on the prediction

32:17.200 --> 32:18.160
that the compiler is doing.

32:18.260 --> 32:20.120
We already take advantage of those predictions,

32:20.220 --> 32:22.300
but I think we could do better.

32:22.400 --> 32:25.120
A quick look at some performance results.

32:25.220 --> 32:28.720
These are from the elisp-benchmarks package

32:28.820 --> 32:30.760
within GNU ELPA.

32:30.860 --> 32:32.520
This is the performance uplift,

32:32.620 --> 32:38.480
and we can identify about 4 "classes" of results.

32:38.580 --> 32:41.440
The first one there is no performance uplift,

32:41.540 --> 32:42.880
because there is not much we can do,

32:42.980 --> 32:44.720
and the time is probably not spent

32:44.820 --> 32:46.280
within the execution engine.

32:46.380 --> 32:49.000
And the ones around 3x are the ones

32:49.100 --> 32:50.680
Where probably we are not triggering

32:50.780 --> 32:52.640
manually specific optimizations,

32:52.740 --> 32:53.600
but just the fact

32:53.700 --> 32:57.100
that we are converting into native code

32:57.200 --> 33:00.500
is giving us this performance uplift.

33:00.600 --> 33:03.280
Then there is a bunch of other benchmarks

33:03.380 --> 33:05.680
where the Lisp optimizations are triggering,

33:05.780 --> 33:09.620
and the uplift is way bigger,

33:09.720 --> 33:11.900
and then we have 3 benchmarks that at the time

33:12.000 --> 33:13.420
are completely optimized out.

33:13.520 --> 33:15.580
That means the compiler became "so smart"

33:15.680 --> 33:18.160
that it was able to compute the result

33:18.260 --> 33:20.160
in the compile time and just put the result

33:20.260 --> 33:21.400
in the generated binary.

33:21.500 --> 33:23.880
Let's discuss a little bit the compilation model.

33:23.980 --> 33:26.080
This is an Hybrid one;

33:26.180 --> 33:29.420
it's both JIT-like and Ahead-of-Time-like.

33:29.520 --> 33:33.400
Emacs is composed of what we call an Emacs image,

33:33.500 --> 33:36.180
essentially the Emacs binary that we start.

33:36.280 --> 33:37.720
It's including all the C code,

33:37.820 --> 33:41.760
plus all the Lisp code that we preload.

33:41.860 --> 33:46.480
Then we have the rest of the Emacs Lisp codebase

33:46.580 --> 33:49.440
that can be loaded just if it's required.

33:49.540 --> 33:52.760
Same for the external packages, if we have any.

33:52.860 --> 33:55.120
If we build an Emacs Lisp

33:55.220 --> 33:57.940
with native compilation enabled, by default,

33:58.040 --> 34:01.200
only the Emacs image will be native compiled.

34:01.300 --> 34:03.920
All the other code will be compiled

34:04.020 --> 34:06.720
on the fly when it's loaded and executed

34:06.820 --> 34:08.800
the first time, if it's necessary.

34:08.900 --> 34:10.880
Same for the packages, in a transparent way

34:10.980 --> 34:12.640
and asynchronous way.

34:12.740 --> 34:13.480
Also worth noting

34:13.580 --> 34:15.400
that the result of this compilation

34:15.500 --> 34:17.240
will be stored into a cache directory

34:17.340 --> 34:19.900
within the home directory of the user.

34:20.000 --> 34:23.600
So it will be reused in the following sessions

34:23.700 --> 34:25.440
if the same file is loaded,

34:25.540 --> 34:27.520
without having to recompile multiple times

34:27.620 --> 34:29.320
the same file in different sessions.

34:29.420 --> 34:31.520
It works a little bit like this:

34:31.620 --> 34:33.800
When we load the byte-code for the first time,

34:33.900 --> 34:35.900
we spawn a native compilation process.

34:36.000 --> 34:39.320
Meanwhile we keep using the byte-code available.

34:39.420 --> 34:41.180
When the native compilation is finished,

34:41.280 --> 34:43.960
we hot-swap the definition of the functions

34:44.060 --> 34:46.040
that are contained in the file

34:46.140 --> 34:47.960
and start using the native code transparently.

34:48.060 --> 34:49.880
We do this asynchronously,

34:49.980 --> 34:53.140
and for more compilation units at the same time,

34:53.240 --> 34:56.280
so it looks a little bit like this.

34:56.380 --> 34:58.560
Let's try a quick demo of all of this machinery.

34:58.660 --> 35:00.880
I've started a fresh Emacs

35:00.980 --> 35:03.280
with native compilation support,

35:03.380 --> 35:05.060
and at this moment nothing is going on.

35:05.160 --> 35:07.440
We will test the machinery with Tetris,

35:07.540 --> 35:10.460
because I can't imagine anything better

35:10.560 --> 35:12.840
to test this.

35:12.940 --> 35:15.080
What I do expect is that when I launch Tetris

35:15.180 --> 35:17.920
it will be loaded, it will immediately

35:18.020 --> 35:20.460
start execution of the byte-compiled version,

35:20.560 --> 35:23.000
so we won't see any delay in the user experience,

35:23.100 --> 35:25.160
and in the meanwhile, a parallel process

35:25.260 --> 35:28.160
will start to native-compile Tetris itself.

35:28.260 --> 35:30.200
When the native compilation will be finished,

35:30.300 --> 35:33.240
the functions of all Tetris will be hot-swapped.

35:33.340 --> 35:36.280
So we will not see any interruption.

35:36.380 --> 35:39.680
So Tetris started, and it's running,

35:39.780 --> 35:41.600
we have seen no delay, and in the meanwhile,

35:41.700 --> 35:43.520
the native compilation probably already finished,

35:43.620 --> 35:44.960
we can have a look.

35:45.060 --> 35:47.160
In this I see the native compilation log buffer.

35:47.260 --> 35:49.720
So we see that Tetris has been native compiled,

35:49.820 --> 35:51.760
and all of its dependencies.

35:51.860 --> 35:53.840
Now Tetris is still running,

35:53.940 --> 36:00.480
but I can do "C-h f tetris"

36:00.580 --> 36:02.540
and we can see that 'tetris'

36:02.640 --> 36:04.880
is an interactive native compiled

36:04.980 --> 36:07.940
Lisp function, so it has been native-compiled.

36:08.040 --> 36:13.500
I can even disassemble if I want.

36:13.600 --> 36:14.880
OK, so very cool.

36:14.980 --> 36:18.020
I guess we can say this mechanism is working.

36:18.120 --> 36:20.660
Also worth noting that if I go back

36:20.760 --> 36:24.120
to the *Async-native-compile-log* buffer,

36:24.220 --> 36:27.960
we see we have compiled another bunch of files.

36:28.060 --> 36:31.600
I think these are because of my 'C-h f',

36:31.700 --> 36:33.800
this help function command and disassemble,

36:33.900 --> 36:34.920
and so on.

36:35.020 --> 36:37.720
The first time you run Emacs, you will have,

36:37.820 --> 36:41.280
from time to time, these processes spawned.

36:41.380 --> 36:43.100
Emacs is "compiling itself",

36:43.200 --> 36:45.520
and it's replacing the byte-code definition

36:45.620 --> 36:47.640
with the native one. But after a few sessions,

36:47.740 --> 36:49.760
you will not see this anymore,

36:49.860 --> 36:51.360
because the output of this compilation,

36:51.460 --> 36:54.900
as I mentioned, are stored in the user directory.

36:55.000 --> 36:57.560
To conclude: Emacs with native compilation support

36:57.660 --> 36:59.080
is coming up in Emacs 28,

36:59.180 --> 37:01.040
that is gonna be the next major stable release

37:01.140 --> 37:02.080
that will be released.

37:02.180 --> 37:04.840
So we ought to celebrate with a big party,

37:04.940 --> 37:07.320
I believe. But before going to the party,

37:07.420 --> 37:09.080
I'd like to list a few points

37:09.180 --> 37:11.340
that I think have been success factors

37:11.440 --> 37:13.420
in upstreaming this work.

37:13.520 --> 37:15.420
It has been extremely important

37:15.520 --> 37:18.140
to get in touch with upstream as soon as possible,

37:18.240 --> 37:20.680
as soon as I had a proof of concept.

37:20.780 --> 37:22.600
It's been extremely important

37:22.700 --> 37:24.660
to involve the community as much as possible,

37:24.760 --> 37:28.480
and this included keeping a development blog,

37:28.580 --> 37:31.600
and posts about that on emacs-devel,

37:31.700 --> 37:33.720
and also producing material,

37:33.820 --> 37:36.020
participating in conferences,

37:36.120 --> 37:38.320
and giving presentations like the one I'm doing,

37:38.420 --> 37:40.680
to explain what I was doing and how it works.

37:40.780 --> 37:43.040
It has been extremely important, also,

37:43.140 --> 37:45.860
to be able to rely on the upstream infrastructure.

37:45.960 --> 37:47.540
So, to develop the software

37:47.640 --> 37:49.080
as a feature branch in the official git,

37:49.180 --> 37:49.960
but even more, I would say,

37:50.060 --> 37:51.660
to use the official bug tracker

37:51.760 --> 37:52.880
for solving bugs of this branch.

37:52.980 --> 37:54.680
This gave the opportunity

37:54.780 --> 37:58.160
to stay really in close touch with maintainers,

37:58.260 --> 37:59.920
and senior developers of Emacs.

38:00.020 --> 38:02.980
That helped me a lot. And at the same time

38:03.080 --> 38:04.820
they were informed about what I was doing

38:04.920 --> 38:07.360
and what was the status of this feature branch.

38:07.460 --> 38:08.800
Extremely important.

38:08.900 --> 38:11.160
And also I think it played a major role

38:11.260 --> 38:14.120
to try to design this enormous patch

38:14.220 --> 38:18.120
in a way that the impact on the current codebase

38:18.220 --> 38:21.120
was minimized (at least as much as possible).

38:21.220 --> 38:23.660
And also minimizing

38:23.760 --> 38:26.240
the impact on the user operation of the software,

38:26.340 --> 38:28.040
in this case Emacs.

38:28.140 --> 38:29.640
So yes, mandatory Special Thanks:

38:29.740 --> 38:33.360
Emacs developers, and especially maintainers

38:33.460 --> 38:36.680
and senior developers like Stefan Monnier,

38:36.780 --> 38:40.440
that helped me a lot across this long journey.

38:40.540 --> 38:42.800
And, well, all the community

38:42.900 --> 38:45.160
that really got so excited about this project

38:45.260 --> 38:46.240
and gave me the energy

38:46.340 --> 38:49.120
to go through all of this time and development

38:49.220 --> 38:51.980
and bugs and solving, etc. etc.

38:52.080 --> 38:54.920
So yes, it was a really exciting time,

38:55.020 --> 38:58.000
and I think we have to look forward

38:58.100 --> 39:01.400
and start thinking about how to improve all this

39:01.500 --> 39:02.920
for the following years.

39:03.020 --> 39:04.300
And that's it.

39:04.400 --> 39:06.040
I think I should be online for questions.

39:06.140 --> 39:07.480
Thank you very much.

39:07.580 --> 39:07.680
[captions by John Cummings]