5 ms·

I agree with regards to lock-free not being faster than lock-based, but that: > replace threads with separate processes that communicate via ring buffers does

by adwn 6y ago

I agree with regards to lock-free not being faster than lock-based, but that: > replace threads with separate processes that communicate via ring buffers does not follow at all. Interprocess communication is always more work to set up and less efficient [1] than interthread communication. The only thing separate processes gain you is enforced memory protection. [1] Different processes need different TLB entries, while different threads in the same process do not.

gpderetta 6y ago
TLB is not necessarily an issue as presumably you would be running the processes on different cores. The primary problem is that separate address spaces requires messages to be serialized (although of course serialization can be trivial). With shared memory you can share (or transfer ownership of) data by simply sharing a pointer.
- ncmncm 6y ago
  TLB usage is an advantage as each process, pinned to a core, gets its own. TLB shootdowns vanish. Cache line ownership, similarly, does not pingpong. Sharing pointers causes fragility, as failure in one thread takes down the whole system. Transferring ownership would add coupling. But such objects can live in a shared-memory area. Pointers into shared regions do require some care. Ideally, only one process ever owns objects in each, most commonly just the ring buffer. With separate processes, they may come and go as needed. Yes, setting up shared memory for ring buffers is more work, but interactions establishing them are not fast-path. Decoupling via separate processes is a different architecture, but has real benefits to motivate it.
  - gpderetta 6y ago
    Oh, I agree, it is all tradeoffs. Losing the ability to cheaply share objects, including closures, is a big tradeoff though. BTW lock free queues and data structures are pretty much required for interprocess sharing, unless you really want to deal with robust mutexes (and you don't!)
    - ncmncm 6y ago
      I do it. Without mutexes. I don't count single-writer ring buffers among the ordinary lock-free queues, because there is no competition for access, and cache lines never change ownership. So, none of the overheads show up. And, they are very easy to get right, so pose none of the risk of subtle heisenbugs. Being able to kill and add downstream clients at random is worth a lot of architectural rejiggery.
bluGill 6y ago
It follows in a weird way: Processes requires more effort to communicate so you are less likely to send things across processes and when you do it is because it is worth it. You are also likely to batch the communication and then go off and compute. All of the above improve performance. Nothing about it requires processes though, you can get the same results with threads if you take just as much care. However processes do add one more thing: you can scale to multiple physical computers in ways threads can't.
- adwn 6y ago
  > However processes do add one more thing: you can scale to multiple physical computers in ways threads can't. Although this is technically true, communication with another system has orders of magnitude higher latency and lower bandwidth compared to other cores in the same CPU. So in practice, you'll typically have to redesign your approach anyway.
- ncmncm 6y ago
  Separate processes means no TLB shoot-downs. If you put ring buffers in hugepages, the number of TLB entries involved is small, typically 1. And, pinning the processes to cores, each gets its own set.

by adwn 6y ago

gpderetta 6y ago

TLB is not necessarily an issue as presumably you would be running the processes on different cores. The primary problem is that separate address spaces requires messages to be serialized (although of course serialization can be trivial). With shared memory you can share (or transfer ownership of) data by simply sharing a pointer.

ncmncm 6y ago
TLB usage is an advantage as each process, pinned to a core, gets its own. TLB shootdowns vanish. Cache line ownership, similarly, does not pingpong. Sharing pointers causes fragility, as failure in one thread takes down the whole system. Transferring ownership would add coupling. But such objects can live in a shared-memory area. Pointers into shared regions do require some care. Ideally, only one process ever owns objects in each, most commonly just the ring buffer. With separate processes, they may come and go as needed. Yes, setting up shared memory for ring buffers is more work, but interactions establishing them are not fast-path. Decoupling via separate processes is a different architecture, but has real benefits to motivate it.
- gpderetta 6y ago
  Oh, I agree, it is all tradeoffs. Losing the ability to cheaply share objects, including closures, is a big tradeoff though. BTW lock free queues and data structures are pretty much required for interprocess sharing, unless you really want to deal with robust mutexes (and you don't!)
  - ncmncm 6y ago
    I do it. Without mutexes. I don't count single-writer ring buffers among the ordinary lock-free queues, because there is no competition for access, and cache lines never change ownership. So, none of the overheads show up. And, they are very easy to get right, so pose none of the risk of subtle heisenbugs. Being able to kill and add downstream clients at random is worth a lot of architectural rejiggery.

bluGill 6y ago

It follows in a weird way: Processes requires more effort to communicate so you are less likely to send things across processes and when you do it is because it is worth it. You are also likely to batch the communication and then go off and compute. All of the above improve performance. Nothing about it requires processes though, you can get the same results with threads if you take just as much care. However processes do add one more thing: you can scale to multiple physical computers in ways threads can't.

adwn 6y ago
> However processes do add one more thing: you can scale to multiple physical computers in ways threads can't. Although this is technically true, communication with another system has orders of magnitude higher latency and lower bandwidth compared to other cores in the same CPU. So in practice, you'll typically have to redesign your approach anyway.
ncmncm 6y ago
Separate processes means no TLB shoot-downs. If you put ring buffers in hugepages, the number of TLB entries involved is small, typically 1. And, pinning the processes to cores, each gets its own set.