3 ms·

This is what I appreciate about HN: reading that I was pretty convinced and had no idea what Crystal's shortcomings might be. Then I read the comments and the

This is what I appreciate about HN: reading that I was pretty convinced and had no idea what Crystal's shortcomings might be. Then I read the comments and the largest single complaint is lack of parallelism, by which people seem to mean being able to utilize all the cores of the processor. I've been programming for a while, but haven't run into this issue. Can someone explain who uses parallelism, for what, and in what context?

fiedzia 8y ago
Parallelism is large part of the answer to question of "how do we make this thing as fast as hardware allows" (most people will add "easily" to that). Or "as fast as our users demand" if it makes it easier to understand. The use for that comes with scale, there is a one caveat though: it is often impossible to add this as an afterthought to your program and to programming language. If you choose programming language (or architecture) that does it poorly, you are digging yourself a hole you won't be able to get out of. This is main reasons why it is important even for cases when you don't need it right now.
- projectramo 8y ago
  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.

fiedzia 8y ago

Parallelism is large part of the answer to question of "how do we make this thing as fast as hardware allows" (most people will add "easily" to that). Or "as fast as our users demand" if it makes it easier to understand. The use for that comes with scale, there is a one caveat though: it is often impossible to add this as an afterthought to your program and to programming language. If you choose programming language (or architecture) that does it poorly, you are digging yourself a hole you won't be able to get out of. This is main reasons why it is important even for cases when you don't need it right now.

projectramo 8y ago
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.