4 ms·

I have no idea how they think IPC is as quick as in-process. I do it pretty quickly with memory mapping (shared memory between data providers and consumers), bu

I have no idea how they think IPC is as quick as in-process. I do it pretty quickly with memory mapping (shared memory between data providers and consumers), but it has at least an order of magnitude overhead compared to a concurrent queue even after 30 years. Tannenbaum must be threatened by the growing linux community to start throwing flamebaits like this.

adrian_b 2y ago
I do not understand what you say. The best performance for IPC is achieved indeed as you say, using shared memory between the communicating parties. But once you have shared memory, you can implement in it any kind of concurrent queue you want, without any kind of overhead in comparison with in-process communication between threads. While other kinds of IPC, which need context switches between kernel and user processes, are slow, IPC through shared memory has exactly the same performance as inter-thread communication inside a process. Inter-thread communication may need to use event-waiting syscalls, which cause context switches, but these are always needed when long waiting times are possible, regardless if the communication is inter-process or inside a process. Mach and other early attempts at implementing micro-kernels have made the big mistake of trying to do IPC mediated by the kernel, which unavoidably has a low performance. The right way to do a micro-kernel is for it to not handle any IPC, but only scheduling, event handling and resource allocation, including the allocation of the shared memory that enables direct communication between processes.
- nurettin 2y ago
  I tested it, communicating with a process through shared memory vs communicating with a thread via queue has an overhead. Like 1m eps vs 10m eps. It might be due to implementation.
  - adrian_b 2y ago
    The implementations of whatever queues or buffers were used for communication must have been different. There is absolutely no difference between memory pages that are shared by multiple processes and memory pages that are private to a process. If you use the same implementation of a buffer/message queue or whatever other data structure you want to use for communication, it does not matter whether it is located in private memory or in shared memory. Similarly, there is no difference between threads that belong to the same process and threads that belong to different processes, except that the threads that belong to the same process share all their memory, not only a part of it. Nevertheless, on modern CPUs measuring the IPC performance may sometimes be misleading, because the benchmark results can be altered randomly by the thread scheduler of the OS, because the IPC performance may differ depending on the pair of CPU cores where the threads happened to be located during the benchmark. For reproducible benchmark results, regardless whether threads from the same process or from different processes are tested, the threads must be pinned to some cores, which must be the same when you measure communication inside a process or between processes. Otherwise the results can be quite different depending on what kind of cache memories are shared between the measured cores or on their position on the chip on the communication network or ring that connects the cores.
xorcist 2y ago
Welcome to the future. We have microservices.
- teleforce 2y ago
  Microservices Are Technical Debt: https://news.ycombinator.com/item?id=41620166 https://news.ycombinator.com/item?id=41620166
pjmlp 2y ago
Meanwhile most Linux distros run containers all over the place, serialising into and out of JSON in every single RPC call, with users shipping Electron applications all over the place. Got to put all that monolithic kernel performance to good use. /s

adrian_b 2y ago

I do not understand what you say. The best performance for IPC is achieved indeed as you say, using shared memory between the communicating parties. But once you have shared memory, you can implement in it any kind of concurrent queue you want, without any kind of overhead in comparison with in-process communication between threads. While other kinds of IPC, which need context switches between kernel and user processes, are slow, IPC through shared memory has exactly the same performance as inter-thread communication inside a process. Inter-thread communication may need to use event-waiting syscalls, which cause context switches, but these are always needed when long waiting times are possible, regardless if the communication is inter-process or inside a process. Mach and other early attempts at implementing micro-kernels have made the big mistake of trying to do IPC mediated by the kernel, which unavoidably has a low performance. The right way to do a micro-kernel is for it to not handle any IPC, but only scheduling, event handling and resource allocation, including the allocation of the shared memory that enables direct communication between processes.

nurettin 2y ago
I tested it, communicating with a process through shared memory vs communicating with a thread via queue has an overhead. Like 1m eps vs 10m eps. It might be due to implementation.
- adrian_b 2y ago
  The implementations of whatever queues or buffers were used for communication must have been different. There is absolutely no difference between memory pages that are shared by multiple processes and memory pages that are private to a process. If you use the same implementation of a buffer/message queue or whatever other data structure you want to use for communication, it does not matter whether it is located in private memory or in shared memory. Similarly, there is no difference between threads that belong to the same process and threads that belong to different processes, except that the threads that belong to the same process share all their memory, not only a part of it. Nevertheless, on modern CPUs measuring the IPC performance may sometimes be misleading, because the benchmark results can be altered randomly by the thread scheduler of the OS, because the IPC performance may differ depending on the pair of CPU cores where the threads happened to be located during the benchmark. For reproducible benchmark results, regardless whether threads from the same process or from different processes are tested, the threads must be pinned to some cores, which must be the same when you measure communication inside a process or between processes. Otherwise the results can be quite different depending on what kind of cache memories are shared between the measured cores or on their position on the chip on the communication network or ring that connects the cores.

xorcist 2y ago

Welcome to the future. We have microservices.

teleforce 2y ago
Microservices Are Technical Debt: https://news.ycombinator.com/item?id=41620166 https://news.ycombinator.com/item?id=41620166

pjmlp 2y ago

Meanwhile most Linux distros run containers all over the place, serialising into and out of JSON in every single RPC call, with users shipping Electron applications all over the place. Got to put all that monolithic kernel performance to good use. /s