[webkit-dev] parallel rendering in WebKit

[Mike Marchywka]

----------------------------------------
> Date: Sat, 20 Feb 2010 12:22:02 +0100
> From: zherczeg at inf.u-szeged.hu
> To: mjs at apple.com
> CC: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] parallel rendering in WebKit
>
> Hi,
>
> thanks for all of your for your help.
>


>> I'm also curious how this will help overall rendering time. Embedded
>> platforms would normally only be displaying one document at a time, so
>> how will one thread per document help?
>
> Not anymore. The UI design of mobile or handheld devices use more and more
> html-based content. It is easier for both UI designers (enough to know how
> to create html pages) and developers (a browser is needed anyway, and not
> need to maintain a separate UI rendering engine). Of course we need
> reliable and fast brower engines to achive these features.

( again, with 1Gb of memory right now even iceweasel is lighting up my disk
as i try to type in this simple form LOL but not nearly as bad as firefox on a 500M laptop).
 We have a phone app that has a bunch of pieces made from html with various 
fake links to point to internal resources and variables. It is easy to write the html but speed is certainly an issue.
One part of this time delay seems to be start-up or initialization time and the few times
I've profiled this ( java ) I usually end up looking at calls to script compilers and stuff like that
but I'm not sure this unrelated thing would likely say much about webkit. You may alrady
have to initialize a lot of "Stuff" just to render a simple form with a few buttons and you
may be able to reduce that time to make it acceptable in more apps but it will always
be slower than using more direct components. 

Keep in mind that random initialization code to setup parallelism could be much slower than predictable
local access even if instruction counts ( and of course ignoring SIMD benefits ) are comparable due to memory architecture.

If you only have one CPU the likely benefits would be in things that amount to IO- 
and I guess that includes use of GPU or 
scheduling use of contsrained resources or something. Threading of course creates
a new class of resource, the lock or mutex, possibly  leading to "lock starvation" 
as many workers compete for one resource. The extreme case being each launched thread
holds the same lock for duration of execution thereby forcing them to execute serially
and you may even find this improves performance over less synchronized case even when
not needed for correctness. 

I guess offhand from what I've seen initialization and memory access patterns are often ignored components of performance
and there is a tendency to think that launching a thread creates a new CPU.



>
> I can't promise any major gain at this momment, but it seems there is not
> any design issue in WebKit, which makes this approach impossible. Wish us
> luck :)
>
> Regards,
> Zoltan
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/