1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
% language=us
% After watching \quotation {What Makes This Song Great 30: Alanis Morisette} by
% Rick Beato, it's tempting to poder \quotation {What makes \TEX\ great}.
\startcomponent onandon-110
\environment onandon-environment
\startchapter[title={Getting there, version 1.10}]
When we decided to turn experiments with a \LUA\ extensions to \PDFTEX\ into
developing \LUATEX\ as alternative engine we had, in addition to opening up some
of \TEX's internals, some extensions in mind. Around version 1.00 most was
already achieved and with version 1.10 we're pretty close to where we want to be.
The question is, when are we ready? In order to answer that I will look at four
aspects:
\startitemize[packed]
\startitem objectives \stopitem
\startitem functionality \stopitem
\startitem performance \stopitem
\startitem stability \stopitem
\stopitemize
The main {\em objective} was to open up \TEX\ in a way that permit extensions
without the need to patch the engine. Although it might suit us, we don't want to
change too much the internals, first of all because \TEX\ is \TEX, the documented
program with a large legacy. \footnote {This is reflected in the keywords that
exposed mechanisms use: they reflect internal variable names and constants and as
a consequence there is inconsistency there.} Discussions about how to extend
\TEX\ are not easy and seldom lead to an agreement so better is to provide a way
to do what you like without bothering other users and|/|or interfering with macro
packages. I think that this objective is met quite well now. Other objectives,
like embedding basic graphic capabilities using \METAPOST\ have already been met
long ago. There is more control over the backend and modern fonts can be dealt
with.
The {\em functionality} in terms of primitives has been extended but within
reasonable bounds: we only added things that make coding a bit more natural but
we realize that this is very subjective. So, here again we can say that we met
our goals. A lot can be achieved via \LUA\ code and users and developers need to
get accustomed to that if they want to move on with \LUATEX. We will not
introduce features that get added to or are part of other engines.
We wanted to keeping {\em performance} acceptable. The core \TEX\ engine is
already pretty fast and it's often the implementation of macros (in macro
packages) that creates a performance hit. Going \UTF\ has a price as do modern
fonts. At the time of this writing processing the 270 page \LUATEX\ manual takes
about 12 seconds (one run), which boils down to over 27 pages per second.
\starttabulate[||c|c|]
\NC \BC runtime \BC overhead \NC \NR
\BC \LUATEX \NC $12.0$ \NC $+0.6$ \NC \NR
\BC \LUAJITTEX \NC $ 9.7$ \NC $+0.5$ \NC \NR
\stoptabulate
Is this fast or slow? One can do tests with specific improvements (using new
primitives) but in practice it's very hard to improve performance significantly.
This is because a test with millions of calls that show a .05 second improvement
disappears when one only has a few thousand calls. Many small improvements can
add up, but less that one thinks, especially when macros are already quite
optimal. Also this runtime includes time normally used for running additional
programs (e.g.\ for getting bibliographies right).
It must be said that performance is not completely under our control. For
instance, we have patched the \LUAJIT\ hash function because it favours \URL's
and therefore favours hashing the middle of the string which is bad for our use
as we are more interested in the (often unique) start of strings. We also
compress the format which speeds up loading but not on the native windows 64~bit
binary. At the time this writing the extra overhead is 2~seconds due to some
suboptimal gzip handling; the cross compiled 64~bit mingw binaries that I use
don't suffer from this. When I was testing the 32~bit binaries on the machine of
a colleague, I was surprised to measure the following differences on a complex
document with hundreds of \XML\ files, many images and a lot of manipulations.
\starttabulate[||c|c|]
\NC \BC 1.08 with \LUA\ 5.2 \BC 1.09 with \LUA\ 5.3 \NC \NR
\BC \LUATEX \NC $21.5$ \NC $15.2$ \NC \NR
\BC \LUAJITTEX \NC $10.7$ \NC $10.3$ \NC \NR
\stoptabulate
Now, these are just rough numbers but they demonstrate that the gap between
\LUATEX\ and \LUAJITTEX\ is becoming less which is good because at this moment it
looks like \LUAJIT\ will not catch up with \LUA\ 5.3 so at some point we might
drop it. It will be interesting to see what \LUA\ 5.4 will bring as it offers an
\ alternative garbage collector. And imagine that the regular \LUA\ virtual
machine gets more optimized.
You also have to take into account that having a browser open in the background
of a \TEX\ run has way more impact than a few tenths of a second in \LUATEX\
performance. The same is true for memory usage: why bother about \LUATEX\ taking
tens of megabytes for fonts while a few tabs in a browser can bump memory
consumption to gigabytes of memory usage. Also, using a large \TEX\ tree (say the
whole of \TEXLIVE) can have a bit of a performance hit! Or what about inefficient
callbacks, using inefficient \LUA\ code of badly designed solutions? What we
could gain here we loose there, so I think we can safely say that the current
implementation of \LUATEX\ is as good as you can (and will) get. Why should we
introduce obscure optimizations where on workstations \TEX\ is just one of the
many processes? Why should we bother too much to speed up on servers that have
start|-|up or job management overhead or are connected to relatively slow remote
file system? Why squeeze out a few more milliseconds when badly written macros or
styles can have an way more impact on performance? So, for now we're satisfied
with performance. Just for the record, the ratio between \CONTEXT\ \MKII\
running other engines and \LUATEX\ with \MKIV\ for the next snippet of code:
\starttyping
\dorecurse{250}{\input tufte\par}
\stoptyping
is 2.8 seconds for \XETEX, 1.5 seconds for \LUATEX, 1.2 seconds for \LUAJITTEX,
and 0.9 seconds for \PDFTEX. Of course this is not really a practical test but it
demonstrates the baseline performance on just text. The 64 bit version of \PDFTEX\
is actually quite a bit slower on my machine. Anyway, \LUATEX\ (1.09) with \MKIV\
is doing okey here.
That brings us to {\em stability}. In order to achieve that we will not introduce
many more extensions. That way users get accustomed to what is there (read: there
is no need to search for what else is possible). Also, it makes that existing
functionality can become bug free because no new features can interfere. So, at
some point we have to decide that this is it. If we can do what we want now,
there are no strong arguments for more. in that perspective version 1.10 can be
considered very close to what we want to achieve.
Of course development will continue. For instance, the \PDF\ inclusion code will
be replaced by more lightweight and independent code. Names of functions and
symbolic constants might be normalized (as mentioned, currently they are often
related to or derived from internals). More documentation will be added. We will
quite probably keep up with \LUA\ versions. Also the \FFI\ interface will become
more stable. And for sure bugs will be fixed. We might add a few more options to
control behaviour of for instance of math rendering. Some tricky internals (like
alignments) might get better attribute support if possible. But currently we
think that most fundamental issues have been dealt with.
\stopchapter
\stopcomponent
|
