3 ms·

The kind of app that needs to scale up to 4-8 processors but never higher is pretty rare. For anything bigger than that you need a full-blown distributed archit

The kind of app that needs to scale up to 4-8 processors but never higher is pretty rare. For anything bigger than that you need a full-blown distributed architecture. Unless you're sure you can scale forever in one box relying on language-level parallelism is asking for trouble.

_delirium 15y ago
I tend to see using 4-8 cores as having roughly the same use case as compiler optimizations: making code running on one box do so faster, usually by a constant factor. That's a pretty big use case, though. If, for example, a significant part of Matlab's built-in functions could use all 4 of my cores, and got maybe a 2x speedup overall from doing so, that'd be pretty great. (Matlab in particular seems to have already added quite a bit of this.)
bemmu 15y ago
Triple-A 3D games might fall into this category.
- cageface 15y ago
  Yeah, and the high-end multimedia authoring tools, and database engines. Ironically, all of these need every drop of performance you can squeeze out of a machine so nice, high-level languages like Haskell are off the table and you have to slog through with C++ and low-level threading.
  - mononcqc 15y ago
    funnily enough, many DB engines are written in Erlang -- a usually slow, high-level language. CouchDB, Riak, Mnesia, Hibari, Amazon SimpleDB, etc. They're not completely off the table.
mooism2 15y ago
I thought Moore's law was enabling new processors to include more cores at no extra cost. So there should be processors with more than 8 cores before too long.
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 ago
  But 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 ago
    Local 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.
nickik 15y ago
If you have a distributed architecture you are probebly going to build some nodes. When programming that software for these nodes you want to use all the 4-8 cores that the node can use. Sure you could only use one core on every maschine and spin up 4-8 maschines but that not effective.
- cageface 15y ago
  Unless each of your processes needs a lot of memory, the easy way to leverage those cores is to spin up a server process for each core.
  - jshen 15y ago
    no it's not. How do you coordinate between those processes? It's far easier to use a producer/consumer model on the jvm with threads. I do this all the time and it's really easy, much easier than managing multiple processes and some kind of external queue like redis.
    - cageface 15y ago
      If you're writing a distributed app you have to write the process coordination logic and the fact that two processes happen to be on the same machine is incidental. This is how all the big webapps scale.
      - jshen 15y ago
        But you make a giant mistake assuming that everyone is writing big web apps.
        cageface 15y ago
        Assuming no such thing. It's just the easiest example to hand. At Pixar we used similar techniques for rendering.
        15y ago
jshen 15y ago
"The kind of app that needs to scale up to 4-8 processors but never higher is pretty rare." I disagree. At my last job I exclusively made internal web apps that could always live on a single server. They never needed to scale beyond the cores on 1 box, but most benefited from using all cores on that box.

_delirium 15y ago

I tend to see using 4-8 cores as having roughly the same use case as compiler optimizations: making code running on one box do so faster, usually by a constant factor. That's a pretty big use case, though. If, for example, a significant part of Matlab's built-in functions could use all 4 of my cores, and got maybe a 2x speedup overall from doing so, that'd be pretty great. (Matlab in particular seems to have already added quite a bit of this.)

bemmu 15y ago

Triple-A 3D games might fall into this category.

cageface 15y ago
Yeah, and the high-end multimedia authoring tools, and database engines. Ironically, all of these need every drop of performance you can squeeze out of a machine so nice, high-level languages like Haskell are off the table and you have to slog through with C++ and low-level threading.
- mononcqc 15y ago
  funnily enough, many DB engines are written in Erlang -- a usually slow, high-level language. CouchDB, Riak, Mnesia, Hibari, Amazon SimpleDB, etc. They're not completely off the table.

mooism2 15y ago

I thought Moore's law was enabling new processors to include more cores at no extra cost. So there should be processors with more than 8 cores before too long.

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 ago
But 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 ago
  Local 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.

nickik 15y ago

If you have a distributed architecture you are probebly going to build some nodes. When programming that software for these nodes you want to use all the 4-8 cores that the node can use. Sure you could only use one core on every maschine and spin up 4-8 maschines but that not effective.

cageface 15y ago
Unless each of your processes needs a lot of memory, the easy way to leverage those cores is to spin up a server process for each core.
- jshen 15y ago
  no it's not. How do you coordinate between those processes? It's far easier to use a producer/consumer model on the jvm with threads. I do this all the time and it's really easy, much easier than managing multiple processes and some kind of external queue like redis.
  - cageface 15y ago
    If you're writing a distributed app you have to write the process coordination logic and the fact that two processes happen to be on the same machine is incidental. This is how all the big webapps scale.
    - jshen 15y ago
      But you make a giant mistake assuming that everyone is writing big web apps.
      - cageface 15y ago
        Assuming no such thing. It's just the easiest example to hand. At Pixar we used similar techniques for rendering.
        15y ago

jshen 15y ago

"The kind of app that needs to scale up to 4-8 processors but never higher is pretty rare." I disagree. At my last job I exclusively made internal web apps that could always live on a single server. They never needed to scale beyond the cores on 1 box, but most benefited from using all cores on that box.