> 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@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
