3 ms·

> I've always thought that the next truly big leap in VMs and languages will be those that can do smart things with threading without making developers sweat to

> I've always thought that the next truly big leap in VMs and languages will be those that can do smart things with threading without making developers sweat too much. I'm skeptical we'll see something like this for _nontrivial_ applications, especially highly tuned applications (search, financial, etc). I think we will have examples of toy applications that can be automatically parallelized. Parallel Linq (plinq) is a good example. You can easily make course grained operation concurrent. However, for truly fine grained stuff, the compiler isn't "smart enough." (see On Being Sufficiently Smart - http://prog21.dadgum.com/40.html http://prog21.dadgum.com/40.html) I hope I'm wrong and we see some major advances in magic err I mean compiler design.

sausagefeet 15y ago
I'm wondering if the solution to the Sufficiently Smart Compiler is to have the Sufficiently Stupid Language. Automated parallelism becomes easier if you only give users parallelizable operators. That sounds terrible, but maybe it isn't that bad (I don't know). Perhaps users should always be working on sets of data (a number doesn't a exist, just a set with one number in it), then the compiler really just has to be smart enough to turn that set operator into just an operation on an integer. That is, deparallelize it. Is this why array languages tend to work well for these things?
- gauravk92 15y ago
  Arrays are usually causing problems in the parallelism world, if you're trying to modify them anyway. The standard paradigm is the actor model, you reduce your program to never actually talk to data, only act as if it were. The objects asynchronously handle messages to modify themselves, thus a message can come from anywhere. That's one solution but the biggest hurdle most parallel codes faces is the fact that most programmers think sequentially. When you start thinking parallel, it doesn't make as much sense, and the thought degrades to a magic box that you throw work at. IMHO usually because where parallelism is an intuitive concept, the API's to take advantage of it usually suck.
  - sausagefeet 15y ago
    You wouldn't have array mutation in this case, since that isn't a very parallelizable operation. My question is if we could construct a usable language where every operator in it is a parallel operator, in which point the optimizing compiler is trying to find situations where it can just treat values as sequential code, not finding situations where it can treat sequential code as parallelizable.

sausagefeet 15y ago

I'm wondering if the solution to the Sufficiently Smart Compiler is to have the Sufficiently Stupid Language. Automated parallelism becomes easier if you only give users parallelizable operators. That sounds terrible, but maybe it isn't that bad (I don't know). Perhaps users should always be working on sets of data (a number doesn't a exist, just a set with one number in it), then the compiler really just has to be smart enough to turn that set operator into just an operation on an integer. That is, deparallelize it. Is this why array languages tend to work well for these things?

gauravk92 15y ago
Arrays are usually causing problems in the parallelism world, if you're trying to modify them anyway. The standard paradigm is the actor model, you reduce your program to never actually talk to data, only act as if it were. The objects asynchronously handle messages to modify themselves, thus a message can come from anywhere. That's one solution but the biggest hurdle most parallel codes faces is the fact that most programmers think sequentially. When you start thinking parallel, it doesn't make as much sense, and the thought degrades to a magic box that you throw work at. IMHO usually because where parallelism is an intuitive concept, the API's to take advantage of it usually suck.
- sausagefeet 15y ago
  You wouldn't have array mutation in this case, since that isn't a very parallelizable operation. My question is if we could construct a usable language where every operator in it is a parallel operator, in which point the optimizing compiler is trying to find situations where it can just treat values as sequential code, not finding situations where it can treat sequential code as parallelizable.