Call for testing: builds of Tectonic for Apple Silicon

[pkgw]

Hi all,

As per this comment, in #959 I've prototyped a CI build of Tectonic for Apple on ARM64 chips. A package of the binary is here:

https://newton.cx/~peter/files/tectonic-0.11.0+20221025-aarch64-apple-darwin.tar.gz

Would anyone be able to give it a test and report whether it seems to work? Thanks!

edit: oops, I labeled this "Apple Metal" first. I mean Apple Silicon!

[LiHRaM]

Can confirm that rebuilding my master's thesis worked just fine with that binary!

Please let me know if there's any specific sets of files you want me to test it on.

Tested on a MacBook Pro with Apple M1 Pro processor (MacBookPro18,1).

[pkgw]

Thanks! If it runs at all, that's the main thing.

[Neved4]

@pkgw Working without issues so far, everything looks good to me 🚀

I've ran some benchmarks too, with xenia/paper.tex:

$ time ./tectonic-0.12.0-x86_64 paper.tex
real	0m2.536s
user	0m2.358s
sys	0m0.162s

$ time ./tectonic-0.12.0-aarch64 paper.tex
real	0m1.975s
user	0m1.824s
sys	0m0.145s

≈ 0.5 seconds, great perf improvement!

Normalized values with hyperfine:

$ hyperfine -w 8 -r 64 './tectonic-0.12.0-aarch64 paper.tex' './tectonic-0.12.0-x86_64 paper.tex'

Benchmark 1: ./tectonic-0.12.0-aarch64 paper.tex
  Time (mean ± σ):      1.970 s ±  0.030 s    [User: 1.826 s, System: 0.136 s]
  Range (min … max):    1.936 s …  2.104 s    64 runs
 
Benchmark 2: ./tectonic-0.12.0-x86_64 paper.tex
  Time (mean ± σ):      2.545 s ±  0.066 s    [User: 2.385 s, System: 0.140 s]
  Range (min … max):    2.462 s …  2.835 s    64 runs
 
Summary
  './tectonic-0.12.0-aarch64 paper.tex' ran
    1.29 ± 0.04 times faster than './tectonic-0.12.0-x86_64 paper.tex'

* Note: the marketing term would be Apple Silicon; Metal typically refers to Apple's graphics API, à la OpenGL.

[pkgw]

Oh, argh! Thank you for the correction about Silicon vs. Metal. Hopefully I'll get that right going forward.

[Neved4]

More benchmarks compiling biblatex documentation, ≈350 pages.
Removing Libertine, Biolinum and Shobhika fonts is needed to get it to work under XeTeX-based engines.

XeLaTeX:

$ time latexmk -pdfxe -bibtex biblatex.tex 
real	0m22.137s
user	0m21.508s
sys	0m0.558s

LuaHBTeX:

$ time latexmk -pdflua -bibtex biblatex.tex 
real	0m54.335s
user	0m53.093s
sys	0m1.090s

Tectonic (aarch64): 🚀

$ time ./tectonic-0.12.0-aarch64 biblatex.tex
real	0m18.617s
user	0m18.265s
sys	0m0.278s

Tectonic (x86_64, Rosetta 2):

$ time ./tectonic-0.12.0-x86_64 biblatex.tex
real	0m22.370s
user	0m22.013s
sys	0m0.295s

---

Software:

• tectonic 0.12.0
• TeX Live 2022
• LuaHBTeX 1.15.0
• XeTeX 3.141592653-2.6-0.999994

Hardware:

• MacBookPro 17,1 (M1)

[Neved4]

@pkgw Do you think it's a good idea to have a centralized place to monitor, collect stats and keep tabs on tectonic performance?

[pkgw]

I think it would definitely be nice to have! To be honest, performance is not a high priority for me personally right now, but there are always people interested in that aspect of things. So, I'm not familiar with what kinds of tools/infrastructure are out there, but I bet there are options. We could definitely create a repo or section of the website to act as a hub.

[Neved4]

Perf is not a priority for me either, but since the previous binary was running under M-family cpus using an emulation layer, I wanted to know if there was any noticeable difference, considering the other engines were already shipping ARM-native code.

Having a hub sounds fantastic! 🚀
It could be something that pulls issues based on a performance label.
A hub that gives a good overview of the performance changes between releases, architectures, native binaries etc. is much better than having separate isolated issues and also organises the information of performance issues in the future —there will be—

Regarding tools, I really like hyperfine for compilation, because it lets you perform multiple runs, gives you mean values, allows you to do warmup runs and reduce variances... etc. For other aspects, strace/dtruss (to examine syscalls) and flamegraph/inferno (to check where cpu time is spent) seem useful too. Something that integrates in a CI would be great to automate the process, but I'm not familiar enough on this.

The criterion create is also interesting.