4 ms·

> rely on process-based parallelism which is basically strictly worse. Why is that worse? I very seldomly use threads for concurrency, it creates monolithic b

> rely on process-based parallelism which is basically strictly worse. Why is that worse? I very seldomly use threads for concurrency, it creates monolithic binaries that are hard to maintain, configure, and understand. I much prefer a process based architecture with mmap'd shared memories for interprocess communications.

snovv_crash 6y ago
Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer? Personally, I'd prefer to have a single binary that I start with some arguments, then need to also have a launch script, probably in a different language, which needs to coordinate all the starting, stopping, shared state etc. But, most of my work has been at the workstation level. Maybe it's different once you start needing clusters? The issue is that workstations have grown extremely powerful over the last few years with 50+ cores, 1000s of GPU 'cores', and hundreds of GB of memory. Clusters now bring the same headaches, in hardware, of multiprocess design.
- Galanwe 6y ago
  > Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer? That's true indeed, but I find it more manageable that way. To me, managing independent processes instead of threads is especially powerful when the lifecycle of the concurrent work can vary. A typical example that happens quite often is when you have some kind of producer/consumer application. Say, you need to receive some data from a socket, and then process it. If implemented with threads, it becomes quite messy very fast. You end up with a big blob binary that spawns whatever the hell it wants and need to engineer some complex configuration file to tell it how many workers you want, etc. You also need some notification to this process to tell him to increase or decrease its amount of workers, etc. With independent process, it can be much more manageable. You can have a "collector" process that reads the socket and places messages in a shared memory, and if you want more/less workers, you just spawn worker processes to read from the shared memory.
  - maccard 6y ago
    You can make exactly this argument the other way around: If implemented with processes it becomes quite messy very fast. You end up with a bunch of processes that do whatever the hell they want, and need some complex orchestrator script to tell it how many processes you want, and need some notifications to the orchestrator to increase or decrease the number of workers With threads, you can have a main thread that reads the socket and places messages in a shared queue, and if you want more/less workers you just spawn worker threads to read from the queue.
    - Galanwe 6y ago
      > if you want more/less workers you just spawn worker threads to read from the queue. My point is precisely that's its not trivial to do that. You now need some signal mechanism to tell your main process to spawn or kill workers. That's an additional layer of complexity. Things get even worse if you want to add new types of workers that were unplanned. Say I want a new type of worker that is just a forwarder, or a new type of worker that stores the queue on disk for replaying it. With a monolithic thread based design, you now need to stop your whole main and worker threads and start a newly built process that support these workers. With a process based design, you just spawn a new worker process and point it to the existing shared memory without any interruption.

snovv_crash 6y ago

Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer? Personally, I'd prefer to have a single binary that I start with some arguments, then need to also have a launch script, probably in a different language, which needs to coordinate all the starting, stopping, shared state etc. But, most of my work has been at the workstation level. Maybe it's different once you start needing clusters? The issue is that workstations have grown extremely powerful over the last few years with 50+ cores, 1000s of GPU 'cores', and hundreds of GB of memory. Clusters now bring the same headaches, in hardware, of multiprocess design.

Galanwe 6y ago
> Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer? That's true indeed, but I find it more manageable that way. To me, managing independent processes instead of threads is especially powerful when the lifecycle of the concurrent work can vary. A typical example that happens quite often is when you have some kind of producer/consumer application. Say, you need to receive some data from a socket, and then process it. If implemented with threads, it becomes quite messy very fast. You end up with a big blob binary that spawns whatever the hell it wants and need to engineer some complex configuration file to tell it how many workers you want, etc. You also need some notification to this process to tell him to increase or decrease its amount of workers, etc. With independent process, it can be much more manageable. You can have a "collector" process that reads the socket and places messages in a shared memory, and if you want more/less workers, you just spawn worker processes to read from the shared memory.
- maccard 6y ago
  You can make exactly this argument the other way around: If implemented with processes it becomes quite messy very fast. You end up with a bunch of processes that do whatever the hell they want, and need some complex orchestrator script to tell it how many processes you want, and need some notifications to the orchestrator to increase or decrease the number of workers With threads, you can have a main thread that reads the socket and places messages in a shared queue, and if you want more/less workers you just spawn worker threads to read from the queue.
  - Galanwe 6y ago
    > if you want more/less workers you just spawn worker threads to read from the queue. My point is precisely that's its not trivial to do that. You now need some signal mechanism to tell your main process to spawn or kill workers. That's an additional layer of complexity. Things get even worse if you want to add new types of workers that were unplanned. Say I want a new type of worker that is just a forwarder, or a new type of worker that stores the queue on disk for replaying it. With a monolithic thread based design, you now need to stop your whole main and worker threads and start a newly built process that support these workers. With a process based design, you just spawn a new worker process and point it to the existing shared memory without any interruption.