gnu-parallel - 为什么在教程中使用 GNU Parallel --jobs 4 选项运行 5 个作业？

Question

我正在处理 GNU Parallel totorial .在“多个参数”部分中，有以下示例(注意:num30000 是一个文本文件，在连续行中的数字为 1 到 30,000):

For better parallelism GNU Parallel can distribute the arguments between all the parallel jobs when end of file is met.

Running 4 jobs in parallel will split the last line of arguments into 4 jobs resulting in a total of 5 jobs:

  cat num30000 | parallel --jobs 4 -m echo | wc -l

Output:

  5

我的问题是:为什么我们期望总共有 5 个工作岗位？我显然遗漏了一点，尽管我不知道这是否重要。因为 30,000 可以被 4 整除，所以我预计有 4 个工作。我决定在运行以下命令后发布这个问题:

cat num30000 | parallel --jobs 4 -m echo | colrm 12

这导致:

1 2 3 4 5 6
23696 23697
25273 25274
26850 26851
28427 28428

这在我看来就像第一个 echo命令传递了前 23,695 个参数。然后，其余的被分成 4 个作业，参数计数分别为 1577、1577、1577 和 1574。我是否误解了并行调用应该做什么？谢谢!

Answer 1

你对这个答案的代价是帮助我以某种方式改进这个例子，这样你在第一次阅读时就会理解它。

那么会发生以下情况:

GNU Parallel 计算出限制为 131071。然后它会查看当前正在运行的作业数量 (0)。这是否小于要并行运行的作业数 (4):然后它读取最多 131071 限制的参数并启动该作业。这是第一份工作。

现在 GNU Parallel 再次读取参数。这次它读取所有其余部分并到达文件末尾。 “哦，”GNU Parallel 想。 “如果这是文件的结尾，那么我会将所有参数散布到所有工作槽 (4) 上。”所以它需要所有其余的参数并将它们分布在 4 个工作中。然后它启动 3 个作业。现在有 4 个作业正在运行。

一个正在运行的作业完成，给出一个空闲的作业槽；所以 GNU Parallel 开始了最后的工作。

如果您有 4 个内核和 100 个参数，这种设计的原因就更清楚了:100 个参数很容易放在一行中，但通常在 4 核机器上运行 4 个带有 25 个参数的作业会比运行 1 个带有 100 个参数的作业快参数。