followingup-feedback.tex /size: 9897 b    last modification: 2021-10-28 13:50
1% language=us runpath=texruns:manuals/followingup
2
3\startcomponent followingup-feedback
4
5\environment followingup-style
6
7\logo [AMD]   {AMD}
8\logo [INTEL] {Intel}
9
10\startchapter[title={Feedback}]
11
12\startsection[title={Introduction}]
13
14As \LUATEX\ 1.10 is basically frozen in terms of functionality not much can or
15will be added. But it made sense to some of the (small) improvements that were
16made in \LUAMETATEX\ got feedback to \LUATEX\ (or will be at some point). Because
17we are also experimenting, there can be a delay. \footnote {Later chapters
18mention a few more possible extensions.}
19
20Of course the question is \quotation {Should we feedback (retrofit) at all?}. I'm
21still not sure about it. There should be a good reason to do it because it can
22harm stability of the original. At some point \CONTEXT\ can default to the follow
23up in which case testing the original becomes more difficult for specific
24features. I never ran into (useful) demands for extensions so retrofit can have a
25low priority.
26
27Another factor is that when distributions start adding stuff to stock \LUATEX\ on
28top of what is our default (after all isn't that what happens with open source
29projects), it makes not much sense to look back and retrofit new functionality,
30because there is not much change that we will use such a variant ourselves and we
31could introduce errors in the process. Providing bloatware is not our objective.
32
33Related to this is the question if we should always go into \LMTX\ mode and I'm
34no longer sure if we shouldn't do that. We can use plain \TEX\ with the regular
35\LUATEX\ backend and just forget about some generic framework. The danger of it
36backfiring is just too large. It is a waste of time and will keep us back.
37
38One reason for a dual mode is that it made possible some timings in order to
39determine bottlenecks. I did some rough tests and that is enough to get the
40picture. Take this document:
41
42\starttyping
43\starttext
44    \dorecurse
45        {1000}
46        {\samplefile{sapolsky} {\bf\samplefile{sapolsky}}\par}
47\stoptext
48\stoptyping
49
50Using regular \LUATEX\ this takes on an \INTEL\ i7-3840 mobile processor about
519.3 seconds while \LUAMETATEX\ needs 11.2 seconds, so we loose time. This is
52because we have only text so the native backend wins on piping out the page
53stream. On my domotica fitlet with an low power \AMD\ A10 processor running
54\LINUX\ the runtime goes from 25.4 seconds to 27.8 seconds, so again a slow down.
55
56But this is not a typical document! Add a bit more spice and the numbers reverse.
57For processing the \LUATEX\ manual stock \LUATEX\ takes 12.6 seconds on the
58\INTEL\ and \LUAMETATEX\ needs 12.4 seconds. On the \AMD\ runtime goes from 35.1
59seconds down to 32.8 seconds. So here we win some.
60
61These are rough timings and a few weeks later we go these timings on the \INTEL:
62\footnote {On the more modern gaming laptop of a nephew we measured half these
63numbers.}
64
65\starttabulate[|l|c|c|c|]
66\BC engine            \BC backend \BC runtime \BC \LUAJIT\ vm \BC \NR
67\HL
68\NC \LUATEX\     1.10 \NC normal  \NC 12.4    \NC 9.9 \NC \NR
69\NC \LUATEX\     1.10 \NC lmtx    \NC 12.7    \NC 9.8 \NC \NR
70\NC \LUAMETATEX\ 2.00 \NC lmtx    \NC 12.2    \NC 9.3 \NC \NR
71\stoptabulate
72
73Because we have more \LUA\ code active, we pay a price with \LMTX\ but not on
74\LUAMETATEX\ (as of now, later we will see a performance bump). The gain when
75using the \LUAJIT\ virtual machine is more noticeable. And, there is probably
76some more to gain. In case you wonder why this matters: think of the low power
77\AMD\ processor. When we have to replace computers we can consider using low
78power ones, with weaker processors, less memory, and less cache. For the record:
79I use cross compiled \MINGW\ binaries on windows (they are quite a bit faster
80than native windows binaries). And the binaries are less than 3MB (small files
81and less resources are nice when running on remote file systems).
82
83This all indicates that we have no real reason to stick to a mixed approach: if we
84want we can just switch to always \LMTX\ and never look back.
85
86\stopsection
87
88\startsection[title={Expressions}]
89
90When writing an article that involved using a \type {\numexpr} it struck me that
91we should have a proper integer division. Just compare these:
92
93\startbuffer[1]
94\the\numexpr 13/2\relax
95\stopbuffer
96
97\startbuffer[2]
98\scratchcounter13 \divide\scratchcounter 2 \the\scratchcounter
99\stopbuffer
100
101\typebuffer[1]
102
103and
104
105\typebuffer[2]
106
107This gives {\bf \inlinebuffer[1]} and {\bf \inlinebuffer[2]}. We now also have:
108
109\startbuffer[3]
110\the\numexpr 13:2\relax
111\stopbuffer
112
113\typebuffer[3]
114
115which gives {\bf \inlinebuffer[3]}. I considered using a double slash (as in
116\LUA) but using a colon is easier. Of course those who make that an active
117character are probably toast. This is an easy patch but it's hard to predict
118possible side effects outside \CONTEXT.
119
120\stopsection
121
122\startsection[title={Looking ahead}]
123
124Sometimes you want to look ahead and act upon the presence of a specific
125character. Implementing that in pure \TEX\ primitives is no big deal, but
126especially when you want to ignore leading spaces it leads to rather verbose code
127when tracing is enabled. Out of curiosity I played with a primitive that can help
128us out. Although there is also a performance gain, in practice one will not
129notice that unless such a feature is used millions of times, but in that case the
130gain is noise compared to the rest of the run.
131
132\startbuffer
133\def\foo{\futureexpand/\fooyes\foonop}
134\def\fooyes/#1/#2{[#1:#2]}
135\def\foonop    #1{(#1)}
136
137\foo/yes/{one}\quad
138\foo     {two}
139\stopbuffer
140
141\typebuffer
142
143We either expand \type {\fooyes} or \type {\foonop}, depending on the presence
144of a \type {/} after \type {\foo}. So, the result is:
145
146{\tttf\getbuffer}
147
148The next examples demonstrates two variants. The second one doesn't inject spaces
149back into the stream.
150
151\startbuffer
152\def\f<{\futureexpand/\y\n}
153\def\y/#1/{#1}
154\def\n    {}
155
156(\f</yes/>)\quad
157(\f<     >)
158\stopbuffer
159
160\typebuffer
161
162Watch the space in the \type {\n} case.
163
164{\tttf\getbuffer}
165
166\startbuffer
167\def\f<{\futureexpandis/\y\n}
168\def\y/#1/{#1}
169\def\n    {}
170
171(\f</yes/>)\quad
172(\f<     >)
173\stopbuffer
174
175\typebuffer
176
177This time the space is not injected (\type{is} is short for ignore spaces).
178
179{\tttf\getbuffer}
180
181I will probably use this one in \CONTEXT, but as said, not for performance
182reasons but because it reduces code and therefore tracing. \footnote {In the
183\CONTEXT\ code base there are several places where less code takes precedence
184over efficiency. But in all cases extensive tests were done to see if it made a
185dent in practical performance.}
186
187\stopsection
188
189\startsection[title={Checking numbers an dimensions}]
190
191The \CONTEXT\ user interface often uses parameters that take keywords as well as
192a number or dimension. In practice it has never been an issue to check for that but
193there are a few cases where we'd like to be a bit more flexible.
194
195\startbuffer
196\doifelsenumber{123999999999999999}YN
197\doifelsenumber               {123}YN
198\doifelsenumber                 {A}YN
199\doifelsenumber          {\char123}YN
200\doifelsenumber          {\toks123}YN
201\doifelsenumber{123\scratchcounter}YN
202
203\doifelsedimension{123999999999999999pt}YN
204\doifelsedimension               {123pt}YN
205\doifelsedimension                   {A}YN
206\doifelsedimension            {\char123}YN
207\doifelsedimension            {\toks123}YN
208\doifelsedimension    {123\scratchdimen}YN
209\stopbuffer
210
211\typebuffer
212
213This typesets:
214
215\startpacked
216\getbuffer
217\stoppacked
218
219especially the \type {123\scratch...} checking is tricky. For that reason we now
220have two new built|-|in checkers. Again, performance is not one of the arguments,
221because these checks are not much faster than what we have already, they are just
222a bit more robust for weird cases. A possible use of the primitives is:
223
224\starttyping
225\ifdimen123\or
226  yes
227\else % or \or
228  no
229\fi
230\stoptyping
231
232and:
233
234\starttyping
235\ifnumber123\or
236  yes
237\else % or \or
238  no
239\fi
240\stoptyping
241
242When a valid number or dimension is gobbled, the value pushed in the branches
243is~1, and when an error is encountered the value~2 is pushed. Deep down we have
244just an \type {\ifcase} and by not using the value zero we nicely skip the
245invalid code. It might look a bit weird but we need a sentinel for the number
246(and the \type {\or} serves as such, without introducing strange new constructs.
247We'll see if we keep it (as testing must prove its usefulness).
248
249\stopsection
250
251\stopsection
252
253\startsection[title={Comparing tokens}]
254
255The following code compares (for instance) two strings:
256
257\starttyping
258\def\thisorthat#1#2%
259  {\edef\one{#1}
260   \edef\two{#2}
261   \ifx\one\two
262     this%
263   \else
264     that%
265   \fi}
266
267\thisorthat{foo}{bar}
268\stoptyping
269
270but this looks a bit cleaner (in a trace):
271
272\starttyping
273\def\thisorthat#1#2%
274  {\iftok{#1}{#2}%
275     this%
276   \else
277     that%
278   \fi}
279
280\thisorthat{foo}{bar}
281\stoptyping
282
283It's not that much faster (unless one uses it a real lot) as similar things have
284to happen to get the test to work. But the nice things of this checker is that it
285works with token registers and macros too. But in order use it in relevant places
286in \CONTEXT\ I would have to adapt quite some code. This could actually be a
287reason for a \MKIV\ freeze and \LMTX\ code base (as with \MKII). The question is:
288does it pay off?
289
290\stopsection
291
292\stopchapter
293
294\stopcomponent
295
296% \newbox\mybox \setbox\mybox\ruledhbox{\blackrule[width=3cm,height=1cm]}
297
298% \dontleavehmode\copy\mybox\quad \ruledhbox{\copy\mybox} \blank[3*line]
299% \boxxmove\mybox            10pt
300% \dontleavehmode\copy\mybox\quad \ruledhbox{\copy\mybox} \blank[3*line]
301% \wd\mybox\dimexpr\wd\mybox+10pt\relax
302% \dontleavehmode\copy\mybox\quad \ruledhbox{\copy\mybox} \blank[3*line]
303% \boxymove\mybox            10pt
304% \dontleavehmode\copy\mybox\quad \ruledhbox{\copy\mybox} \blank[3*line]
305% \ht\mybox\dimexpr\ht\mybox+10pt\relax
306% \dontleavehmode\copy\mybox\quad \ruledhbox{\copy\mybox} \blank[3*line]
307