[dev-servo] Meeting notes - further discussion of selected topics from "Unanswered questions" thread
https://github.com/mozilla/servo/wiki/Meeting-2013-07-15 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes - further discussion of selected topics from "Unanswered questions" thread
On 7/15/13 3:05 PM, Josh Matthews wrote: https://github.com/mozilla/servo/wiki/Meeting-2013-07-15 Some comments on the discussion (sorry I couldn't make the meeting, and thank you for the notes!): 1) Mutable prototypes will be supported in SpiderMonkey (and indeed are), but they will likely not be fast (and indeed, they are not). For one thing, they totally defeat the way TI works right now. In practice, we should check how often C++ objects are allocated without setting up their proto chain in Gecko. I bet it's not too often If we get desperate here, we can try to make DOM prototype setup faster in SpiderMonkey. Right now it's slow mostly for dumb reasons. Or are we worrying about the memory used by the prototypes? 2) We can modify Spidermonkey as needed, and should, but we also want to avoid biting off more than we can chew (e.g. replacing TI wholesale is probably not something that should be on the blocking path to servo). Especially given that the JS team doesn't have spare cycles. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes - further discussion of selected topics from "Unanswered questions" thread
On Jul 15, 2013, at 1:11 PM, Boris Zbarsky wrote: > On 7/15/13 3:05 PM, Josh Matthews wrote: >> https://github.com/mozilla/servo/wiki/Meeting-2013-07-15 > > Some comments on the discussion (sorry I couldn't make the meeting, and thank > you for the notes!): > > 1) Mutable prototypes will be supported in SpiderMonkey (and indeed are), but > they will likely not be fast (and indeed, they are not). For one thing, they > totally defeat the way TI works right now. In practice, we should check how > often C++ objects are allocated without setting up their proto chain in > Gecko. I bet it's not too often Agreed. If it's not necessary, great. I was mostly just thinking out loud about possible tools at our disposal. But of course the truth is, whatever we need that we were getting at the C++ level could in theory be gotten in self-hosted JS code, simply by adding some special-purpose self-hosting functionality to the JS engine. So in addition to not being sufficient (you need to know *when* the prototype is needed to trigger the mutation), mutable proto may not be necessary either. > If we get desperate here, we can try to make DOM prototype setup faster in > SpiderMonkey. Right now it's slow mostly for dumb reasons. Or are we > worrying about the memory used by the prototypes? The latter, AIUI. > 2) We can modify Spidermonkey as needed, and should, but we also want to > avoid biting off more than we can chew (e.g. replacing TI wholesale is > probably not something that should be on the blocking path to servo). > Especially given that the JS team doesn't have spare cycles. Agreed. We have people, like JDM, who can potentially implement changes to SpiderMonkey as well. But we should certainly tread lightly with things that affect TI. (I would *definitely* never advocate replacing TI for Servo!) Dave ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes - further discussion of selected topics from "Unanswered questions" thread
"people like roc say we must be at least as fast as Gecko for everything" To be clear: I think Servo's architecture must not prevent Servo from being as fast as Gecko for everything. I push for microbenchmarks targeting the risky parts of Servo's architecture because we must avoid discovering much later that some critical part of Servo's architecture is wrong. But I think it's completely fine for Servo to be slower than Gecko on some tests, indefinitely, as long as it's obvious how to fix that. In fact it's much more important to beat Gecko (and Blink) mightily on some tests than to equal them on all tests. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes - further discussion of selected topics from "Unanswered questions" thread
For compositing with IFRAMEs, you might want to consider what we do for multi-process compositing in Gecko. It's somewhat obvious but it seems like it works well. Each process publishes a layer tree to the compositor. A layer tree can contain RefLayers, each with a unique ID. A layer tree root can also be given an ID. The compositor matches roots to RefLayers to build a complete layer tree which is composited as a whole. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes - further discussion of selected topics from "Unanswered questions" thread
On 7/15/13 3:58 PM, Robert O'Callahan wrote: For compositing with IFRAMEs, you might want to consider what we do for multi-process compositing in Gecko. It's somewhat obvious but it seems like it works well. Each process publishes a layer tree to the compositor. A layer tree can contain RefLayers, each with a unique ID. A layer tree root can also be given an ID. The compositor matches roots to RefLayers to build a complete layer tree which is composited as a whole. That was basically what we whiteboarded. (I called a RefLayer an IframeProxyLayer but the idea was the same.) Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes - further discussion of selected topics from "Unanswered questions" thread
Robert O'Callahan wrote: "people like roc say we must be at least as fast as Gecko for everything" To be clear: I think Servo's architecture must not prevent Servo from being as fast as Gecko for everything. I push for microbenchmarks targeting the risky parts of Servo's architecture because we must avoid discovering much later that some critical part of Servo's architecture is wrong. Important clarification -- thanks! But I think it's completely fine for Servo to be slower than Gecko on some tests, indefinitely, as long as it's obvious how to fix that. In fact it's much more important to beat Gecko (and Blink) mightily on some tests than to equal them on all tests. This is key, and we always (you and I anyway) said "win on multicore beyond what a mostly-single-core-architected engine can do". You once said "win on 8-way or higher only." That might want to be 4-way, I don't know (Ras filled Dave and me in on the trend in chipmakers to go linear after 8, not keep doubling # of cores -- "the end of Dennard scaling"). But part of the value of Servo is relative to degree of hardware parallelism. /be ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
