4 ms·

Thank you for taking the time to answer the question. In principle, I know how it ought to work. But when would I need to use it? For instance, if someone is

Thank you for taking the time to answer the question. In principle, I know how it ought to work. But when would I need to use it? For instance, if someone is making a web api, and you're pulling data from a database, should one think about it? If one is doing some data analysis, should one think about it? I always thought that it is a "low level" program that takes care of it. So tensorflow might worry about it, but I wouldn't if I use tensorflow. Or perhaps mapreduce worries about it, or the ORM worries about it. But when should I worry about it?

kjeetgill 8y ago
I don't know your experience so I'll do my best to draw on examples _I suspect_ you might be familiar with. I'll try to keep this simplified but deep enough. I'm taking a shot in the dark and hoping you're more familiar with the one of the python/node/ruby world. You should worry about it when you want to do something faster than you are already or want to do more things at once. Maybe someone's framework/service has done it for you maybe not. For a web api, the workload _usually_ looks like: {database call} -> {do some work} -> {maybe more calls} -> {more local work} -> {done}. In the python/node/ruby world where you have mostly single process workers. You get some parallelism by doing work locally while the database call is made asynchronously. If you want to handle more requests on a host you'll just run more processes and load balance across the front (nginx, gunicorn, etc). In languages with threads you usually do that INSIDE your program. A single process load balances across worker threads internally. At first blush, multiple threads are pretty similar to just running multiple programs. It gets more complicated when you start talking about how you want to communicate between them or share resources across them. For data analysis you often have algorithms that are embarrassingly parallel[0] chained together. You use threads the same way you'd call three friends to help you move. You all pack boxes at the same time without really needing to coordinate and then you start loading the truck where you have to talk more. One might wait in the truck and organize while 2 or 3 others might be shuttling boxes outside. Maybe everyone sits around while the stairs are blocked by one person moving a shelf. It just depends. Having 4 people helps sometimes or is disruptive in others. [0]: https://en.wikipedia.org/wiki/Embarrassingly_parallel https://en.wikipedia.org/wiki/Embarrassingly_parallel P.S. - To address your examples: tensorflow, map-reduce, orms. etc. It's all still about parallelism but not necessarily about threads. Parallelism is just doing more things at the same time. Threads are (mostly) about CPU parallelism, but many of those use other resources to get parallelism. Tensorflow might use the GPU, which has many threads internally (simplification), to do one thing while the CPU does another. Mapreduce will use a lot of different machines across a cluster, but maybe only a thread or two on each, to archive parallelism (and really getting disk IO parallelism). And ORM will call the database and let it do work while your CPU else instead of wait.
- projectramo 8y ago
  Great answer. You should post that on a blog if you have one. This was the best part if you want to expand on it in a longer post: "You should worry about it when you want to do something faster than you are already or want to do more things at once. Maybe someone's framework/service done it for you maybe not. For a web api, the workload _usually_ looks like: {database call} -> {do some work} -> {maybe more calls} -> {more local work} -> {done}. In the python/node/ruby world where you have mostly single process workers. You get some parallelism by doing work locally while the database call is made asynchronously. If you want to handle more requests on a host you'll just run more processes and load balance across the front (nginx, gunicorn, etc). In languages with threads you usually do that INSIDE your program. A single process load balances across worker threads internally. At first blush, multiple threads are pretty similar to just running multiple programs. It gets more complicated when you start talking about how you want to communicate between them or share resources across them."
  - kjeetgill 8y ago
    Thanks, I'm glad it was helpful! I don't have a blog yet, but I started commenting a month back to build up some writing chops so I'm especially happy to hear it.
sam0x17 8y ago
If all you ever deal with are what are known as "embarrassingly parallel" problems, where you don't need to do any synchronization or intermediate communication between cores, then true parallelism isn't really needed and you can do whatever you were trying to do with simple process forking or something of that nature. Problems that are not embarrassingly parallel often require frequent and complicated communication and synchronization between cores. For this you need to use a real multi-threading library, or do some complicated message passing on a per-process level. If you need hundreds of workers, it is better to use something more light-weight than a thread, as Go does. Once crystal's parallelism support is added, it will have these light-weight "go-style" threads, so this complaint will disappear.

