<div dir="ltr">Hi all,<div><br></div><div>there is another problem with small benchmark, the memory cache. If the program is run for the first time, it has to be read from disk. If you run it again, it may be still present in cache, hence it starts faster. If you do not have SSD, then especially on the laptops the HD may be stopped in order to save energy and reading may be slow. It may also be a difference between a statically linked C program run immediately after compilation and linking, because it may still be in the cache, and running the same program the next day. </div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Zdeněk Wagner<br><a href="http://ttsm.icpf.cas.cz/team/wagner.shtml" target="_blank">http://ttsm.icpf.cas.cz/team/wagner.shtml</a><br><a href="http://icebearsoft.euweb.cz" target="_blank">http://icebearsoft.euweb.cz</a></div></div>
<br><div class="gmail_quote">2017-07-27 8:58 GMT+02:00 jfbu <span dir="ltr"><<a href="mailto:jfbu@free.fr" target="_blank">jfbu@free.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Reinhard<br>
<br>
Le 27 juil. 2017 at02:15, Reinhard Kotucha  :<br>
<span class=""><br>
> On 2017-07-26 at 22:00:30 +0200, jfbu wrote:<br>
><br>
>> 3. run in this work repertory the test file which I will indicate<br>
>> next via<br>
>><br>
>> "time etex testmachin.tex"<br>
>><br>
>> - with TL2017<br>
>><br>
>> - with TL2015<br>
><br>
> Dear Jean-Francois,<br>
> I get<br>
><br>
>  TL2017:  computed in 9.27 seconds.<br>
>  TL2015:  computed in 9.21 seconds.<br>
><br>
> No significant difference, but in both cases I get the error message<br>
><br>
>  ! Undefined control sequence.<br>
>  l.31 \ifx\x\Z \message{OK}\else \ERROR<br>
>                                        \fi<br>
><br>
> and thus the return value of "time" isn't usable.  What went wrong?<br>
<br>
<br>
</span>Thanks a lot for trying out, the most likely cause is that the<br>
<br>
def\x{3.141592653589793238462.<wbr>...<br>
<br>
line got hard-wrapped somehow so that it occupies multiple lines<br>
<br>
(it should be on only one line)<br>
<br>
and this means the \x has spaces in it and the \ifx test fails<br>
because the \Z computed by \fdef\Z {\Machin {1000}} contains<br>
the first 1000 digits of Pi with no spaces.<br>
<br>
I really should not have left that piece of code in there, my wrong.<br>
<br>
It makes sense as an error check, but as I validated it once at the<br>
time of 1.2k upload to CTAN a few months back,<br>
it was superfluous to keep it here<br>
<br>
(I try again here xint 1.2k. OK, no issue on my side)<br>
<span class=""><br>
<br>
><br>
> My system is an AMD 2.4 GHz CPU running Gentoo Linux and TeX binaries<br>
> are from <a href="http://tug.org" rel="noreferrer" target="_blank">tug.org</a>.<br>
><br>
> I must admit that benchmarks are confusing me ATM.  I've written a<br>
> tiny program in several programming languages which does nothing else<br>
> than to multiply numbers in nested for-loops.  On my old AMD machine,<br>
> luajit was as fast as C.  On my brand-new Intel i7-7700K luajit is<br>
> twice as fast as C.  Don't know why.  The CPU clock frequency is<br>
> obviously not all that counts.<br>
<br>
<br>
</span>I have no idea: perhaps the luajit was compiled with top-notch<br>
machines and software and performs at its best in such contexts?<br>
<br>
Best,<br>
<br>
Jean-Francois<br>
</blockquote></div><br></div>