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
-----------------------------------------------------------------
