[webkit-dev] A Parallel Webkit?

[Leo Meyerovich]

> I wasn't entirely sure what OP was after of if the reply below
> adequately addressed his interests.

WebKit2 seems to have little to do with taking advantage of parallel hardware in browser algorithms like lexing, parsing, selectors, JS compilation, JS execution, layout, DOM interactions, fonts, rendering, etc. There is some benefit: Sam King measured bucketing coarse tasks at the process isolation level gives maybe 10-20% better utilization of cores (a la Google Chrome or predecessors like the OP browser, Charles Reis's work, Gazelle, ...) on a good workload.  WebKit2's goal of supporting concurrency might be aimed at foundations for building parallelism into library code, such as further cleaning up threading API or introducing lightweight task parallelism, but the description doesn't talk about such things.

In contrast, we're interested in magnitudes of speedup. Parallelism --- memory parallelism (hw + sw prefetching to avoid cache misses), SIMD instructions, multiple cores, etc -- and even sequential stuff (smaller data representation, balancing incrementalization/memoization, etc.). Parallelization is already standard for traditional media libraries within browsers (e.g., GPUs & SSE for painting and rendering); for maybe a third of our work, we're just expanding the scope of what algorithms should be tuned kernels in the HPC sense.

> 
> I guess I would just make a few comments about your considerations and our experience.
> A somewhat different strategy than what you are proposing is to offload some tasks
> to a more capable device such as a server- simply tokenizing html or compiling
> JS can be a big benefit in phone CPU and bandwidth (aka time and battery life).

Opera mini is one stab at this, and the OnLive platform shows some of the potential here. However, this is for a limited deployment scenario and I'd actually argue against it from a power, energy, and latency perspective for handheld devices (... assuming you can get parallelization to work).


> You don't need to dig too deeply into the literature to find non monotonic graphs
> of execution time for some task vs number of cores ( more can make things slower).
> 


I agree -- it's tricky stuff. Worth keeping in mind handhelds will be in the multicore camp, not manycore, for awhile -- we're only now seeing dualcore ones: we don't need arbitrary strong scaling. Furthermore, frameworks like TBB are in a position to automate making the cutoff (which is actually non-obvious as you might want more threads than cores due to memory effects, hyperthreading, etc.). OTOH, for the processing style of browsers (sequences of little tasks), getting speedups isn't easy.


> I have seen this with transcoding and profiling on phone simulators- parsing
> and compiling is a great way to use time and create lots of objects ( and these
> in java have lots of overhead and many phones only let you use java but in any
> case we know that temp objects are not free in any case and fragment memory). 


I'm actually surprised a project like WebKit doesn't use, as far as I've been able to tell, many memory pooling etc. optimizations. We've been mindful of this stuff in our work -- it's fairly standard in the performance community.


> Another rate limiting step has been the round trip delay to housekeep a connection
> or do a DNS lookup. Here a proxy with persistent connections properly implemented
> is a much bigger issue than optimized rendering or well transcoded web pages AFAIK.
> 


Both the network and the CPU need work. For laptops, the network is typically the bottleneck, and only recently has that been shifting in the smart phone space. Worth noting, even on a fast network and local pages, profilers will show CPU bottlenecks.



> It may be worth considering making a standard compiled page type rather than
> worry about some of these other issues for example and cached compiled pages of course
> greatly reduce problems for everyone. 


That's great and actually complementary -- parallel serialization of machine-generated formats is preferable to formats like HTML5. A lot of problems lie under the surface here, however: introducing a proxy somewhere introduces latency, not getting benefits on dynamic component loading, etc. I actually view making in-browser algorithms faster as the conservative choice.

> 
> Its important to remember that most of these things involve tradeoffs and
> there are many resources to consider.
> 
> So, maybe you can make various arguments (" but with wifi IO doesn't matter "
> or " CPU's are only getting faster" or "memory is only getting cheaper" ) and
> battle out platittudes to defend a given approach


We have never said any of these things. Mobile browsers take too much time processing and the hardware is going parallel in multiple ways; we're just putting 1+1 together. 


> but I wouldn't just point to 
> one, like parallelism, and assume that will fix everything and indeed it can make things
> worse. Making things smaller in a way you don't need to undo ( say use winzip to download
> and then unzip the html only to compile it etc) is potentially a benefit in any situation
> as long as radio usage requires power.
> 

As is hopefully clear by now, our more prominent work is algorithm-centric where we're also taking the opportunity to perform other optimizations as well. You think a lot about representation, access patterns, etc. when doing (high performance) parallelization.


> An immediate concern I would point to in regard to multithreading on desktop
> and mobile is the need to keep a responsive UI thread- not sure if webkit has
> addressed this fully but I have seen this as a huge problem on my desktop, mobile,
> and my own mobile code that I ( carefully LOL) wrote myself. 
> 

That's an orthogonal concern modulo some tricky perceived response time issues.


Getting back to the original question of a parallel webkit, we have some collaborators looking at porting & improving some of our findings. I don't know anybody in the central WebKit community openly discussing this stuff but there is a lot of movement on the painting/rendering side of things (which we mostly assume doesn't need academic help).

- Leo


> 
> 
>>> 
>>> Thanks,
>>> -Ying
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 		 	   		  
> _________________________________________________________________
> Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100723/88dfca8e/attachment.html>