让我从集群用户和集群管理员的 POV 中提供一个迟来的答案。

一般来说，一个设计良好的集群会尽可能地同质化，登录节点通常会更强大一些，因为它是用户与集群的单点联系。一个维护良好的集群也将有一个很好的系统文档，对于想要真正弄脏自己的手的用户。

随着时间的推移，我掌握了一些开发和使用并行软件的经验法则，我将在此分享：

1. 如果目标只是一个正在运行的程序，请尝试在登录节点上编译它。如果可能（并且如果您使用 Make），请使用并行编译。
2. 同1，但编译进展缓慢。对其他用户的影响可能不可忽略，尤其是在您使用并行 make ( make -j <n>) 时。在这种情况下，您应该尝试（大量）估计编译代码并将作业提交到队列所需的时间。
3. 如果目标是优化代码但不依赖于架构优化，那么您应该以独占模式提交编译作业，即请求整个节点进行编译。这样其他用户就不会干扰优化过程。我将以这种方式编译的代码示例是 NumPy，它的分析器引导优化和链接时优化。-O3前两个版本也可以使用简单的优化。

4. 如果目标是优化代码并使用架构优化（AVX、SSE 等），那么在节点上编译会更安全，因为这是作业将运行的地方。警告：如果您运行的集群包含多个 CPU 架构（例如 Intel Broadwell、Skylake），例如比较http://www.bwhpc-c5.de/wiki/index.php/BwUniCluster_Hardware_and_Architecture那么您有两个选择：

   1. 仅使用两种架构共有的选项。这通常需要针对旧版本进行优化。

   2. 在具有特定架构的节点上编译并针对该架构进行优化。通常，诸如 SLURM 之类的作业调度程序允许通过约束来选择资源。不过，请询问您的集群管理员。之后，当您运行代码时，请确保将可以运行的节点集限制为仅具有合适架构的节点集，否则程序可能会崩溃。

这些是粗略的指导方针。如果我不能 100% 确定编译会成功，我自己宁愿不将编译脚本提交到队列中。在这种情况下，我提交了一个交互式会话的请求，这本质上就像ssh一个节点，一旦请求的时间到了，只有批处理系统会把你踢出去。