Dynamically allocated pseudo-filesystems [LWN.net]

Dynamically allocated pseudo-filesystems

Posted May 18, 2022 6:04 UTC (Wed) by zdzichu (subscriber, #17118)
In reply to: Dynamically allocated pseudo-filesystems by dgc
Parent article: Dynamically allocated pseudo-filesystems

The article didn't state _which find_ was used. We guess it was GNU/find.
I'm personally using https://github.com/sharkdp/fd daily. It parallelizes on all CPU cores by default.

to post comments

Dynamically allocated pseudo-filesystems

Posted May 18, 2022 8:43 UTC (Wed) by dgc (subscriber, #6611) [Link] (1 responses)

True, but it doesn't really matter _which find_ was used if it only used 100% CPU. A parallel find that was constrained to a single cpu would behave the same.

FWIW, I do know there are find (and other tool) variants out there that are multi-threaded. I use tools like lbzip2 because compression is another common operation that is trivially parallelisable. The problem is we have to go out of our way to discover and then install multi-threaded tools. It is long past the point where the distros should be defaulting to parallelised versions of common tools rather than they being the exception...

-Dave.

Dynamically allocated pseudo-filesystems

Posted May 26, 2022 14:31 UTC (Thu) by mrugiero (guest, #153040) [Link]

> I use tools like lbzip2 because compression is another common operation that is trivially parallelisable.

There are caveats for complession. Block schemes like bzip2 are trivially parallelisable with increased memory usage (which is quite low anyway) as the only drawback, but Lempel-Ziv and streaming compressors in general may take a hit to compression ratio, at least if done without care.