multithreading - GNU 并行 : assign one thread for each node (directories and sub* directories) of an entire tree from a start directory

Question

我想从 macOS 上 parallel 命令的所有潜力中受益(似乎存在 2 个版本，GNU 和 Ole Tange 的版本，但我不确定)。
使用以下命令:

parallel -j8  find {} ::: *

如果我位于包含 8 个子目录的目录中，我将有很大的表现。
但是如果所有这些子目录的内容都很小，只有一个，我将只有一个线程可以在唯一的“大”目录上工作。

有没有办法遵循这个“大目录”的并行化？我的意思是，剩下的唯一线程可以得到其他线程的帮助吗(前一个在小子目录上工作的线程)？
理想的情况是，当上面命令行中的 find 命令找到所有小子时，并行命令“自动切换”。也许我要求太多了？

如果存在另一个潜在的优化:考虑一个通用的树目录结构:有没有一种方法，例如类似于命令 make -j8 ，将每个当前线程分配给一个 sub-(sub-(sub-....))) ) 目录，一旦探索了当前目录(不要忘记，我最想使用这个优化与 find Linux 命令)，另一个线程探索另一个目录 sub-(sub-(sub- ....))) ) 目录？
当然，运行的总线程数不大于 parallel 命令指定的数量(我上面的例子中为 parallel -j8):我们可以说如果树元素的数量(1个节点=1个目录)大于多个线程，我们不能超过这个数字。
我知道在递归上下文中并行化很棘手，但是当我想在大树结构中查找文件时，也许我可以获得重要因素？
这就是为什么我以命令 make -j8 为例:我不知道它是如何编码的，但这让我觉得我们可以对我帖子开头的一对 parallel/find 命令行做同样的事情。

最后，我想就这两个问题获得您的建议，更一般地说，对于这些优化建议，目前哪些是可能的，哪些是不可能的，以便更快地找到具有经典 find 命令的文件。
UPDATE 1: 正如@OleTange 所说，我不知道我想要 gupdatedb 索引的内容的先验目录结构。因此，很难提前知道 maxdepth。您的解决方案很有趣，但 find 的第一次执行不是多线程的，您不使用 parallel 命令。我有点惊讶 gupdatedb 的多线程版本不存在:在纸面上，这是可行的，但是一旦我们想在 MacOS 10.15 的脚本 GNU gupdatedb 中对其进行编码，就更加困难了。
如果有人可以有其他建议，我会接受!

Answer 1

如果您要并行化 find您需要确保您的磁盘可以传输数据。
对于磁驱动器，您很少会看到加速。有时用于 RAID、网络驱动器和 SSD，通常用于 NVMe。
最简单的并行化方法 find是使用 */* :

parallel find ::: */*

或 */*/* :

parallel find ::: */*/*

这将在子子目录和子子子目录中搜索。
他们不会搜索顶级目录，但可以通过运行一个额外的 find 来完成。用合适的 -maxdepth .
上述解决方案假设您对目录结构有所了解，因此它不是通用解决方案。
我从未听说过通用的解决方案。这将涉及广度优先搜索，该搜索将同时启动一些工作人员。我可以看到它是如何被编程的，但我从未见过它。
如果我要实现它，它将是这样的(经过轻微测试):

#!/bin/bash

tmp=$(tempfile)
myfind() {
  find "$1" -mindepth 1 -maxdepth 1
}
export -f myfind
myfind . | tee $tmp
while [ -s $tmp ] ; do
    tmp2=$(tempfile)
    cat $tmp | parallel --lb myfind | tee $tmp2
    mv $tmp2 $tmp
done
rm $tmp

(PS:我有理由相信由 Ole Tange 和 GNU Parallel 编写的并行是一回事)。