4 ms·
This is a false dichotomy; taking advantage of language-level parallelism doesn't prevent you from supporting a full-blown distributed architecture. In fact, i
by nupark2 15y ago
This is a false dichotomy; taking advantage of language-level parallelism doesn't prevent you from supporting a full-blown distributed architecture.
In fact, if so inclined, you can model your distributed architecture on top of language-level (or OS-level) parallelism; message passing can be considerably cheaper when you can rely on simple shared memory mechanisms.
Parallelism in the language environment allows you to make better use of the hardware you have. In a server environment, there's a fixed power utilization cost for each machine, and a per-CPU core power cost. It's cheaper and more efficient to scale up cores than it is to scale horizontally across machines. In fact, the more efficient you are, the longer you can put off the complexity of large-scale horizontal scaling.
In a mobile environment, the equation is different -- you can't just add more mobile devices to scale horizontally. The device has X amount of cores, period. If you don't use them, your application's performance will not be up to par with other applications.
- cageface 15y agoBut all the assumptions you make about reliability in a single box go right out the window when you start building a distributed app. The point is that you can't rely on simple shared memory mechanisms anymore. All those pretty parallel algorithms go straight in the bin. This is why Erlang looks nothing like Haskell. And if you have to endure the pain of writing a distributed app, why would you layer another level of concurrent complexity underneath it?
- nupark2 15y agoLocal concurrency and shared memory can be used to improve performance of operations that may be distributed; assuming proper implementations, a shared memory mailbox will always be cheaper than forcing multiple data copies of network/pipe based messaging, even if the API for both transports is identical.