[luatex] slower texlua at LuaTeX 1.0.4 (TL 2017) ?

Hans Hagen pragma at wxs.nl
Wed Jun 7 09:58:51 CEST 2017


On 6/7/2017 8:46 AM, jfbu wrote:
> 
>> In other words, the issue is a non-issue not worth the time several
>> respected LuaTex experts are putting into it.
> 
> Hi list,
> 
> should I conclude that the LuaTeX experts are not the least
> bit interested into understanding which compilation flags
> were modified and resulted in a texlua twice slower
> on macOS 10.9.5 with TeXLive 2017 release than it was
> with TeXLive 2016 for the same machine?

indeed, as these experts are not going to check compilation other than 
on their own machines ... compilation elsewhere is 'derived work'

(and fwiw, we'd observed 50% slower linux 32 bit versions versions a 
month ago at BT and were only mildly puzzled .. and those were all 
experts running 64 bit, so there was no reasson for panick)

> should I conclude it is _my fault_ to have reported this
> FACT at the initial message of this thread?
> 
> did I receive appropriate answers when Hans Hagen
> only reaction was to tell that my code (which
> I said explicitely was NOT MY CODE) was crap and
> could be sped up 99%, which was NOT my question?
> NOT MY CODE, NOT MY ALGORITHM, NOT MY BINARY.

i never said it was crap, i only said that (and i'm talking of years of 
using luatex) it often more pays of to optimize code (which in this case 
was possible, and normally is even fun to do) than to squeeze out some 
more from compilation (and even more if you're bound to a specific binary)

i don't see why yuou should get pissed about this ... i'm pretty sure 
that henry (whose code it was and who knows tex/lua very well) is 
interested in possible speed ups (if it were important at all)

in this case the 50% slow down was a compilation issue but normally 
we're talking of 5% fluctuations (in which case optimizing can pay of)

also, there have been answers about possible causes but as tex live 2017 
is frozen one has to live with what's there (or update in a few months 
when updates become available)

in fact, what bothers me more is that one lets people look into this 
(and therefore waste their time) while in fact the choice is then 
something python and tex (if i understood well) and lua was just a side 
track

(it's like users asking for a feature and then not testing it due to 
lack of time or whatever)

> It was the first ever time I ever ran texlua. Next time
> you run some software on your machine and find that
> between version 2016 and version 2017 its execution
> speed has increased 100% maybe you will consider that
> the experts of this software "put some time into understanding
> the cause",
it is no secret that there are speed differences between compilations, 
and if you mean with 'experts' those who develop luatex, indeed we're 
not that much interested because we compile for windows and linux and if 
that's okay, it's out of our hands and up to those who compile 
themselves and / or distributors and you cannot expect us to spent time 
on that

(for us the benchmark compilations are those on the context garden 
compile farm and you can bet that when there is a slow binary there 
we'll hear about it)

(btw, in the early days, cpu cache was a bottleneck)

(i've reported several times about speed related issues and luatex in 
the last decade but probably not in places and journals that you read)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------


More information about the luatex mailing list