[webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

[Filip Pizlo]

Hi Zoltan,

I would be curious how you did the synchronization.  I've had some luck reducing synchronization costs before.

Was the patch ever uploaded anywhere?

-F


On Jan 10, 2013, at 12:11 AM, Zoltan Herczeg <zherczeg at webkit.org> wrote:

> Parsing, especially JS parsing still takes a large amount of time on page
> loading. We tried to improve the preload scanner by moving it into
> anouther thread, but there was no gain (except some special cases).
> Synchronization between threads is surprisingly (ridiculously) costly,
> usually worth for those tasks, which needs quite a few million
> instructions to be executed (and tokenization takes far less in most
> cases). For smaller tasks, SIMD instruction sets can help, which is
> basically a parallel execution on a single thread. Anyway it is worth
> trying, but it is really challenging to make it work in practice. Good
> luck!
> 
> Regards,
> Zoltan
> 
>> On Jan 9, 2013, at 10:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>> 
>>> On Wed, 9 Jan 2013, Eric Seidel wrote:
>>>> 
>>>> The core goal is to reduce latency -- to free up the main thread for
>>>> JavaScript and UI interaction -- which as you correctly note, cannot be
>>>> moved off of the main thread due to the "single thread of execution"
>>>> model of the web.
>>> 
>>> Parsing and (maybe to a lesser extent) compiling JS can be moved off the
>>> main thread, though, right? That's probably worth examining too, if it
>>> hasn't already been done.
>> 
>> 100% agree.
>> 
>> However, the same problem I brought up about tokenization applies here: a
>> lot of JS functions are super cheap to parse and compile already, and the
>> latency of doing so on the main thread is likely to be lower than the
>> latency of chatting with another core.  I suspect this could be alleviated
>> by (1) aggressively pipelining the work, where during page load or during
>> heavy JS use the compilation thread always has a non-empty queue of work
>> to do; this will mean that the latency of communication is paid only when
>> the first compilation occurs, and (2) allowing the main thread to steal
>> work from the compilation queue.  I'm not sure how to make (2) work well.
>> For parsing it's actually harder since we rely heavily on the lazy parsing
>> optimization: code is only parsed once we need it *right now* to run a
>> function.  For compilation, it's somewhat easier: the most expensive
>> compilation step is the third-tier optimizing JIT; we can delay this as
>> long as we want, though the longer we dela
>> y it, the longer we spend running slower code.
>> 
>> Hence, to make parsing concurrent, the main problem is figuring out how to
>> do predictive parsing: have a concurrent thread start parsing something
>> just before we need it.  Without predictive parsing, making it concurrent
>> would be a guaranteed loss since the main thread would just be stuck
>> waiting for the thread to finish.
>> 
>> To make optimized compiles concurrent without a regression, the main
>> problem is ensuring that in those cases where we believe that the time
>> taken to compile the function will be smaller than the time taken to awake
>> the concurrent thread, we will instead just compile it on the main thread
>> right away.  Though, if we could predict that a function was going to get
>> hot in the future, we could speculatively tell a concurrent thread to
>> compile it fully knowing that it won't wake up and do so until exactly
>> when we would have otherwise invoked the compiler on the main thread (that
>> is, it'll wake up and start compiling it once the main thread has executed
>> the function enough times to get good profiling data).
>> 
>> Anyway, you're absolutely right that this is an area that should be
>> explored.
>> 
>> -F
>> 
>> 
>>> 
>>> --
>>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev