Re: [dev-servo] Recent Improvements to Functions like getClientBoundingRect
On Aug 28, 2014, at 9:26 PM, Cameron Zwarich wrote: > On Aug 28, 2014, at 5:45 PM, Clark Gaebel 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
Re: [dev-servo] Recent Improvements to Functions like getClientBoundingRect
On 2014-08-29 8:27 AM, Lars Bergstrom wrote: On Aug 28, 2014, at 9:26 PM, Cameron Zwarich wrote: 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 only affected workers, not the main script task. 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 We should not assume that anybody on the SpiderMonkey is doing that work. If we're going to bet on this, we're going to need to push on them/do it ourselves. 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 Cheers, Josh ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Recent Improvements to Functions like getClientBoundingRect
On 2014-08-29 9:52 AM, Josh Matthews wrote: On 2014-08-29 8:27 AM, Lars Bergstrom wrote: 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! To be clear, we're spawning a green task for each script task today (despite the fact that we should not be, according to our JSAPI use). ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Recent Improvements to Functions like getClientBoundingRect
On 8/29/14 5:27 AM, Lars Bergstrom wrote: 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. I agree in general. `MutexArc` should be your last resort. I think that this one is worth making an exception for, though: it's pretty fundamental to the design, and we can potentially abstract it away via the "RPC" mechanism. I definitely agree that we shouldn't end up with a system where you have to sprinkle "lock_dom()" calls throughout script and layout: the locking should happen in a single well-defined place. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Recent Improvements to Functions like getClientBoundingRect
I filed both of the issues discussed on this thread: https://github.com/servo/servo/issues/3187 https://github.com/servo/servo/issues/3188 Cameron On Aug 28, 2014, at 7:20 PM, Patrick Walton wrote: > I believe the answer today is "nothing"--i.e. it's a Servo bug. Clark's work > doubles as a nice way to fix it :) > > Patrick > > On August 28, 2014 7:18:27 PM PDT, Robert O'Callahan > wrote: > On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton wrote: > It might happen if layout is flushed from outside the script task; window > resizing/device rotation being what immediately comes to mind, as today in > Servo those events go straight from compositor to layout without hitting the > script task at all. (As an alternative design, we could route such events > through the script task; this would remove the necessity of the mutex but > would block layout for such events if script is running, even if the script > hasn't touched the DOM.) > > Hmm. So given > > var v = e.getBoundingClientRect(); > // layout change is triggered by window resizing or whatever > var v2 = e.getBoundingClientRect(); > > what in Servo, prior to Clark's work, ensures v and v2 are the same? > > Rob > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
