4 ms·
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
by 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 agoArrays 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 agoYou 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.