令人惊讶的是,我没有找到太多关于这个话题的信息,除了选择硬件以获得最佳 LaTeX 编译性能的技巧其中指出,编译时间主要取决于 CPU 每个核心的时钟速度。
但是,如果我有很多图形(假设是 TikZ 和 PDF 图形)和中等复杂的文本怎么办?我可以使用专用图形芯片来缩短编译时间吗?
一般来说,在编译 LaTeX 项目时有没有办法利用 GPU?
答案1
这个问题可以从两个方面去理解:
- 您想使用 CPU 和 GPU 编译您的 LaTeX 文档:这实际上与您想使用另一个核心(即多核设置)来编译文档是同一个问题,这是不可能的。
- 您想专门使用 GPU:我怀疑这是否会非常有效,因为 GPU 通常有一些优化的操作,主要是关于图形的,但对于“普通”任务来说速度并没有那么快(对于某些操作甚至可能更慢)。除此之外,使用 GPU 代替 CPU 将是一项非常困难的任务,因为您需要事先将 TeX 的 CPU 指令转换为 GPU 指令,并让您的操作系统(可能还有图形驱动程序)允许这些操作。
根据你的情况你可以做什么:
- 如果您有许多 TikZ 图形,则可以使用外部化,这会使编译速度更快(第一次除外)。仅包含 PDF 就非常快。
- 您还可以创建一种以某种方式“预编译”前言的格式,从而加快速度(创建格式时除外,感谢 Skillmon 指出这一点)。
答案2
tikzexternalize 并行
我认为我最好稍微扩展一下关于外部化tikzpicture
s 的并行化的答案。我建议阅读 pgfman 的部分以了解更多详细信息(第 607 页及以后)。
免责声明:我是 Linux 用户;还没有在其他平台上尝试过。但是这个问题显然,这表明这是可以做到的。
无论如何:让我们制作一个非常简单的示例文档,tikzpicture
其中包含相当多的 s。请注意mode=list and make
对 的调用中的tikzexternalize
。这是重要的一点。
\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize[prefix=tikz-,mode=list and make]
\begin{document}
\begin{tikzpicture}
\draw (0,0) -- (1,1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (1,0) -- (1,1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (0,2) -- (1,1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (0,3) -- (1,1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (0,0) -- (2,1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (0,0) -- (5,1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (0,0) -- (2,-1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (0,0) -- (1,6);
\end{tikzpicture}
\begin{tikzpicture}
\draw (0,1) -- (7,1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (0,-1) -- (5,1);
\end{tikzpicture}
\begin{tikzpicture}
\draw (-1,0) -- (1,0);
\end{tikzpicture}
\end{document}
跑步
pdflatex myfile
或您喜欢的引擎。
然后你的目录中就会有一个新文件myfile.makefile
。使用以下命令执行该文件
make -j<PARALLEL_JOB_COUNT> -f myfile.makefile
这将以tikzpicture
并行批次的形式构建您的 s<PARALLEL_JOB_COUNT>
对于四个,这将是
make -j4 -f myfile.makefile
使用核心数作为运行并行作业数量的指导。
如果一切顺利,您可以再次编译您的文档并包含所有tikzpicture
内容:
pdflatex myfile
一切都会好起来的。
正如我在 TeXnician 的回答的评论中提到的那样,我能够将我的论文(很多pgfplot
s)的编译时间从大约 90 分钟缩短到干净目录上的大约 13 分钟(实际上,算上生成 s 之前和之后的两次 90 秒运行,是 16 分钟tikzpicture
,但我认为,这仍然是相当可观的增益)。当然,这里内核越多越好;我那台机器上有 12 个内核。
除了编译时间之外,我发现工作流程中还有另一个非常有益的方面:您可以从命令行轻松强制重建单个 tikzpictures。如果您将各个s 放在单独的文件中,这意味着您基本上可以获得与stikzpicture
非常相似的工作流程。因此,例如,如果我们想在这种情况下进行构建,我们可以发出:standalone
tikzpicture
tikz-main-figure5.pdf
make -B -f main.makefile tikz-main-figure5.pdf
该-B
选项强制make
重建目标——通常在这些情况下需要,如果您更改了您的tikzpicture
,然后又编译了主文档,因为这样m5dsum
将不会更新,并且make
会认为什么都没有改变。当然,您也可以直接删除.pdf
文件并重新编译,而无需-B
,但这是我在深夜漫长的几个小时里摆弄我的图并试图让它们看起来正确时通常所做的。我有 Ti钾Z pdf 在一个窗口中打开,带有源代码的编辑器在另一个窗口中打开,并有一个重新编译的快捷方式,使用起来确实非常方便。
GPU 注意事项
撇开已经提到的编译 TeX 文档在许多方面都是高度序列化的工作,您可能需要编写自己的 TeX 实现以在 GPU 上运行,或者编写一个可以在 GPU 上运行 x86 TeX 的包装器。我认为这些都不是简单的过程,而且考虑到在许多情况下,好处可能最多只是微不足道的(或负面的),我怀疑这样做是否值得。
更新:基准和背景
由于 90 分钟的编译时间对我来说似乎很荒谬,对这里的大多数人来说也是如此,所以我再次挖掘了该项目并对其进行了一些调整。目前的数字如下:
- 从头开始构建所有
tikzpicture
s(其中大多数是pgfplot
s),依次:57 分钟 - 建设
tikzpicture
s 有 12 个工作岗位平行线:7 分 30 秒
整个过程包括
tikzpicture
61输出pdf 文件- 256,000 行 CSV 数据,其中 130,000 行是 3 列,其余大部分是 2 列
- 237 个命令,其中的数据通常通过命令
\addplot
读取\pgfplotstableread
目前,我认为有两个主要的优化领域。由于它们通常也有助于加快tikzpicture
s 的编译速度,因此我希望这仍然足够切题,值得一提:
- 减少数据点的数量,以及
- 删除任何
filter/.code
命令,将其工作转移到首先生成数据的工具。
所以:
- 是的,这里有优化的潜力。
- 我对此没有异议。我的观点是,并行编译
tikzpicture
s 可以显著减少总体编译时间,而且如果您不反对使用命令行,则相对容易实现。 - 此外,它并没有听起来那么糟糕,因为我很少需要
tikzpicture
从头编译所有 s —— 通常我只需更新一个内容,然后整个文档大约需要 40 秒即可编译完成(可以使用 进一步缩短时间\includeonly
,但我通常不费心)。或者,如果我正在处理特定的tikzpicture
,我只需要重建它,这也是完全可以接受的(请参阅上面的工作流程说明)。
如果有人想自己尝试一下(或者对我可能犯下的一些 LaTeX 异端行为感到震惊),可以找到该文档这里(完整 PDF 版本可在快照目录)。这是一个有点复杂的设置,因为我还使用了一个单独的build
目录,而让它正常工作tikzexternalize
本身就是一个故事。但如果有人想看看一个非小型项目的实际用例tikzexternalize
,这可能会引起人们的兴趣。