1. 56
  1.  

  2. 6

    On FreeBSD there is also netmap(4) which offers zero copy pipes:

    1. 5

      would love to see the same with network communication via loopback devices (for example: MTU settings on a loopback device can have effects on software components transferring data locally only in terms of throghput).

      Also note: the “pv” utility attempts to use splice(2) by default! so if you compare pv throughputs against an application that doesnt, pv will outperform.

      1. 1

        Curious, I was expecting GNU coreutils dd(1) to use splice as well, but it appears that it doesn’t.

        1. 1

          Splice has to have at least one pipe argument. As the main use case for dd is file-to-file, there’s little point in using it. And splice is mostly fast because it can move kernel pages from one pipe (or socket) to another. File system pages are managed by the page cache, and—as far as I know—splice has to copy those pages rather than moving them.

          1. 1

            As the main use case for dd is file-to-file

            I get that, but this is a different use case. Here the reason to use dd is that status=progress shows transfer speed.

      2. 4

        Huh.

        I was curious to see how things stacked up on plan 9 vs linux, and while the machines are apples to oranges (my 9front box is a 2015-ish era Zbox with a Intel Core i5-7300HQ processor, and my Linux is a custom-built 12 core Ryzen 9 3900X), it’s fun to see how things turned out.

        I tweaked it to do 128 gigs instead of just 10, and here are the results:

        # 9front 595684fd8a2f08e12d5df48152d93fb8ab800fe3
        % time rc -c '6.write | 6.read'
        0.33u 23.28s 11.64r 	 rc -c 6.write | 6.read 
        
        # Linux 5.13.0-40-generic #45~20.04.1-Ubuntu SMP
        $ time sh -c './write | ./read'
        real    0m32.039s
        user    0m0.231s
        sys     0m34.576s
        

        It looks like in user time, 9front is nearly 3 times faster, while running on slower hardware. Not a shock, given that the I/O paths are shorter and simpler, but also not what I was expecting.

        1. 2

          related: if you are copying between two fds you can use copy_file_range

          1. 1

            I’ve read this somewhere. :)