3 ms·
"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 t
by 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 agoAn 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 agoI 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 agoComment 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 agoMake 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.