[OS X TeX] benchmark a pdflatexmk run on a Mac Studio?
Doug McKenna
doug at mathemaesthetics.com
Mon May 2 15:27:12 EDT 2022
Here are some data points from my world:
A CPU-intensive, enumeration program that I wrote finds all the Hamiltonian path solutions on an N x N grid-graph that comport with a given a set of constraints. The backtracking code is single-threaded, and there's no file I/O other than occasional progress messages to the terminal. On my circa 2015 MacBook Pro Intel, a run takes around 5 hours to find all 20 million solutions for N=11. On my new M1 MacBook Pro, the run takes a little more than half that time. So a big win, comporting with various benchmarks saying that M1s represented a 70% increase in speed.
I've got a 32-page math paper with 54 PDF illustrations. It typesets in TexShop 4.7 on my M1 MacBook Pro in about 1 second to an 8.3MB PDF file. On my circa-2015 Intel MacBook Pro, using TexShop 4.69, it takes I'm guessing like 1.3 seconds. This is based on hitting Cmd-T simultaneously on both laptops sitting next to each other and viewing with my own eyes which Console window finishes first. It's always the M1 Mac, and noticeably so, but certainly not 70% faster.
Because iOS apps can run natively on M1 Macs, I recompiled my 160-page iOS eBook/app for iPads so as to be available in the MacOS app store for M1 Macs. The eBook/app relies on my own homebrew TeX language interpreter in it (JSBox, written in C), also recompiled. Each time the eBook/app launches, it reads the TeX source and self-typesets 160 pages anew, keeping the layout results for every page in memory. Because of the eBook's subject matter and interactive design, using PDF isn't an option (all the 130+ illustrations are created at read-time in the app by C subroutines when a user reveals a page, not at typesetting time).
The point being that the typesetting job reserves a box for each illustration, but is otherwise pure TeX language and layout computation, without any PDF or DVI or other input/output processing issues for illustrations. No files are written during the job. No other TeX infrastructure tools like ghostscript are relied upon.
The internal interpreter records the run time of the typesetting job at each app launch. For 160 pages (the eBook's virtual pages are long, 8.5" by 18"), the speed of its self-typesetting on my M1 Mac is about 140 milliseconds, whereas the speed on the older Intel machine (same as above) I developed it on is around 400 milliseconds. One caveat, of course, is that on the Intel machine, the code is translated on the fly by either Rosetta or the iOS device simulators into ARM code (or it's otherwise emulated). But even with that inefficiency taken into account, I think the TeX interpretation and layout algorithms are significantly faster on the M1 silicon, perhaps getting back towards the 70% level.
Which says to me that whatever is keeping a large pdfLaTeX project from being accomplished much faster on an M1 Mac, it's somewhere other than in the TeX language engine. There could also be some kind of cache issues that have cropped up, I suppose.
Perhaps the Mac's Activity Monitor program (see Applications/Utilities/) could show what processes might be involved in a time-consuming pdfLaTeX job that takes minutes to accomplish.
Doug McKenna
Mathemaesthetics, Inc.
Author of interactive eBook "Hilbert Curves" for iPads and M1 Macs
More information about the MacOSX-TeX
mailing list