[webkit-dev] parallel rendering in WebKit

[Mike Marchywka]

----------------------------------------
> Date: Fri, 19 Feb 2010 23:36:26 +0100
> From: zherczeg at inf.u-szeged.hu
> To: webkit-dev at lists.webkit.org
> Subject: [webkit-dev] parallel rendering in WebKit
>
> Hi,
>
> as all of you probably know, smp based systems are getting widespread even
> in the embedded domain, and we hope we can speed up webkit on these
> systems. We did some profiling, and seemed the platform dependent
> rendering took 50% of the total runtime (at least on our test platforms).
> We are thinking about adding some parallel rendering support for WebKit,
> probably mostly platform dependent code, but the threading support could
> be reused by different ports.
>
> The plan is opening a rendering thread for each document object. This
> thread is dedicated to rendering, the resource management is still done by
> the main thread. In other words, functions like drawRect (in
> GraphicsContext.h) creates a small object, which contains the arguments of
> the called function, and passing this object to the thread. The thread
> would do the painting, and send back the object after it is processed. The
> main thread can free the memory space of the object later, and dereference
> the resources (we hope resources like fonts and images are not need to be
> duplicated).
>
> This is still a vague idea, and we are still investigating the
> possibilities. What is your opinion? Do you know about any major blockers
> we should know about?


I'm new to webkit and haven't looked at details of browsers much but I would
suggest that you at least identify some bottlenecks more specifically and
get some idea how you expect to benefit. Certainly with one core you would
have to be skeptical but even with multi cpu's you can end up slowing things
down pretty quickly based on some graphs I've seen of "what can happen."
Obviously, if you are waiting for IO doing something on another thread
may be a good idea but offhand I'd start trying to make coding or algorithmic
changes and see if anything specific emerges while doing that that suggests
a way to multi-thread. 

If you really are limited by some CPU intensive tasks and have a hierarchial
memory you can end up doing more harm cache thrashing than anything else.
In fact, you may be better off making sure any such algorighms are cache
aware and retain memory locality etc before just throwing more threads
at the thing. If you have inner loops that can be optimized or reordered
to get better locaclity that can be a big issue. 

I would also point out personally I am tired of  seeing my disk light come on in firefox
or even in iceweasel sometimes due to what appears to be VM problems
and memory leaks ( this was even more annoying when my first attempt to
write a test program that invoked my webkit build was dying on a smart or
auto ptr assign LOL). So, I'd worry about saving memory first and making things
more local FWIW.  Loading up memory with more housekeeping and idle threads
may not be a good idea. 




>
> Thanks in advance,
> Zoltan
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 		 	   		  
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/