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
testromannumeral.tex
Description: Binary data
