<div dir="ltr"><div>Hi</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Luís Sequeira wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
pdflatex is a single threaded program and I believe that other tex engines, xelatex and lualatex, are too.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The processing of a latex file is pretty much sequential anyway, so it is hard to see how multithreading might help in this case. If someone has a different understanding of this, I would like to learn about it.<br></blockquote><div><br></div><div>I'll look at the question both narrowly, as clearly stated by Luís, and broadly in terms of LaTeX responding more quickly to typesetting requests.</div><div><br></div><div>Don Knuth's TeX introduced dvi (DeVice Independent) files as an intermediate between typesetting and rendering. (Take this as a definition of typesetting and rendering.) I've read that XeTeX retains this distinction. This division between the two allows the typesetting to be piped to the rendering, which allows two cores to be used.</div><div><a href="https://en.wikipedia.org/wiki/XeTeX#Mode_of_operation" target="_blank">https://en.wikipedia.org/wiki/XeTeX#Mode_of_operation</a><br></div><div><br></div><div>LaTeX requires multiple runs to resolve generated text such as equation and page numbers, and also the index. These intermediate runs are usually performed by a script, and no human being looks at the intermediate PDF files generated by pdflatex.</div><div><br></div><div>If rendering is separate from typesetting then it can be omitted from the intermediate runs. This will speed matters up, particularly if the document being typeset has much graphics. Even without separation a speedup is achieved if graphics are rendered as grey boxes on all but the script's final run of pdflatex.</div><div><br></div><div>If typesetting can be done chapter by chapter, a separate core can be used to process each chapter. This is fairly straightforward for the typesetting. For rendering to PDF multiple cores can still be used, followed by a tool that will concatenate the resulting PDF files.</div><div><br></div><div>Most of the above is I believe possible with pdflatex as it is, or with only minor changes. More extensive changes will allow authors to be provided with an even more rapid edit-typeset-preview loop.</div><div><br></div><div>Worth looking at here is David Platt's statement: You [developers] think your users want to use your software. They do not want to use your software. They want to have used your software.</div><div><br></div><div><a href="https://www.youtube.com/watch?v=JAOTTLQ0rlY">https://www.youtube.com/watch?v=JAOTTLQ0rlY</a><br></div><div><a href="https://www.joyofux.com/">https://www.joyofux.com/</a><br></div><div><br></div><div>wishing you rapid texing</div><div><br></div><div>Jonathan</div><div><br></div><div> </div><div><br></div><div> </div><div><br></div><div> </div></div></div>