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: abe...@inf.u-szeged.hu
> To: webkit-dev@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/
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@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
