Hacker News new | past | comments | ask | show | jobs | submit login

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.



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.


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.


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.


But you make a giant mistake assuming that everyone is writing big web apps.


Assuming no such thing. It's just the easiest example to hand. At Pixar we used similar techniques for rendering.


you said, "the easy way to leverage those cores is to spin up a server process for each core"

It's not THE easy way. It's actually the harder way, but in some cases, like giant public web apps, you have to do the hardway anyway.

Managing a work queue using java.util.concurrent in process is far easier than managing many processes and coordinating across something like redis.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: