5 ms·

You're saying that shared memory concurrency is the future? I think you've got it completely wrong. Shared memory concurrency is the past. It was thought to be

by catern 5y ago

You're saying that shared memory concurrency is the future? I think you've got it completely wrong. Shared memory concurrency is the past. It was thought to be a good idea in the 80s and 90s, but we now know that it's both hard to program, and that it works poorly with highly-parallel, high-performance hardware. In the future, we'll see more and more programming systems which don't provide shared memory concurrency at all.

bottled_poe 5y ago
I believe there will always be situations (though specific) where a shared-memory concurrency model is the most efficient and performant use of available resources. For this reason alone, shared-memory concurrency will always have a place. That said, I generally agree that the isolated parallel memory model is preferable for simplicity's sake.
jerf 5y ago
Shared memory space, not necessarily shared memory. I referenced Erlang & Pony after all so it's not like I'm unaware of the issues here. You don't need a full OS process boundary to separate things; it is a very crude and blunt instrument and there are much better options available. Separation is nice but paying to cross OS boundaries with every message kills performance dead. A full OS process boundary between all concurrently-running threads would be insane overkill for a Rust, Erlang or Pony program, and in practice, with best practices and the use of some tooling, even for Go, even if it is just old-fashioned shared-memory at its core.
- catern 5y ago
  "Memory space" is usually called "address space". And I think you're confused - context switching is expensive but there's no context switching involved when you're running in parallel across N cores. We're talking about parallelism, not concurrency.
  - jerf 5y ago
    No, we're talking about what I'm talking about. I've started the whole thread and participated all the way down to here. I also find myself wondering if you understand what we're talking about. I know what I'm saying about terminology is a bit controversial, but the nature of what existing run time systems are doing is not. They've been doing it for decades. But I guess we'll just have to leave it there.

by catern 5y ago

bottled_poe 5y ago

I believe there will always be situations (though specific) where a shared-memory concurrency model is the most efficient and performant use of available resources. For this reason alone, shared-memory concurrency will always have a place. That said, I generally agree that the isolated parallel memory model is preferable for simplicity's sake.

jerf 5y ago

Shared memory space, not necessarily shared memory. I referenced Erlang & Pony after all so it's not like I'm unaware of the issues here. You don't need a full OS process boundary to separate things; it is a very crude and blunt instrument and there are much better options available. Separation is nice but paying to cross OS boundaries with every message kills performance dead. A full OS process boundary between all concurrently-running threads would be insane overkill for a Rust, Erlang or Pony program, and in practice, with best practices and the use of some tooling, even for Go, even if it is just old-fashioned shared-memory at its core.

catern 5y ago
"Memory space" is usually called "address space". And I think you're confused - context switching is expensive but there's no context switching involved when you're running in parallel across N cores. We're talking about parallelism, not concurrency.
- jerf 5y ago
  No, we're talking about what I'm talking about. I've started the whole thread and participated all the way down to here. I also find myself wondering if you understand what we're talking about. I know what I'm saying about terminology is a bit controversial, but the nature of what existing run time systems are doing is not. They've been doing it for decades. But I guess we'll just have to leave it there.