On Aug 28, 2014, at 9:26 PM, Cameron Zwarich <zwar...@mozilla.com> wrote:
> On Aug 28, 2014, at 5:45 PM, Clark Gaebel <cgae...@mozilla.com> wrote: > >> 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. > > As a side point, why is there a 7 us overhead here for message-passing > between green threads? Is it really that bad? Are script and layout currently > green tasks, or did something land causing this to not be the case? Yes, the current perf issue is a bug due to a workaround landed to move script onto a native task to avoid some bugs related to Servo's very-old SpiderMonkey but very-new Web Workers support: https://github.com/servo/servo/pull/2842 That architecture will probably persist until we get a SpiderMonkey upgrade that will allow us to switch script back to also being on a green thread, per the discussion in this thread: https://github.com/servo/servo/pull/2915#issuecomment-50355651 At that point, I'd expect script to layout calls via message passing to be much cheaper than a mutex acquisition, but would be very interested to see numbers comparing them! In general, I'd be a little wary of adding global locks into Servo unless it's really necessary (i.e., if it turns out we can't architect away the race condition Cameron brought up in any other way). Since we haven't found a good way to do any concurrent protocol verification yet for Servo, it's really easy to end up writing deadlocky or racy code (mainly w.r.t. underlying native resource allocation/destruction). For example, I spent way too much time getting shutdown "cleaned up" so that we don't intermittently crash due to attempting to render to graphics contexts that had been destroyed too early, and that was just tracking through our spaghetti message passing code, with no locks to reason about. - Lars _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
