Live data from Hacker News

How fast are Linux pipes anyway? (2022)

mazzo.li

11–20 of 46 posts

Re: How fast are Linux pipes anyway? (2022)

#11
post #7

Seared into my soul is the experience porting a linux pipe-based application to Windows, thinking it's all posix and given it's all in memory the performance will be more or less the same. The performance was hideous, even after we found that having pipes waiting for a connection more or less ground windows to a halt. Some years later this got revisited due to needing to use the same thing under C# on Win10 and while…

Some years back Windows added AF_UNIX sockets, I wonder how those would perform relative to Win32 pipes. My guess is better.

Re: How fast are Linux pipes anyway? (2022)

#12
post #9

FWIW there is readv() / writev(), splice(), sendfile(), funopen(), and io_buffer() as well. splice() is great when transferring data between pipes and UNIX sockets with zero-copy, but it is Linux-only. splice() is the fastest and most efficient way to transfer data through pipes (on Linux), especially for large volumes. It bypasses memory allocations in userspace (as opposed to read(v)/write(v)), there is no extra bu…

> sendfile() is file-to-socket (zero-copy as well), and has very high performance as well, for both Linux and BSDs. It only supports file-to-socket, however, and well, to stay relevant, sendmsg() can't be used with pipes in the general case, it is for UNIX domain sockets, INET sockets, and other socket types. On Linux, sendfile supports more than just file to socket, as it's implemented using splice. I've used it for…

On BSDs probably not, as they don't have splice, but that is good to know. I wonder if on BSDs it really is readv() and writev() that are the fastest way to achieve the same thing as has been done in the article. Maybe I am missing something. I would like to be corrected.

Re: How fast are Linux pipes anyway? (2022)

#13
post #9

Earlier quoted context omitted.

> sendfile() is file-to-socket (zero-copy as well), and has very high performance as well, for both Linux and BSDs. It only supports file-to-socket, however, and well, to stay relevant, sendmsg() can't be used with pipes in the general case, it is for UNIX domain sockets, INET sockets, and other socket types. On Linux, sendfile supports more than just file to socket, as it's implemented using splice. I've used it for…

On BSDs probably not, as they don't have splice, but that is good to know. I wonder if on BSDs it really is readv() and writev() that are the fastest way to achieve the same thing as has been done in the article. Maybe I am missing something. I would like to be corrected.

AFAIK, neither OpenBSD nor NetBSD has sendfile. On FreeBSD, I think you're correct regarding it being file-to-socket only.

Re: How fast are Linux pipes anyway? (2022)

#14
post #7

Seared into my soul is the experience porting a linux pipe-based application to Windows, thinking it's all posix and given it's all in memory the performance will be more or less the same. The performance was hideous, even after we found that having pipes waiting for a connection more or less ground windows to a halt. Some years later this got revisited due to needing to use the same thing under C# on Win10 and while…

Well POSIX only defines behavior, not performance. Every platform and OS will have its own performance idiosyncracies.

Re: How fast are Linux pipes anyway? (2022)

#15
post #13

Earlier quoted context omitted.

On BSDs probably not, as they don't have splice, but that is good to know. I wonder if on BSDs it really is readv() and writev() that are the fastest way to achieve the same thing as has been done in the article. Maybe I am missing something. I would like to be corrected.

AFAIK, neither OpenBSD nor NetBSD has sendfile. On FreeBSD, I think you're correct regarding it being file-to-socket only.

Indeed, if I'm not mistaken Netflix at least used to use (and commit to kernel) FreeBSD on content servers because of its superior sendfile performance

Re: How fast are Linux pipes anyway? (2022)

#16
Does modern Linux have anything close to Doors? I’ve an embedded application where two processes exchange small amounts of data which are latency sensitive, and I’m wondering if there’s anything better than AF_UNIX.

Re: How fast are Linux pipes anyway? (2022)

#17
post #7

Seared into my soul is the experience porting a linux pipe-based application to Windows, thinking it's all posix and given it's all in memory the performance will be more or less the same. The performance was hideous, even after we found that having pipes waiting for a connection more or less ground windows to a halt. Some years later this got revisited due to needing to use the same thing under C# on Win10 and while…

Well POSIX only defines behavior, not performance. Every platform and OS will have its own performance idiosyncracies.

How on earth would POSIX define performance of something like pipes?

Re: How fast are Linux pipes anyway? (2022)

#18
post #17

Earlier quoted context omitted.

Well POSIX only defines behavior, not performance. Every platform and OS will have its own performance idiosyncracies.

How on earth would POSIX define performance of something like pipes?

I was addressing "it's all posix and given it's all in memory the performance will be more or less the same."

Not claiming that POSIX should or could attempt to address performance.

Re: How fast are Linux pipes anyway? (2022)

#19

FWIW there is readv() / writev(), splice(), sendfile(), funopen(), and io_buffer() as well. splice() is great when transferring data between pipes and UNIX sockets with zero-copy, but it is Linux-only. splice() is the fastest and most efficient way to transfer data through pipes (on Linux), especially for large volumes. It bypasses memory allocations in userspace (as opposed to read(v)/write(v)), there is no extra bu…

Shared memory, like shm_open and fd passing, would be even faster and fully portable.

Re: How fast are Linux pipes anyway? (2022)

#20
post #16

Does modern Linux have anything close to Doors? I’ve an embedded application where two processes exchange small amounts of data which are latency sensitive, and I’m wondering if there’s anything better than AF_UNIX.

shared memory provides the lowest latency, but you still need to deal with task wakeup, which is usually done via futexs. Google was working on a FUTEX_SWAP call for linux which would have allowed direct handover from one task to another, not sure what happened to that.
Post reply on HN