[webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Filip Pizlo]

On Apr 11, 2013, at 2:30 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> On Wed, Apr 10, 2013 at 1:17 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> I.e. if you believe that (A) is not a solvable problem, then this constitutes an argument against ParallelArrays, and not against inferring that a normal array should behave like a ParallelArray.
> 
> I believe that there are a class of solvable problems for soundness, but it's hard if not impossible to do it generally; that was my main concern. There are certainly languages that make this problem easier, for example (Haskell, J). I agree that the JIT+runtime bailout strategy you discuss gives you more options here.

You're totally right, generality here is super hard.  That's why I'm skeptical of ParallelArrays; they don't help in solving that particular problem.

>  
>> - Adding hints to the language results in programming models that nobody uses.  Have you ever used OpenMP?
> 
> I'm familiar enough with it. I was referring to things more like "restrict", "const", and "pure" which give you (or the compiler) more guarantees about what it is safe to infer about the parameters and functions. I'm not sure these are the same sorts of things you don't like.

I like all of those things, and believe that I could infer them in a JIT!  We already infer "const" for global variables and object properties that point to functions, since it's crucial for making method dispatch fast.  No reason why we couldn't do it for other properties or variables.  We just don't, yet, because it hasn't felt super important.  But if you have some JS code that would benefit from it, you should file a bug! :-)

"Pure" is not something that we infer now, but the ParallelArray work does infer it, the stupid way: write barrier that deoptimizes.  You don't need a special "ParallelArray" type to do that for closures passed to forEach(); it's an orthogonal thing.  We could get super crazy with this if we wanted to.  There's a lot of work on transactional memory barriers that can infer purity very easily; so if the single most important thing for the web platform was writing parallel numerical kernels (lmao yeah right!) then this would probably be doable.

"Restrict" is a fun one.  Points-to analysis all of the things!  I did this once in a JVM, and have seen others do it, also.  It can work.  It's an expensive thing to do, but if we had benchmarks that did benefit from it, then I see no reason why not.  As an aside, aliasing in JavaScript is already easier to figure out than in C - once our type inference is done we will know that for example an access to a property called "foo" cannot alias an access to a property called "bar" by virtue of the fact that simple self-properties cannot overlap.  In C a thing called "foo" and a thing called "bar" can totally overlap and so you need annotations like "restrict" to help deconfuse the poor compiler.


>> 
>> Hope my answers help! :-)
>> 
> 
> Yes, thank you for expounding.
> 
> -- Dirk 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130411/587c4dae/attachment.html>