[webkit-dev] A Parallel Webkit?

[gao ying]

Hi Marchywka ,

Thanks for your comments about the paralle browser.:)

Your point is that exeucution can not benifit from multi-thread multi-core
for the following reasons:
1) Inter-thread compete
2) Cache thrashing (false sharing)
3) task offload overhead (BW limitation etc)

Generally, all these bullets are true for multi-thread workload whether or
not it is browser. Do you have any data for showing these worse in mobile
device?

1) Inter-thread compete
There are some solutions which can reduce the compete. For example, you can
select a suitable execution model (producer-consumer, Bulk synchronous
parallel) for a specific workload.
2) Cache thrashing (false sharing)
App has to take care of the memory locality and reduce the working set.
3) task offload overhead (BW limitation etc)
The task partitioner should offload the coarse task to device or accelator
for less communication overhead.

Thanks,
-Ying

2010/7/23 Mike Marchywka <marchywka at hotmail.com>

>
>
>
> I wasn't entirely sure what OP was after of if the reply below
> adequately addressed his interests. After looking at the link
> provided, I thought I would make a few comments that may or
> may not be of much benefit ( for discussion ) but that relate
> to observations on a few recent browsers on one series of mobile phones.
>
>
>
>
> ----------------------------------------
> > Date: Thu, 22 Jul 2010 22:20:34 +0200
> > From: abecsi at inf.u-szeged.hu
> > To: webkit-dev at lists.webkit.org
> > Subject: Re: [webkit-dev] A Parallel Webkit?
> >
> > Hi Ying,
> >
> > you might be looking for WebKit2, wich is a non-blocking API layer for
> > WebKit and aims to make WebKit more suitable for multicore systems. It
> > supports the split-process model and the thread model as well. The API
> > is currently under development for the Mac and Windows ports of WebKit
> > (Safari), and the Qt port also tries to keep pace with WebKit2
> > development, but currently lags behind the Mac and Win versions a bit.
> > There is a test browser called MiniBrowser, you can try it if you are
> > interested.
> >
> > You can find more information about WebKit2 at:
> > http://trac.webkit.org/wiki/WebKit2
> >
> > regards,
> > Andras
> >
> >
> > 2010-07-22 17:43 keltezéssel, gao ying írta:
> >> Hi,
> >>
> >> Is WebKit well parallel for fitting in multicore architecture? And any
> >> status for the parallel Webkit? The same idea is from
> >> http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/<http://www.eecs.berkeley.edu/%7Elmeyerov/projects/pbrowser/>
>
>
> 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).
> Many people rush to parallelism even with only one core or may try to
> use many cores and then they compete with each other, often thrashing
> memory
> caches or worse going to VM ( on smaller desktop computers like mine this
> is a problem).
> 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 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).
> 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.
>
> 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.
>
> 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 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.
>
> 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.
>
>
>
> >>
> >> 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/03fd64dd/attachment.html>