我可以例如执行：
parallel -j 200 < list0
其中“列表”有：
nice -n -20 parallel -j 100 < list2
nice -n -20 parallel -j 100 < list1
这可行/可能吗？
答案1
这不仅是可能的，而且是可能的。在某些情况下也建议这样做。
GNU Parallel 运行一个作业大约需要 10 毫秒。因此，如果您有 8 个核心，并且运行的作业花费的时间少于 70 毫秒，那么您将看到 GNU Parallel 使用 100% 的单个核心，但其他核心上会有空闲时间。因此您不会 100% 使用所有核心。
建议的另一种情况是，如果您想要运行的作业数量超出了-j0实际执行的数量。目前，-j0除非您调整某些系统限制，否则将并行运行大约 250 个作业。如果作业不受 CPU 和磁盘 I/O 的限制，那么运行 250 多个作业是非常有意义的。例如，如果网络延迟是限制因素，则情况如此。
然而，使用 2 个列表并不是推荐的分割作业的方法。推荐的方式是使用GNU Parallel来调用GNU Parallel：
cat list0 | parallel -j20 --pipe parallel -j100
这将并行运行 2000 个作业。要多跑调整-j。建议外部（20）至少为核心数，这样每个核心上至少有一个 GNU Parallel 进程。
使用这种技术，并行启动 20000 个作业应该没有问题；当进程超过 32000 个时，事情就开始出现问题。
通过第一次运行：
echo 4194304 | sudo tee /proc/sys/kernel/pid_max
我能够运行：
seq 1000000 2000000000 |
parallel -j16 --roundrobin --pipe parallel -j0 --pipe parallel -j0 sleep
它将并行启动 100 万个进程（我的系统需要 300 G RAM）。
答案2
我不明白为什么它不可能——系统当然可以同时处理 200 个并行任务。
但是，这几乎肯定是不可取的，除非有某些特定原因需要并行运行确切数量的任务。这似乎不太可能；我能看到的唯一原因是因为您需要它们同时存在，因为它们需要交换信息，或者以混乱和不确定的方式与其他东西交换信息（例如，用于测试服务器程序）。
之所以不希望这样做，是因为就效率而言，理想状态是系统运行的进程数量等于可用处理器核心的数量。由于进程在某种程度上经常涉及 CPU 外部的瓶颈（例如磁盘 I/O），因此这个广义的理想数字范围从核心数 + 1 到核心数 * 2。
这是理想状态效率的原因是，如果任务本身消耗 100 万单位的处理器时间，则顺序运行同一任务 10 次将消耗 1000 万单位，并行运行同一任务将消耗 1000 万单位。但是，在后一种情况下，如果 CPU 数量少于 10 个，有额外费用因为系统必须不断地从一项任务切换到另一项任务。
这也是为什么一般来说具有 2 x 2 Ghz 核心的系统比具有 4 x 1 Ghz 核心的系统更快。多核系统发展的主要原因是制造速度越来越快的CPU变得越来越困难，超过某个相对较低的点就不可能了。因此，解决方案是制造具有更多处理器内核的系统。
简而言之，如果你需要尽快做 20 件事，并且你有 4 个核心，那么最快的方法就是 5 组 4 组，或者 4 组 5 组，以留出等待的空闲时间。输入/输出。parallel允许您向其提供不定长度的列表，但限制一次运行的作业数量（请注意，该数量的默认值是核心数量）。
对此有一种例外，尽管它通常与某些类型的单一多线程程序相关（即，不是一堆单独的程序，而是一个占用多个内核的程序）。这是因为当一个程序可以通过相对独立的分支来完成某件事，而这些分支只需要偶尔进行协调（“偶尔”可能仍然是每秒 10 或 20 次）时，它会更容易，而且通常更灵活，将程序设计为在独立线程中执行此操作，而不是将其设计为以任意（异步）方式循环任务。视频游戏和 CAD 系统等图形密集型和/或交互式程序就属于这一类。