It’s nice that it’s so close to the competition. It would be interesting to see
numbers on ARM as well, since the relative cost of the atomic instructions
might be higher, even in the uncontended case.
Is it strictly enforced that the script task never sees inconsistent views of
layout? This came up in the other thread about threading, but what prevents
this incorrect scenario?
1) The script task takes the mutex to access one property of layout.
2) The script task releases the mutex.
3) Layout changes the property that was accessed.
4) The script task takes the mutex again to access the same property, in the
same turn of the event loop without modifying layout in any intervening work
since the last attempt.
5) The script task reads a different value from before.
Cameron
On Aug 28, 2014, at 5:45 PM, Clark Gaebel <cgae...@mozilla.com> wrote:
> Hi servo-dev!
>
> Servo exists to validate the idea that parallel browser architectures work.
> Going parallel isn't always a good thing, and can sometimes be worse if
> there's too much communication overhead. For example, in the current Servo
> design, javascript is run in a different task than layout. This is great, but
> it means that javascript calls that require communication between the tasks
> can incur a lot of overhead.
>
> Consider this HTML/JS:
>
> <html>
> <script>
>
> var ready = function() {
> var ident = document.getElementById("some_div");
> var left_sum = 0;
> var top_sum = 0;
> var right_sum = 0;
> var bottom_sum = 0;
> var t0 = +new Date();
> for(var i = 0; i < 10000000; i++) {
> var rect = ident.getBoundingClientRect();
> left_sum += rect.left;
> top_sum += rect.top;
> right_sum += rect.right;
> bottom_sum += rect.bottom;
> }
> var t1 = +new Date();
>
> ident.appendChild(document.createTextNode("sums: (" + left_sum + ", " +
> top_sum + ", " + right_sum + ", " + bottom_sum + ") "));
> ident.appendChild(document.createTextNode("dt: " + (t1 - t0) + " ms"));
> }
>
> //document.addEventListener("DOMContentLoaded", ready, false)
> window.onload = ready;
> </script>
> <body>
> <div id="some_div">Working...</div>
> </body>
> </html>
>
> Running this on Firefox takes 500 ns/iteration. Chrome takes 700 ns/iteration.
>
> Servo before [1] lands took 8100 ns! That's paying a lot (some would say too
> much) for a parallel architecture, when simple queries experience a 10x
> slowdown.
>
> However, thanks to [1], Servo is down to 950 ns/iteration. This is very
> competitive with Firefox and Chrome, especially when considering the mutex
> involved. I'm sure with some micro-optimization work we can get closer.
>
> Because of these results, I believe that communication overhead between
> script and layout can be (and has been) reduced to a competitive amount,
> while still maintaining the benefits of parallelization.
>
> Regards,
> - Clark
>
> [1] https://github.com/servo/servo/pull/3164
> _______________________________________________
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