kjeetgill 8y ago

I don't know your experience so I'll do my best to draw on examples _I suspect_ you might be familiar with. I'll try to keep this simplified but deep enough. I'm taking a shot in the dark and hoping you're more familiar with the one of the python/node/ruby world. You should worry about it when you want to do something faster than you are already or want to do more things at once. Maybe someone's framework/service has done it for you maybe not. For a web api, the workload _usually_ looks like: {database call} -> {do some work} -> {maybe more calls} -> {more local work} -> {done}. In the python/node/ruby world where you have mostly single process workers. You get some parallelism by doing work locally while the database call is made asynchronously. If you want to handle more requests on a host you'll just run more processes and load balance across the front (nginx, gunicorn, etc). In languages with threads you usually do that INSIDE your program. A single process load balances across worker threads internally. At first blush, multiple threads are pretty similar to just running multiple programs. It gets more complicated when you start talking about how you want to communicate between them or share resources across them. For data analysis you often have algorithms that are embarrassingly parallel[0] chained together. You use threads the same way you'd call three friends to help you move. You all pack boxes at the same time without really needing to coordinate and then you start loading the truck where you have to talk more. One might wait in the truck and organize while 2 or 3 others might be shuttling boxes outside. Maybe everyone sits around while the stairs are blocked by one person moving a shelf. It just depends. Having 4 people helps sometimes or is disruptive in others. [0]: https://en.wikipedia.org/wiki/Embarrassingly_parallel https://en.wikipedia.org/wiki/Embarrassingly_parallel P.S. - To address your examples: tensorflow, map-reduce, orms. etc. It's all still about parallelism but not necessarily about threads. Parallelism is just doing more things at the same time. Threads are (mostly) about CPU parallelism, but many of those use other resources to get parallelism. Tensorflow might use the GPU, which has many threads internally (simplification), to do one thing while the CPU does another. Mapreduce will use a lot of different machines across a cluster, but maybe only a thread or two on each, to archive parallelism (and really getting disk IO parallelism). And ORM will call the database and let it do work while your CPU else instead of wait.

projectramo 8y ago
Great answer. You should post that on a blog if you have one. This was the best part if you want to expand on it in a longer post: "You should worry about it when you want to do something faster than you are already or want to do more things at once. Maybe someone's framework/service done it for you maybe not. For a web api, the workload _usually_ looks like: {database call} -> {do some work} -> {maybe more calls} -> {more local work} -> {done}. In the python/node/ruby world where you have mostly single process workers. You get some parallelism by doing work locally while the database call is made asynchronously. If you want to handle more requests on a host you'll just run more processes and load balance across the front (nginx, gunicorn, etc). In languages with threads you usually do that INSIDE your program. A single process load balances across worker threads internally. At first blush, multiple threads are pretty similar to just running multiple programs. It gets more complicated when you start talking about how you want to communicate between them or share resources across them."
- kjeetgill 8y ago
  Thanks, I'm glad it was helpful! I don't have a blog yet, but I started commenting a month back to build up some writing chops so I'm especially happy to hear it.

sam0x17 8y ago

If all you ever deal with are what are known as "embarrassingly parallel" problems, where you don't need to do any synchronization or intermediate communication between cores, then true parallelism isn't really needed and you can do whatever you were trying to do with simple process forking or something of that nature. Problems that are not embarrassingly parallel often require frequent and complicated communication and synchronization between cores. For this you need to use a real multi-threading library, or do some complicated message passing on a per-process level. If you need hundreds of workers, it is better to use something more light-weight than a thread, as Go does. Once crystal's parallelism support is added, it will have these light-weight "go-style" threads, so this complaint will disappear.