[luatex] how many bytes for fontdimens?

[jfbu]

Hi Reinhard,

I belatedly (as I don’t subscribe yet) see your informative post on the luatex mailing list,

I did not know about tinytex and will look into it thanks for the pointer!

About

> Hello Jean-François,
> as Hans already pointed out, the size of the texmf tree matters.  IMO
> it's not a good idea to change TeX Live's configuration.  You can't
> achieve a significant improvement this way.  And please avoid
> TeX-related environment variables whenever possible.


it was needed to set TEXMFCNF
in my original testing in order to enlarge texlive’s font_mem_size
parameter for pdftex usage, as

- the -cnf-line option (recognized by TL2021 pdftex binary) is not recognized
  by the pdftex from (the Docker image based on) TL2018 minimal scheme

  (i.e. I can’t do this

  pdftex -cnf-line "font_mem_size=147483647" erato_benchmark

  which TeXLive 2018)

and

- with the help of a texmf.cnf
  file in the working repertory dictating the font_mem_size setting,
  exporting to the environment TEXMFCNF="(pwd):" lets pdftex use
  the maximally (147483647 words) enlarged font memory


I usually did this encapsulated in a script, but sometimes did

export TEXMFCNF="(pwd):"

on the command line and forgot to reset the environment afterwards.
(by the way, context users will be quickly reminded of this oversight from the
mtxrun          | unknown script 'context.lua' or 'mtx-context.lua’
error message when TEXMFCNF is set as above)

This led me to realize (??) that there was (or not), sometimes, 
some effect
on a seemingly quite unrelated matter on whether to use or not
a (serving to nothing) \romannumeral inside a \Replicate

[digression: this \Replicate comes from my xintkernel.sty where the \romannumeral was
justified by other things, among them presence of an added layer using
\numexpr which I removed because I wanted the prime sieve
to use only Knuth tex; I could have used \csname not \romannumeral
actually even with this \numexpr. I had modeled some years back 
the xintkernel.sty Replicate on latex3 code with
some changes including not raising an error if used with
negative argument]

But this whole thing is disconcerting: evidence and truth are
utterly evident… …but do change radically at unexpected
times it appears.

I have made enough noise, now attaching my benchmark file which
has some desperate comments in case some foolish person is interested
into running luatex with it

I am going to have very limited internet access for most of August,
starting tomorrow,
 <strike>so posting this off-list as anyhow I can’t follow</strike>
posting on-list after all

PS, some additional and final off-topic noise:

since my initial post to the luatex list I have updated
my sieve code at 

https://github.com/PlummersSoftwareLLC/Primes/tree/drag-race/PrimeTeX/solution_2

The main change was to replace =1sp<space> assignments into =\onesp
with \onesp a \dimen with value 1sp, I knew naturally this would bring some gain,
but it is spectacular for the base sieve 
with pdftex it was almost 3X speed gain from this change only! (on the sieving part isolated).

A further change on advice from Hans, was to use \ifcase in place of \ifdim\foo=\z@,
which proves definitely beneficial too (but for some much smaller gain)

Another change bringing a small improvement
was to use systematically = in \count and \dimen assignments

(in the wheel algorithm there is still an inefficiency about using one \count
assignment too many in the loop, but I am leaving it as it as the maintainers
of the above site are a bit overworked from successive PRs)

Cheers,

Jean-François

-------------- next part --------------
A non-text attachment was scrubbed...
Name: testromannumeral.tex
Type: application/octet-stream
Size: 7010 bytes
Desc: not available
URL: <https://tug.org/pipermail/luatex/attachments/20210808/98f9d713/attachment.obj>
-------------- next part --------------