https://bugs.webkit.org/show_bug.cgi?id=63531
The work was done by Zoltan Horvath and Balazs Kelemen. Regards, Zoltan > 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 <zherc...@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 <i...@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@lists.webkit.org >>>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev