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

[Meer, Hans van der]

I feel obliged to make a few remarks concerning the direction this discussion has taken.

My first point is the acrid tone I think I hear in the reaction "Hi list, should I conclude...etc". Please refrain. Although the developers of texlua may make mistakes (they are human after all, isn't it?) I am convinced of their devotion to the project and have experienced that more than once. They deserve our support, respect and gratitude. So please, let us not converse in a tone that in my opinion sounds unnecessary offending.

That said, in asserting the cause of a perceived slowdown in the processing of ones input, much care has to be taken in pointing at the culprit. I can speak from a certain experience, having made programs from 1965 onwards on several machines/operating systems and in several programming languages. Many things count here: compilation settings yes, but also changes in the opersting system (updates are not always for the better), machine load, the specific input data, in the case of user originated luacode execution the algorithm chosen with respect to these data, the implementation of that code. 
Before pointing a finger I have learned to first do some (documented) experiments and present these to the developers. That will help them to pinpoint the problem that might be there. Doing so we will all benefit.

Please note that I make these remarks to have all of us in the (Con)Text/Lua community happily working together.
Best wishes

Hans van der Meer




> On 7 Jun 2017, at 09:58, Hans Hagen <pragma at wxs.nl> wrote:
> 
> 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
> -----------------------------------------------------------------