[luatex] how many bytes for fontdimens?

jfbu jfbu at free.fr
Tue Aug 3 09:45:45 CEST 2021


Hi,

> Le 3 août 2021 à 09:09, Hans Hagen <j.hagen at xs4all.nl> a écrit :
> 
> On 8/2/2021 9:37 PM, jfbu wrote:
>> forgot to mention that I am aware a \fontdimen is limited to 2**30 strictly anyhow
>> but my question is whether such « arrays » are stored 32bits or 64bits itemwise
> it happens to be an array of 32 bit integers (that grows on demand) but such implementaiton details are unspecified (could as well have been a sparse array in which case each entry that is actually set has more
> 
> also, the fact that it grow is a sort of side effect of the fact that tfm fonts can have 7 or more, but 7 are used, for text upto more for math fonts
> 
> so, i wouldn't rely on these properties too much

Thanks! 

Reason I asked is because I contributed an Eratosthenes Prime sieve to a github site comparing a whole bunch of langages and it is asked there to specify whether the « arrays » use 1bit, 8bits, 32bits, or 64bits (or « unknown ») per (potential) prime.

https://github.com/PlummersSoftwareLLC/Primes/blob/drag-race/CONTRIBUTING.md#flag-storage <https://github.com/PlummersSoftwareLLC/Primes/blob/drag-race/CONTRIBUTING.md#flag-storage>

I am using luatex for the benchmark because even setting pdftex’s font_mem_size at its maximum TeXLive setting, the memory is at risk of being exhausted on current personal computers  from the condition that the benchmark must iterate at least until a duration of 5 seconds and each iteration re-in allocates a \fontdimen « array » (in the case at hand about 500,000 entries are needed to sieve up to 1,000,000 and memory will get exhausted before the 300th pass)

Also it seems luatex runs comparatively faster once the sieving range is large enough (the instantiation step which requires extending dynamically does take some time).

I will thus modify the « bit count » tag of my « solution » from unknown to 32bits, thanks to your answer, knowing though that this remains officially unspecified. But the Dockerfile which I was asked to include, and which their benchmarking uses, pulls a texlive-minimal based image dating back to 2018.

Perhaps someone here will be interested into contributing a genuine luatex (i.e. using Lua) solution (my code uses only Knuth TeX; there is also a LaTeX3 code also on the github site).

There is already at least one Lua contribution. I don’t know if a genuine luatex would have to be categorized under « PrimeTeX » or « PrimeLua » ...

... in particular a LuaTeX genuine solution may have a way to use an « array » not based on font dimension parameters.

One particular point I don’t know is whether LuaTeX would allow a « faithful » solution: this seems to mean roughly a class-encapsulated one (it is hard to understand what they precisely mean in their guidelines), which I could not really emulate in my code due to global nature of fontdimen assignments.

(I also experimented with  a csname based approach but never could reach comparable speed to fontdimen arrays ; and this required extending other parts of the memory)

Here is a link to how the various implementations sort out currently on one specific machine:

https://plummerssoftwarellc.github.io/PrimeView/?sc=dt&sd=True&rc=30 <https://plummerssoftwarellc.github.io/PrimeView/?sc=dt&sd=True&rc=30>


Thanks,

Jean-François

> 
> Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/luatex/attachments/20210803/ba366631/attachment.html>


More information about the luatex mailing list.