Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Fri, Apr 26, 2013 at 2:19 AM, Oneal Bluce wrote: > Hi Mikhail, > > Like what's you said, now WebCL have some serious security issues, we > also try to some approach to fix this issue or make the security issue in a > limited scope. such as we can use provide some high level parallelization > data structure , like what's done in RiverTrail . At the same time , we can > set a independent running environment for each web application or web site. > > Please refer to https://lists.webkit.org/pipermail/webkit-dev/2013-April/024747.html regarding WebCL security aspects discussion. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Auto-detecting scripts that are using ParallelArrays implicitly instead of adding a new type and making Web developers use it, this is a better way, this can reduce the difficulty of web developers. Cheers, Oneal From: Ryosuke Niwa To: "Pozdnyakov, Mikhail" Cc: "webkit-dev@lists.webkit.org" ; Benjamin Poulain Sent: Wednesday, April 10, 2013 5:38 PM Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Wed, Apr 10, 2013 at 2:29 AM, Pozdnyakov, Mikhail wrote: > >> Why not infer ParallelArrays automatically? >Sorry, did not get it. Could you please elaborate? > >I'm not insisting on this concrete proposal, my point is just that it would be >more safe and natural to enhance >ECMAScript (enable parallel calculations there) rather than make developers to >introduce OpenCL snippets to their web apps. > Filip is saying that we should be able to auto-detect scripts that are using ParallelArrays implicitly instead of adding a new type and making Web developers use it. i.e. if it quacks like a duck, then optimize it as a duck. And I completely agree with Filip on this. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi Imbert, what you said likes what's have done in Web Workers or RiverTrail is the correct way. Now we want to make full use of the hardware computation capability on various platform, such as thin client(mobile device), PC ..etc. because now the most of the hardwares have integrate the parallel processing unit. like intel's Ivy Bridge. AMD APU and provide a more better user experience, like the 3D game on mobile device base on the Web. Cheers, Oneal From: Thibault Imbert To: Oneal Bluce ; Benjamin Poulain Cc: "webkit-dev@lists.webkit.org" Sent: Wednesday, April 10, 2013 12:59 PM Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Hi Oneal, Yes, leveraging multicore and the power of GPUs for general computations is great and very powerful but first, securing such kernels is hard, and authoring these would be pretty brutal to most web developers, I think this is what Benjamin was referring to. With WebCL, you are basically writing C style kernels that you load and run to drive the computations, initiatives like RiverTrail are more restrictive but way more approachable and closer to the web, exposing higher level primitives on top of WebCL (ParallelArray for example) and integrated at the language level, which makes a lot of sense. You can also rely on Web Workers which are now broadly available, also abstracted through libraries like Parallel.js. You won't get shared memory, but improving data passing performance between workers may be a more interesting problem to solve in the short term, with lots of value to most developers. Thibault From: Oneal Bluce Reply-To: Oneal Bluce Date: Tuesday, April 9, 2013 8:39 PM To: Benjamin Poulain Cc: "webkit-dev@lists.webkit.org" Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Hi, Benjamin if browser have a capability to run some application with data-intensive parallel computing . some applications required data-intensive parallel computing can works on websit. such as 3D movie, 3D game... etc, this can give developer a way that developer don't care which devices the application will run, this can shorten the application development sycle, speedup the application deployment and reduce costs. maybe the browser will to be a runtime container which can provide a rumtime for those applications that have run on various OS. Cheers, Oneal From: Benjamin Poulain To: Oneal Bluce Cc: "webkit-dev@lists.webkit.org" Sent: Wednesday, April 10, 2013 1:47 AM Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Hi Oneal, On Tue, Apr 9, 2013 at 2:40 AM, Oneal Bluce wrote: Hello, I'm a researcher and I just focusing on the multi-process supporting and WebCL supporting in browser engin. so I have some concerns about the both features. >In recently, Google has pronounced that they will support the multi-process in >their browser egin(Blink) which is forked from the webkit. but Google will not >supporting the WebCL in Blink. so I just want to know is there a plan >supporting the multi-process and WebCL in webkit. I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges... Cheers, Benjamin___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi Mikhail, Like what's you said, now WebCL have some serious security issues, we also try to some approach to fix this issue or make the security issue in a limited scope. such as we can use provide some high level parallelization data structure , like what's done in RiverTrail . At the same time , we can set a independent running environment for each web application or web site. Cheers, Oneal From: "Pozdnyakov, Mikhail" To: Jer Noble ; Benjamin Poulain Cc: "webkit-dev@lists.webkit.org" Sent: Wednesday, April 10, 2013 3:16 PM Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Hi, As far as I'm concerned WebCL would have serious security issues as it lets web app to provide OpenCL target code (which is really unsafe), besides its using requires OpenCL knowledge and hence might be too complex for a web developer. Good alternative could be enabling parallel calculations inside ECMAScript itself. For instance providing ParallelArray interface for map-reduce calculations, there is actually a proposal already at http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism. BR, Mikhail From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Jer Noble [jer.no...@apple.com] Sent: Tuesday, April 09, 2013 11:23 PM To: Benjamin Poulain Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Apr 9, 2013, at 10:47 AM, Benjamin Poulain mailto:benja...@webkit.org>> wrote: I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges… There has also been interest in the WebAudio WG about using OpenCL/WebCL for custom audio processing. There are significant performance issues involved with doing custom audio processing in JavaScript, even in a Worker thread, but WebCL may offer performance and memory characteristics which would couple well with the requirements of realtime audio threads. -Jer - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi Gomes, Sorry for this late reply . for the "multi-process support" in my pre-email, I mean the Web/GPU processes implemented by the Chromium port (now on Blink). for the Web/UI process model provided by WebKit2, Can you give a more detail about the Web/UI process model. Cheers, Oneal From: Antonio Gomes To: Oneal Bluce ; Simon Gibbs - Samsung Cc: "webkit-dev@lists.webkit.org" Sent: Tuesday, April 9, 2013 10:26 PM Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Hi Oneal. As pointed out by Jesus, Samsung is working on a WebCL implementation for WebKit. https://github.com/SRA-SiliconValley/webkit-webcl is being our staging repo. As for your question, it is a bit unclear that if by "multi-process support" you are referring the Web/UI process model provided by WebKit2, or the Web/GPU processes implemented by the Chromium port (now on Blink). Our roadmap, which includes announcing the feature here on webkit-dev very soon, has WebKit2 based ports as a first target. As a secondary goal, Chromium (and its GPU-process architecture) would be targeted. Cheers, On Tue, Apr 9, 2013 at 5:40 AM, Oneal Bluce wrote: Hello, I'm a researcher and I just focusing on the multi-process supporting and WebCL supporting in browser engin. so I have some concerns about the both features. >In recently, Google has pronounced that they will support the multi-process in >their browser egin(Blink) which is forked from the webkit. but Google will not >supporting the WebCL in Blink. so I just want to know is there a plan >supporting the multi-process and WebCL in webkit. > > >Cheers, >Oneal >___ >webkit-dev mailing list >webkit-dev@lists.webkit.org >https://lists.webkit.org/mailman/listinfo/webkit-dev > >___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 11, 2013, at 2:30 PM, Dirk Pranke wrote: > On Wed, Apr 10, 2013 at 1:17 PM, Filip Pizlo 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Wed, Apr 10, 2013 at 1:17 PM, Filip Pizlo 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. > - 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. > > Hope my answers help! :-) > > Yes, thank you for expounding. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 1:03 PM, Dirk Pranke wrote:
> Right, you need some way to ensure that the functions applied to the array
> are "pure", the array doesn't mutate, etc. I thought perhaps your
> ParallelArray() type would be ensuring this (e.g., by enforcing type checking
> and freezing the array), but maybe I misunderstood you?
Ah - this is the key thing. ParallelArray requires the runtime and compiler to:
- Ensure that the closure passed to it is pure enough to parallelize (formally,
no loop-carried side-effects). If you already have the compiler do this
analysis then we might as well do it for any call to forEach().
- You're right that in one of the versions of the ParallelArray proposal, they
make ParallelArray immutable. But this doesn't help much. We already infer
that things are immutable in JS engines. If immutability helped, then we could
just infer it automatically. It would just be another kind of array inference.
All of the major JS inference already do array inference, and
purity/immutability is a particularly simple property to infer. But I don't
actually think you really need to prove that the array doesn't *ever* change -
proving that the closure doesn't change the array in bad ways is all that is
necessary, and that is even easier to detect since it's a property of the
closure (or more broadly, the loop body) and not the array itself.
-F
> Even then, I'm not sure how easy ensuring the functions were pure would be.
>
> Plus there's the problem of figuring how best to parallelize the operations,
> which is also often non-trivial.
>
> -- Dirk
>
> On Wed, Apr 10, 2013 at 12:58 PM, Oliver Hunt wrote:
> I'm not sure what you mean here: a parallel array is simply an array of
> numbers; there is nothing "magic" about it.
>
> If we _really_ wanted to be blunt about it, we could simply say (in Array.map)
>
> if (length >= giant && function.isEasyPeasy() && everything in the array is a
> number)
>return doHardcoreMap();
>
> // carry on doing regular map
> ...
>
> Understand that the parallel APIs have to do all of this as well, the only
> thing they lose is the "is everything a number" check
>
> --Oliver
>
>
> On Apr 10, 2013, at 12:50 PM, Dirk Pranke wrote:
>
>> Right, I get how ParallelArrays would work. I was asking Filip how you might
>> infer that an array could be a ParallelArray.
>>
>> -- Dirk
>>
>> On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt wrote:
>> The parallel arrays apis aren't a magic "make my code parallel" wand.
>>
>> They don't make general code parallel, they simply provide a bunch of
>> functions like map, etc where if you restrict your list of language features
>> to a specific subset, they'll vectorise it.
>>
>> For instance
>>
>> ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
>>
>> would be vectorised
>>
>> ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
>>
>> wouldn't be.
>>
>> This isn't "solve autovectorisation", this is "we've been given a specific
>> operation to perform on each element of an array, parallelise it if
>> possible", and what's possible is arbitrarily limited, and require a
>> distinct type that isn't an array.
>>
>> --Oliver
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 1:15 PM, Filip Pizlo wrote: > > On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote: > >> >> >> >> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote: >> >> >> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail" >> wrote: >> >> > >> > >> >> Why not infer ParallelArrays automatically? >> > Sorry, did not get it. Could you please elaborate? >> >> Normal JS arrays. You use them with pure computation. Profiler notices this. >> And then the same things that you have in the ParallelArrays proposal now >> work except you don't need a new type. >> >> >> Compiler writers have been chasing this problem for 50 years, with (AFAIK) >> very limited success for languages that don't give you compile-time >> annotations to help you along. > > Lets demystify this a bit. It's easy to say "OMG they did things for 50 > years", and we're all guilty of saying things like this sometimes, but, it's > a bit more interesting to identify what these people did for those 50 years, > where they got, and what the remaining problems are. It is already possible > to autoparallelize loops, but there are challenges that remain that make it > impractical for "real code". The problems are with: > > A) Identifying loops that are candidates for sound parallelization. In > formal-speak they look for the lack of "loop-carried side-effects", i.e. > something you'd do in one iteration that would be visible in a subsequent > iteration - this represents a dependency that inhibits parallelization. But > if you prove that no loop-carried side-effects exist, then you're off to a > good start: you know that you could fork off some threads to run the loop's > body in parallel, and the program would still be guaranteed to get identical > results. (I'm oversimplifying a bit - if you tried to auto-parallelize a > loop in a program that already had threads, you'd be in a world of hurt from > a memory model standpoint - but we don't have that problem in JS because all > code in JS is semantically serial and so the parallelization you did wouldn't > interfere with existing uses of threads, since there aren't any.) > > B) Identifying loops that are candidates for profitable parallelization. > Spinning up a thread carries a fixed cost. If you find a loop with no > loop-carried side-effects, but that loop actually only executes for a short > time, parallelizing it will be a performance regression - and likely a steep > one at that. Finding which loops are profitable to parallelize is thought to > be a hard problem. The traditional attempts to solve it centered around > making threads cheaper (i.e. Cilk, CML, and similar), or having stronger > inference of profitability (I think this is what http://ciao-lang.org does), > or pushing parallelizability hints into the language (X10, OpenMP, and these > ParallelArrays). > > (A) is not a problem that is solved by ParallelArrays. ParallelArrays > guarantee sequential equivalence; i.e. ParallelArray.prototype.forEach() will > behave like Array.prototype.forEach() if the closure you pass it has the > equivalent of "loop-carried side-effects". Sorry, to clarify: ParallelArray.prototype.forEach() will _always_ behave identically to Array.prototype.forEach(), and it is only if the runtime/compiler separately proves that there aren't loop-carried side-effects, that you get parallelism. Otherwise you just get a slower and more bulky implementation of foreach(). > 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. If you can do the inference that > allows ParallelArrays.prototype.forEach() to soundly parallelize, then you > can do that inference for Array.prototype.forEach(), as well. I happen to > think that (A) is a big problem with ParallelArrays; I don't like it that > these guys are proposing a language construct called "ParallelArray" but then > secretly they will probably not parallelize a ton of code because the user > didn't realize that storing to a global variable shafts their inference for > side-effects. > > (B) is a problem that ParallelArrays attempt to solve. But here's what we > know about the different approaches to solving (B): > > - Making threads faster hasn't really worked. Cilk's threads are fast enough > that if you use them yourself, manually, you'll be really happy, sort of, > except that it sort of sometimes doesn't work like you'd expect because > you've got user-level scheduling - but the point is, they're not fast enough > that you could spin them up for _any_ loop in a program. You'd get a > regression if you did. > > - Stronger inference of profitability is a promising area, which isn't > adequately explored, IMO. The approaches with which I'm most familiar focus > too much on static inference. > > - Adding hints to the language results in p
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote: > > > > On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote: > > > On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail" > wrote: > > > > > > >> Why not infer ParallelArrays automatically? > > Sorry, did not get it. Could you please elaborate? > > Normal JS arrays. You use them with pure computation. Profiler notices this. > And then the same things that you have in the ParallelArrays proposal now > work except you don't need a new type. > > > Compiler writers have been chasing this problem for 50 years, with (AFAIK) > very limited success for languages that don't give you compile-time > annotations to help you along. Lets demystify this a bit. It's easy to say "OMG they did things for 50 years", and we're all guilty of saying things like this sometimes, but, it's a bit more interesting to identify what these people did for those 50 years, where they got, and what the remaining problems are. It is already possible to autoparallelize loops, but there are challenges that remain that make it impractical for "real code". The problems are with: A) Identifying loops that are candidates for sound parallelization. In formal-speak they look for the lack of "loop-carried side-effects", i.e. something you'd do in one iteration that would be visible in a subsequent iteration - this represents a dependency that inhibits parallelization. But if you prove that no loop-carried side-effects exist, then you're off to a good start: you know that you could fork off some threads to run the loop's body in parallel, and the program would still be guaranteed to get identical results. (I'm oversimplifying a bit - if you tried to auto-parallelize a loop in a program that already had threads, you'd be in a world of hurt from a memory model standpoint - but we don't have that problem in JS because all code in JS is semantically serial and so the parallelization you did wouldn't interfere with existing uses of threads, since there aren't any.) B) Identifying loops that are candidates for profitable parallelization. Spinning up a thread carries a fixed cost. If you find a loop with no loop-carried side-effects, but that loop actually only executes for a short time, parallelizing it will be a performance regression - and likely a steep one at that. Finding which loops are profitable to parallelize is thought to be a hard problem. The traditional attempts to solve it centered around making threads cheaper (i.e. Cilk, CML, and similar), or having stronger inference of profitability (I think this is what http://ciao-lang.org does), or pushing parallelizability hints into the language (X10, OpenMP, and these ParallelArrays). (A) is not a problem that is solved by ParallelArrays. ParallelArrays guarantee sequential equivalence; i.e. ParallelArray.prototype.forEach() will behave like Array.prototype.forEach() if the closure you pass it has the equivalent of "loop-carried side-effects". 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. If you can do the inference that allows ParallelArrays.prototype.forEach() to soundly parallelize, then you can do that inference for Array.prototype.forEach(), as well. I happen to think that (A) is a big problem with ParallelArrays; I don't like it that these guys are proposing a language construct called "ParallelArray" but then secretly they will probably not parallelize a ton of code because the user didn't realize that storing to a global variable shafts their inference for side-effects. (B) is a problem that ParallelArrays attempt to solve. But here's what we know about the different approaches to solving (B): - Making threads faster hasn't really worked. Cilk's threads are fast enough that if you use them yourself, manually, you'll be really happy, sort of, except that it sort of sometimes doesn't work like you'd expect because you've got user-level scheduling - but the point is, they're not fast enough that you could spin them up for _any_ loop in a program. You'd get a regression if you did. - Stronger inference of profitability is a promising area, which isn't adequately explored, IMO. The approaches with which I'm most familiar focus too much on static inference. - Adding hints to the language results in programming models that nobody uses. Have you ever used OpenMP? Probably not, and if you have, you probably wanted to puke all over yourself. It's a disgusting programming model. There's something offensive about writing what looks like a serial loop, and then adding decorations to it to "declare" to the compiler what are the set of things it could do to the loop. Eventually these declarations get so sophisticated that you realize that you made a poor life decision by using them - you could have been more product
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Right, you need some way to ensure that the functions applied to the array
are "pure", the array doesn't mutate, etc. I thought perhaps your
ParallelArray() type would be ensuring this (e.g., by enforcing type
checking and freezing the array), but maybe I misunderstood you? Even then,
I'm not sure how easy ensuring the functions were pure would be.
Plus there's the problem of figuring how best to parallelize the
operations, which is also often non-trivial.
-- Dirk
On Wed, Apr 10, 2013 at 12:58 PM, Oliver Hunt wrote:
> I'm not sure what you mean here: a parallel array is simply an array of
> numbers; there is nothing "magic" about it.
>
> If we _really_ wanted to be blunt about it, we could simply say (in
> Array.map)
>
>
> if (length >= giant && function.isEasyPeasy() && everything in the array
> is a number)
>return doHardcoreMap();
>
> // carry on doing regular map
> ...
>
>
> Understand that the parallel APIs have to do all of this as well, the only
> thing they lose is the "is everything a number" check
>
> --Oliver
>
>
> On Apr 10, 2013, at 12:50 PM, Dirk Pranke wrote:
>
> Right, I get how ParallelArrays would work. I was asking Filip how you
> might infer that an array could be a ParallelArray.
>
> -- Dirk
>
> On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt wrote:
>
>> The parallel arrays apis aren't a magic "make my code parallel" wand.
>>
>> They don't make general code parallel, they simply provide a bunch of
>> functions like map, etc where if you restrict your list of language
>> features to a specific subset, they'll vectorise it.
>>
>> For instance
>>
>> ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
>>
>> would be vectorised
>>
>> ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
>>
>> wouldn't be.
>>
>> This isn't "solve autovectorisation", this is "we've been given a
>> specific operation to perform on each element of an array, parallelise it
>> if possible", and what's possible is arbitrarily limited, and require a
>> distinct type that isn't an array.
>>
>> --Oliver
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
I'm not sure what you mean here: a parallel array is simply an array of
numbers; there is nothing "magic" about it.
If we _really_ wanted to be blunt about it, we could simply say (in Array.map)
if (length >= giant && function.isEasyPeasy() && everything in the array is a
number)
return doHardcoreMap();
// carry on doing regular map
...
Understand that the parallel APIs have to do all of this as well, the only
thing they lose is the "is everything a number" check
--Oliver
On Apr 10, 2013, at 12:50 PM, Dirk Pranke wrote:
> Right, I get how ParallelArrays would work. I was asking Filip how you might
> infer that an array could be a ParallelArray.
>
> -- Dirk
>
> On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt wrote:
> The parallel arrays apis aren't a magic "make my code parallel" wand.
>
> They don't make general code parallel, they simply provide a bunch of
> functions like map, etc where if you restrict your list of language features
> to a specific subset, they'll vectorise it.
>
> For instance
>
> ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
>
> would be vectorised
>
> ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
>
> wouldn't be.
>
> This isn't "solve autovectorisation", this is "we've been given a specific
> operation to perform on each element of an array, parallelise it if
> possible", and what's possible is arbitrarily limited, and require a distinct
> type that isn't an array.
>
> --Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Right, I get how ParallelArrays would work. I was asking Filip how you
might infer that an array could be a ParallelArray.
-- Dirk
On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt wrote:
> The parallel arrays apis aren't a magic "make my code parallel" wand.
>
> They don't make general code parallel, they simply provide a bunch of
> functions like map, etc where if you restrict your list of language
> features to a specific subset, they'll vectorise it.
>
> For instance
>
> ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
>
> would be vectorised
>
> ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
>
> wouldn't be.
>
> This isn't "solve autovectorisation", this is "we've been given a specific
> operation to perform on each element of an array, parallelise it if
> possible", and what's possible is arbitrarily limited, and require a
> distinct type that isn't an array.
>
> --Oliver
>
> On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote:
>
>
>
>
> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote:
>
>>
>>
>> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail" <
>> mikhail.pozdnya...@intel.com> wrote:
>>
>> >
>> >
>> >> Why not infer ParallelArrays automatically?
>> > Sorry, did not get it. Could you please elaborate?
>>
>> Normal JS arrays. You use them with pure computation. Profiler notices
>> this. And then the same things that you have in the ParallelArrays proposal
>> now work except you don't need a new type.
>>
>>
> Compiler writers have been chasing this problem for 50 years, with (AFAIK)
> very limited success for languages that don't give you compile-time
> annotations to help you along. I'm not aware of any work on JIT compilers
> doing this. Why do you think we could do better? (Honest question, I'm not
> trying to be snarky, nor am I an expert).
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
The parallel arrays apis aren't a magic "make my code parallel" wand.
They don't make general code parallel, they simply provide a bunch of functions
like map, etc where if you restrict your list of language features to a
specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
would be vectorised
ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
wouldn't be.
This isn't "solve autovectorisation", this is "we've been given a specific
operation to perform on each element of an array, parallelise it if possible",
and what's possible is arbitrarily limited, and require a distinct type that
isn't an array.
--Oliver
On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote:
>
>
>
> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote:
>
>
> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail"
> wrote:
>
> >
> >
> >> Why not infer ParallelArrays automatically?
> > Sorry, did not get it. Could you please elaborate?
>
> Normal JS arrays. You use them with pure computation. Profiler notices this.
> And then the same things that you have in the ParallelArrays proposal now
> work except you don't need a new type.
>
>
> Compiler writers have been chasing this problem for 50 years, with (AFAIK)
> very limited success for languages that don't give you compile-time
> annotations to help you along. I'm not aware of any work on JIT compilers
> doing this. Why do you think we could do better? (Honest question, I'm not
> trying to be snarky, nor am I an expert).
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote: > > > On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail" < > mikhail.pozdnya...@intel.com> wrote: > > > > > > >> Why not infer ParallelArrays automatically? > > Sorry, did not get it. Could you please elaborate? > > Normal JS arrays. You use them with pure computation. Profiler notices > this. And then the same things that you have in the ParallelArrays proposal > now work except you don't need a new type. > > Compiler writers have been chasing this problem for 50 years, with (AFAIK) very limited success for languages that don't give you compile-time annotations to help you along. I'm not aware of any work on JIT compilers doing this. Why do you think we could do better? (Honest question, I'm not trying to be snarky, nor am I an expert). ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 9:44 AM, Jarred Nicholls wrote: > On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes wrote: > Hi > > On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert wrote: > > Yes, leveraging multicore and the power of GPUs for general computations is > great and very powerful but first, securing such kernels is hard, and > authoring these would be pretty brutal to most web developers, I think this > is what Benjamin was referring to. > > With WebCL, you are basically writing C style kernels that you load and run > to drive the computations, initiatives like RiverTrail are more restrictive > but way more approachable and closer to the web, exposing higher level > primitives on top of WebCL (ParallelArray for example) and integrated at the > language level, which makes a lot of sense. > > > Security is a primary goal of WebCL, and both WebCL and OpenCL working groups > are working together to ensure a safe parallel programming environment to the > Web, as you can see in [1]. If you have specific concerns, please raise it in > the Khronos working group mailing list ([2]) or file a bug ([3]) against the > draft spec. > > Particularly in terms of security, WebCL is to OpenCL as WebGL is to OpenGL. > Introducing "OpenGL" (i.e. WebGL) to the web had similar security concerns, > and yet… OpenCL is fundamentally less safe than OpenGL+GLSL, so it not correct to say that the security concerns are similar. There is no part of GLSL that is overtly operating on raw memory with arbitrary pointer access, whereas in OpenCL such functionality is a core primitive. I am not saying that it will be impossible to make WebCL safe (after all OpenCL can trivially be kept on the cpu, which already has the assumption that it is running untrusted code), but whether you can keep it safe without completely compromising the programming and performance model remains to be seen. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes wrote: > Hi > > On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert wrote: > >> >> Yes, leveraging multicore and the power of GPUs for general computations >> is great and very powerful but first, securing such kernels is hard, and >> authoring these would be pretty brutal to most web developers, I think this >> is what Benjamin was referring to. >> >> With WebCL, you are basically writing C style kernels that you load and >> run to drive the computations, initiatives like RiverTrail are more >> restrictive but way more approachable and closer to the web, exposing >> higher level primitives on top of WebCL (ParallelArray for example) and >> integrated at the language level, which makes a lot of sense. >> >> > Security is a primary goal of WebCL, and both WebCL and OpenCL working > groups are working together to ensure a safe parallel programming > environment to the Web, as you can see in [1]. If you have specific > concerns, please raise it in the Khronos working group mailing list ([2]) > or file a bug ([3]) against the draft spec. > Particularly in terms of security, WebCL is to OpenCL as WebGL is to OpenGL. Introducing "OpenGL" (i.e. WebGL) to the web had similar security concerns, and yet... With that said, I totally agree that using intrinsic idioms and heuristics that is more "webby" would be nice. But at some point there will be use cases that do not translate and will require explicit developer control in one form (WebCL) or another (new ECMAScript idioms). Detecting and optimizing all variations of homogenous parallelable operations seamlessly inside the JS engine is hard, to put it mildly. > > [1] > https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html#4 > [2] http://www.khronos.org/webcl/public-mailing-list/ > [3] https://www.khronos.org/bugzilla/enter_bug.cgi?product=WebCL > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail" wrote: > > >> Why not infer ParallelArrays automatically? > Sorry, did not get it. Could you please elaborate? Normal JS arrays. You use them with pure computation. Profiler notices this. And then the same things that you have in the ParallelArrays proposal now work except you don't need a new type. > > I'm not insisting on this concrete proposal, my point is just that it would > be more safe and natural to enhance > ECMAScript (enable parallel calculations there) rather than make developers > to introduce OpenCL snippets to their web apps. It's even more natural to not add yet another array type to ECMAScript. -F > > BR, > Mikhail > > > From: Filip Pizlo [fpi...@apple.com] > Sent: Wednesday, April 10, 2013 10:37 AM > To: Pozdnyakov, Mikhail > Cc: Jer Noble; Benjamin Poulain; webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and > WebCL in webkit > > Why not infer ParallelArrays automatically? What is the specific reason for > requiring a new type? > > -Filip > > > On Apr 10, 2013, at 12:16 AM, "Pozdnyakov, Mikhail" > mailto:mikhail.pozdnya...@intel.com>> wrote: > > Hi, > > As far as I'm concerned WebCL would have serious security issues as it lets > web app to provide OpenCL target code (which is really unsafe), > besides its using requires OpenCL knowledge and hence might be too complex > for a web developer. > Good alternative could be enabling parallel calculations inside ECMAScript > itself. For instance providing ParallelArray interface for map-reduce > calculations, there is actually a proposal already at > http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism . > > BR, > Mikhail > > > From: > webkit-dev-boun...@lists.webkit.org<mailto:webkit-dev-boun...@lists.webkit.org> > > [webkit-dev-boun...@lists.webkit.org<mailto:webkit-dev-boun...@lists.webkit.org>] > on behalf of Jer Noble [jer.no...@apple.com<mailto:jer.no...@apple.com>] > Sent: Tuesday, April 09, 2013 11:23 PM > To: Benjamin Poulain > Cc: webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> > Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and > WebCL in webkit > > On Apr 9, 2013, at 10:47 AM, Benjamin Poulain > mailto:benja...@webkit.org><mailto:benja...@webkit.org>> > wrote: > > I am very curious about the source of interest in OpenCL on browser. While > OpenCL is a great technology, I have the feeling it is not ready for the web. > What kind of applications do you foresee being powered by OpenCL on the Web? > > I can imagine some use of CPU based kernels for the web (for image > manipulation for example). But I have a hard time seeing how adding full > support of OpenCL would not be shooting ourself in the foot at this point. > That may change in the future when GPU hardware converges… > > There has also been interest in the WebAudio WG about using OpenCL/WebCL for > custom audio processing. There are significant performance issues involved > with doing custom audio processing in JavaScript, even in a Worker thread, > but WebCL may offer performance and memory characteristics which would couple > well with the requirements of realtime audio threads. > > -Jer > > - > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev > > - > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert wrote: > > Yes, leveraging multicore and the power of GPUs for general computations > is great and very powerful but first, securing such kernels is hard, and > authoring these would be pretty brutal to most web developers, I think this > is what Benjamin was referring to. > > With WebCL, you are basically writing C style kernels that you load and > run to drive the computations, initiatives like RiverTrail are more > restrictive but way more approachable and closer to the web, exposing > higher level primitives on top of WebCL (ParallelArray for example) and > integrated at the language level, which makes a lot of sense. > > Security is a primary goal of WebCL, and both WebCL and OpenCL working groups are working together to ensure a safe parallel programming environment to the Web, as you can see in [1]. If you have specific concerns, please raise it in the Khronos working group mailing list ([2]) or file a bug ([3]) against the draft spec. [1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html#4 [2] http://www.khronos.org/webcl/public-mailing-list/ [3] https://www.khronos.org/bugzilla/enter_bug.cgi?product=WebCL ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Thanks for clarification. I also agree that this is better :-) BR, Mikhail From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Wednesday, April 10, 2013 12:38 PM To: Pozdnyakov, Mikhail Cc: Filip Pizlo; Benjamin Poulain; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Wed, Apr 10, 2013 at 2:29 AM, Pozdnyakov, Mikhail mailto:mikhail.pozdnya...@intel.com>> wrote: > Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? I'm not insisting on this concrete proposal, my point is just that it would be more safe and natural to enhance ECMAScript (enable parallel calculations there) rather than make developers to introduce OpenCL snippets to their web apps. Filip is saying that we should be able to auto-detect scripts that are using ParallelArrays implicitly instead of adding a new type and making Web developers use it. i.e. if it quacks like a duck, then optimize it as a duck. And I completely agree with Filip on this. - R. Niwa - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Wed, Apr 10, 2013 at 2:29 AM, Pozdnyakov, Mikhail < mikhail.pozdnya...@intel.com> wrote: > > > > Why not infer ParallelArrays automatically? > Sorry, did not get it. Could you please elaborate? > > I'm not insisting on this concrete proposal, my point is just that it > would be more safe and natural to enhance > ECMAScript (enable parallel calculations there) rather than make > developers to introduce OpenCL snippets to their web apps. > Filip is saying that we should be able to auto-detect scripts that are using ParallelArrays implicitly instead of adding a new type and making Web developers use it. i.e. if it quacks like a duck, then optimize it as a duck. And I completely agree with Filip on this. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
> Why not infer ParallelArrays automatically? Sorry, did not get it. Could you please elaborate? I'm not insisting on this concrete proposal, my point is just that it would be more safe and natural to enhance ECMAScript (enable parallel calculations there) rather than make developers to introduce OpenCL snippets to their web apps. BR, Mikhail From: Filip Pizlo [fpi...@apple.com] Sent: Wednesday, April 10, 2013 10:37 AM To: Pozdnyakov, Mikhail Cc: Jer Noble; Benjamin Poulain; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Why not infer ParallelArrays automatically? What is the specific reason for requiring a new type? -Filip On Apr 10, 2013, at 12:16 AM, "Pozdnyakov, Mikhail" mailto:mikhail.pozdnya...@intel.com>> wrote: Hi, As far as I'm concerned WebCL would have serious security issues as it lets web app to provide OpenCL target code (which is really unsafe), besides its using requires OpenCL knowledge and hence might be too complex for a web developer. Good alternative could be enabling parallel calculations inside ECMAScript itself. For instance providing ParallelArray interface for map-reduce calculations, there is actually a proposal already at http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism . BR, Mikhail From: webkit-dev-boun...@lists.webkit.org<mailto:webkit-dev-boun...@lists.webkit.org> [webkit-dev-boun...@lists.webkit.org<mailto:webkit-dev-boun...@lists.webkit.org>] on behalf of Jer Noble [jer.no...@apple.com<mailto:jer.no...@apple.com>] Sent: Tuesday, April 09, 2013 11:23 PM To: Benjamin Poulain Cc: webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Apr 9, 2013, at 10:47 AM, Benjamin Poulain mailto:benja...@webkit.org><mailto:benja...@webkit.org>> wrote: I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges… There has also been interest in the WebAudio WG about using OpenCL/WebCL for custom audio processing. There are significant performance issues involved with doing custom audio processing in JavaScript, even in a Worker thread, but WebCL may offer performance and memory characteristics which would couple well with the requirements of realtime audio threads. -Jer - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Why not infer ParallelArrays automatically? What is the specific reason for requiring a new type? -Filip On Apr 10, 2013, at 12:16 AM, "Pozdnyakov, Mikhail" wrote: > Hi, > > As far as I'm concerned WebCL would have serious security issues as it lets > web app to provide OpenCL target code (which is really unsafe), > besides its using requires OpenCL knowledge and hence might be too complex > for a web developer. > Good alternative could be enabling parallel calculations inside ECMAScript > itself. For instance providing ParallelArray interface for map-reduce > calculations, there is actually a proposal already at > http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism . > > BR, > Mikhail > > > From: webkit-dev-boun...@lists.webkit.org > [webkit-dev-boun...@lists.webkit.org] on behalf of Jer Noble > [jer.no...@apple.com] > Sent: Tuesday, April 09, 2013 11:23 PM > To: Benjamin Poulain > Cc: webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and > WebCL in webkit > > On Apr 9, 2013, at 10:47 AM, Benjamin Poulain > mailto:benja...@webkit.org>> wrote: > > I am very curious about the source of interest in OpenCL on browser. While > OpenCL is a great technology, I have the feeling it is not ready for the web. > What kind of applications do you foresee being powered by OpenCL on the Web? > > I can imagine some use of CPU based kernels for the web (for image > manipulation for example). But I have a hard time seeing how adding full > support of OpenCL would not be shooting ourself in the foot at this point. > That may change in the future when GPU hardware converges… > > There has also been interest in the WebAudio WG about using OpenCL/WebCL for > custom audio processing. There are significant performance issues involved > with doing custom audio processing in JavaScript, even in a Worker thread, > but WebCL may offer performance and memory characteristics which would couple > well with the requirements of realtime audio threads. > > -Jer > > - > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi, As far as I'm concerned WebCL would have serious security issues as it lets web app to provide OpenCL target code (which is really unsafe), besides its using requires OpenCL knowledge and hence might be too complex for a web developer. Good alternative could be enabling parallel calculations inside ECMAScript itself. For instance providing ParallelArray interface for map-reduce calculations, there is actually a proposal already at http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism . BR, Mikhail From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Jer Noble [jer.no...@apple.com] Sent: Tuesday, April 09, 2013 11:23 PM To: Benjamin Poulain Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit On Apr 9, 2013, at 10:47 AM, Benjamin Poulain mailto:benja...@webkit.org>> wrote: I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges… There has also been interest in the WebAudio WG about using OpenCL/WebCL for custom audio processing. There are significant performance issues involved with doing custom audio processing in JavaScript, even in a Worker thread, but WebCL may offer performance and memory characteristics which would couple well with the requirements of realtime audio threads. -Jer - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi Oneal, Yes, leveraging multicore and the power of GPUs for general computations is great and very powerful but first, securing such kernels is hard, and authoring these would be pretty brutal to most web developers, I think this is what Benjamin was referring to. With WebCL, you are basically writing C style kernels that you load and run to drive the computations, initiatives like RiverTrail are more restrictive but way more approachable and closer to the web, exposing higher level primitives on top of WebCL (ParallelArray for example) and integrated at the language level, which makes a lot of sense. You can also rely on Web Workers which are now broadly available, also abstracted through libraries like Parallel.js. You won't get shared memory, but improving data passing performance between workers may be a more interesting problem to solve in the short term, with lots of value to most developers. Thibault From: Oneal Bluce mailto:onealbl...@yahoo.com>> Reply-To: Oneal Bluce mailto:onealbl...@yahoo.com>> Date: Tuesday, April 9, 2013 8:39 PM To: Benjamin Poulain mailto:benja...@webkit.org>> Cc: "webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>" mailto:webkit-dev@lists.webkit.org>> Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Hi, Benjamin if browser have a capability to run some application with data-intensive parallel computing . some applications required data-intensive parallel computing can works on websit. such as 3D movie, 3D game... etc, this can give developer a way that developer don't care which devices the application will run, this can shorten the application development sycle, speedup the application deployment and reduce costs. maybe the browser will to be a runtime container which can provide a rumtime for those applications that have run on various OS. Cheers, Oneal From: Benjamin Poulain mailto:benja...@webkit.org>> To: Oneal Bluce mailto:onealbl...@yahoo.com>> Cc: "webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>" mailto:webkit-dev@lists.webkit.org>> Sent: Wednesday, April 10, 2013 1:47 AM Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Hi Oneal, On Tue, Apr 9, 2013 at 2:40 AM, Oneal Bluce mailto:onealbl...@yahoo.com>> wrote: Hello, I'm a researcher and I just focusing on the multi-process supporting and WebCL supporting in browser engin. so I have some concerns about the both features. In recently, Google has pronounced that they will support the multi-process in their browser egin(Blink) which is forked from the webkit. but Google will not supporting the WebCL in Blink. so I just want to know is there a plan supporting the multi-process and WebCL in webkit. I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges... Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi, Benjamin if browser have a capability to run some application with data-intensive parallel computing . some applications required data-intensive parallel computing can works on websit. such as 3D movie, 3D game... etc, this can give developer a way that developer don't care which devices the application will run, this can shorten the application development sycle, speedup the application deployment and reduce costs. maybe the browser will to be a runtime container which can provide a rumtime for those applications that have run on various OS. Cheers, Oneal From: Benjamin Poulain To: Oneal Bluce Cc: "webkit-dev@lists.webkit.org" Sent: Wednesday, April 10, 2013 1:47 AM Subject: Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit Hi Oneal, On Tue, Apr 9, 2013 at 2:40 AM, Oneal Bluce wrote: Hello, I'm a researcher and I just focusing on the multi-process supporting and WebCL supporting in browser engin. so I have some concerns about the both features. >In recently, Google has pronounced that they will support the multi-process in >their browser egin(Blink) which is forked from the webkit. but Google will not >supporting the WebCL in Blink. so I just want to know is there a plan >supporting the multi-process and WebCL in webkit. I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges... Cheers, Benjamin___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 9, 2013, at 10:47 AM, Benjamin Poulain wrote: > I am very curious about the source of interest in OpenCL on browser. While > OpenCL is a great technology, I have the feeling it is not ready for the web. > What kind of applications do you foresee being powered by OpenCL on the Web? > > I can imagine some use of CPU based kernels for the web (for image > manipulation for example). But I have a hard time seeing how adding full > support of OpenCL would not be shooting ourself in the foot at this point. > That may change in the future when GPU hardware converges… There has also been interest in the WebAudio WG about using OpenCL/WebCL for custom audio processing. There are significant performance issues involved with doing custom audio processing in JavaScript, even in a Worker thread, but WebCL may offer performance and memory characteristics which would couple well with the requirements of realtime audio threads. -Jer ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi Oneal, On Tue, Apr 9, 2013 at 2:40 AM, Oneal Bluce wrote: > Hello, I'm a researcher and I just focusing on the multi-process > supporting and WebCL supporting in browser engin. so I have some concerns > about the both features. > In recently, Google has pronounced that they will support the > multi-process in their browser egin(Blink) which is forked from the webkit. > but Google will not supporting the WebCL in Blink. so I just want to know > is there a plan supporting the multi-process and WebCL in webkit. > I am very curious about the source of interest in OpenCL on browser. While OpenCL is a great technology, I have the feeling it is not ready for the web. What kind of applications do you foresee being powered by OpenCL on the Web? I can imagine some use of CPU based kernels for the web (for image manipulation for example). But I have a hard time seeing how adding full support of OpenCL would not be shooting ourself in the foot at this point. That may change in the future when GPU hardware converges... Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi Oneal. As pointed out by Jesus, Samsung is working on a WebCL implementation for WebKit. https://github.com/SRA-SiliconValley/webkit-webcl is being our staging repo. As for your question, it is a bit unclear that if by "multi-process support" you are referring the Web/UI process model provided by WebKit2, or the Web/GPU processes implemented by the Chromium port (now on Blink). Our roadmap, which includes announcing the feature here on webkit-dev very soon, has WebKit2 based ports as a first target. As a secondary goal, Chromium (and its GPU-process architecture) would be targeted. Cheers, On Tue, Apr 9, 2013 at 5:40 AM, Oneal Bluce wrote: > Hello, I'm a researcher and I just focusing on the multi-process > supporting and WebCL supporting in browser engin. so I have some concerns > about the both features. > In recently, Google has pronounced that they will support the > multi-process in their browser egin(Blink) which is forked from the webkit. > but Google will not supporting the WebCL in Blink. so I just want to know > is there a plan supporting the multi-process and WebCL in webkit. > > > Cheers, > Oneal > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi. Correct WebCL link is https://github.com/SRA-SiliconValley/webkit-webcl . Cheers, On Tue, Apr 9, 2013 at 8:01 AM, Jesus Sanchez-Palencia wrote: > Hi, > > WebKit already support a split process model which is what we call WebKit2 > [1]. > I'm not aware of any official plans of supporting WebCL but I believe > Samsung was doing some research on this [2]. > > [1] http://trac.webkit.org/wiki/WebKit2 > [2] https://code.google.com/p/webcl/ > > Cheers, > jesus > > > 2013/4/9 Oneal Bluce : > > Hello, I'm a researcher and I just focusing on the multi-process > supporting > > and WebCL supporting in browser engin. so I have some concerns about the > > both features. > > In recently, Google has pronounced that they will support the > multi-process > > in their browser egin(Blink) which is forked from the webkit. but Google > > will not supporting the WebCL in Blink. so I just want to know is there > a > > plan supporting the multi-process and WebCL in webkit. > > > > > > Cheers, > > Oneal > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hi, WebKit already support a split process model which is what we call WebKit2 [1]. I'm not aware of any official plans of supporting WebCL but I believe Samsung was doing some research on this [2]. [1] http://trac.webkit.org/wiki/WebKit2 [2] https://code.google.com/p/webcl/ Cheers, jesus 2013/4/9 Oneal Bluce : > Hello, I'm a researcher and I just focusing on the multi-process supporting > and WebCL supporting in browser engin. so I have some concerns about the > both features. > In recently, Google has pronounced that they will support the multi-process > in their browser egin(Blink) which is forked from the webkit. but Google > will not supporting the WebCL in Blink. so I just want to know is there a > plan supporting the multi-process and WebCL in webkit. > > > Cheers, > Oneal > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
Hello, I'm a researcher and I just focusing on the multi-process supporting and WebCL supporting in browser engin. so I have some concerns about the both features. In recently, Google has pronounced that they will support the multi-process in their browser egin(Blink) which is forked from the webkit. but Google will not supporting the WebCL in Blink. so I just want to know is there a plan supporting the multi-process and WebCL in webkit. Cheers, Oneal___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
