5 ms·

(shared-nothing = copy-everything != blazingly fast)? also: (multi-threading + shared-nothing) = much less complexity = more correctness

fsloth 9y ago
"shared-nothing = copy-everything != blazingly fast)?" Not OP, but, if that does not give you more speed I'm not sure your problem should be multithreaded in the first place. Threads themselves are not free, there is a non-trivial cost in switching thread context. Trying to use multiple threads to wiggle the same memory area is insanity in most cases however you look it.
- yzmtf2008 9y ago
  An example where it's not insanity (while it might seem to be): https://arxiv.org/abs/1106.5730 https://arxiv.org/abs/1106.5730
- chacham15 9y ago
  I dont think this is true. The first example that came to my mind was a database. Shared-nothing + copy-everything is a very bad idea there and it is a thing that definitely needs to be multithreaded for performance.
- hiram112 9y ago
  Comment if you can: We've got an app that is pretty slow. Partially the fault of the front-end doing a lot of synchronous promises. But on the backend we have a lot of calls where we are getting a list off foos from the DB, then spinning through for loops and making one or two synchronous calls to other microseconds to fill in the details. I hated algorithms - but this is O(n^2) and we could cut it down to 2n -> O(n) by spinning off the fir loop to futures. This is java using completable futures with whatever thread pool the generic executor creates. Any issues?
- moomin 9y ago
  Make the messages immutable. Then the message passing is blazingly fast. You can argue about whether that’s strictly “shared-nothing” but practically it works. Ofc, in Rust you can safely send mutable messages and transfer ownership.
manmal 9y ago
copy-everything != copy-everything. clever compilers can reuse addresses of variables for as long as they are not written to, and still call it a „copy“. Eg structs in Swift are most of the time not copied, but rather referenced. Even copying is quite cheap nowadays. Waiting on a trap or semaphore, THAT‘s slow.
- laythea 9y ago
  "clever compilers can reuse addresses of variables for as long as they are not written to" Still chewing on this, but it would immediately strike me that relying on this behaviour in a software application, for it to be performant, would be a bad idea.
  - manmal 9y ago
    Since the type system is so strict, the compiler can often infer immutability even for mutable variables, and avoid copying in those cases. Swift’s compiler will even warn you if you declared a variable mutable when it’s never mutated. It’s an optimization rather than a guiding principle, but a very powerful one. Swift now is quasi on par with C++ performance, also thanks to optimizations like this.
    - laythea 9y ago
      Thanks for the info, that's interesting (I didn't know that). But it still seems like cheating :)
ranit 9y ago
You don't need to copy immutable values.
- 1ris 9y ago
  I feel that immutable (almost) everything is good thing for multi-threaded programming and programming in general.
  - agumonkey 9y ago
    took decades and hardware capabilities for mainstream to realize that immutability can be extremely good for 1) people reasoning 2) machine execution.
    - pron 9y ago
      Immutability is quite the opposite of good for machine execution. Much of modern CPU architecture is based on the idea of memory locality, and that you'd be reusing the same memory addresses in a given unit of work. Also, immutability helps people reason when the language doesn't have a clock. If the language does have a clock -- i.e. it is synchronous, like Eve or Céu -- mutability poses no difficulty.
- laythea 9y ago
  If you don't copy it and don't wait on any synchronisation mechanisms, how do you protect the memory?
  - kccqzy 9y ago
    You don’t need to protect it if every thread only ever reads it without writing.
    - laythea 9y ago
      Someone writes to it. And if they write before the read threads are run (and never again), then this is not really equivalent to the complexity we imagine when we say complexity in the context of multi-threading.
rkangel 9y ago
"shared-nothing" does NOT implicitly mean "copy-everything" You can pass an object around between threads with no issues, as long as only one of them owns it at a time. This is generally the model that is used in practice (although often in functional languages it's hidden under some CoW semantics).

fsloth 9y ago

"shared-nothing = copy-everything != blazingly fast)?" Not OP, but, if that does not give you more speed I'm not sure your problem should be multithreaded in the first place. Threads themselves are not free, there is a non-trivial cost in switching thread context. Trying to use multiple threads to wiggle the same memory area is insanity in most cases however you look it.

yzmtf2008 9y ago
An example where it's not insanity (while it might seem to be): https://arxiv.org/abs/1106.5730 https://arxiv.org/abs/1106.5730
chacham15 9y ago
I dont think this is true. The first example that came to my mind was a database. Shared-nothing + copy-everything is a very bad idea there and it is a thing that definitely needs to be multithreaded for performance.
hiram112 9y ago
Comment if you can: We've got an app that is pretty slow. Partially the fault of the front-end doing a lot of synchronous promises. But on the backend we have a lot of calls where we are getting a list off foos from the DB, then spinning through for loops and making one or two synchronous calls to other microseconds to fill in the details. I hated algorithms - but this is O(n^2) and we could cut it down to 2n -> O(n) by spinning off the fir loop to futures. This is java using completable futures with whatever thread pool the generic executor creates. Any issues?
moomin 9y ago
Make the messages immutable. Then the message passing is blazingly fast. You can argue about whether that’s strictly “shared-nothing” but practically it works. Ofc, in Rust you can safely send mutable messages and transfer ownership.

manmal 9y ago

copy-everything != copy-everything. clever compilers can reuse addresses of variables for as long as they are not written to, and still call it a „copy“. Eg structs in Swift are most of the time not copied, but rather referenced. Even copying is quite cheap nowadays. Waiting on a trap or semaphore, THAT‘s slow.

laythea 9y ago
"clever compilers can reuse addresses of variables for as long as they are not written to" Still chewing on this, but it would immediately strike me that relying on this behaviour in a software application, for it to be performant, would be a bad idea.
- manmal 9y ago
  Since the type system is so strict, the compiler can often infer immutability even for mutable variables, and avoid copying in those cases. Swift’s compiler will even warn you if you declared a variable mutable when it’s never mutated. It’s an optimization rather than a guiding principle, but a very powerful one. Swift now is quasi on par with C++ performance, also thanks to optimizations like this.
  - laythea 9y ago
    Thanks for the info, that's interesting (I didn't know that). But it still seems like cheating :)

ranit 9y ago

You don't need to copy immutable values.

1ris 9y ago
I feel that immutable (almost) everything is good thing for multi-threaded programming and programming in general.
- agumonkey 9y ago
  took decades and hardware capabilities for mainstream to realize that immutability can be extremely good for 1) people reasoning 2) machine execution.
  - pron 9y ago
    Immutability is quite the opposite of good for machine execution. Much of modern CPU architecture is based on the idea of memory locality, and that you'd be reusing the same memory addresses in a given unit of work. Also, immutability helps people reason when the language doesn't have a clock. If the language does have a clock -- i.e. it is synchronous, like Eve or Céu -- mutability poses no difficulty.
laythea 9y ago
If you don't copy it and don't wait on any synchronisation mechanisms, how do you protect the memory?
- kccqzy 9y ago
  You don’t need to protect it if every thread only ever reads it without writing.
  - laythea 9y ago
    Someone writes to it. And if they write before the read threads are run (and never again), then this is not really equivalent to the complexity we imagine when we say complexity in the context of multi-threading.

rkangel 9y ago

"shared-nothing" does NOT implicitly mean "copy-everything" You can pass an object around between threads with no issues, as long as only one of them owns it at a time. This is generally the model that is used in practice (although often in functional languages it's hidden under some CoW semantics).