On 2/13/13 7:16 PM, Boris Zbarsky wrote:
On 2/13/13 9:47 PM, Brian Anderson wrote:
During a lunch discussion today we decided that we have three areas that
we care most about this year: layout, crow, and dom bindings.
We still need to make basic measurements of round-trip times through our
DOM to layout and back on a sync layout flush. I haven't been able to
do that yet, not least because I haven't actually managed to get servo
to compile any of the times I've tried it recently....
Servo now ships a known-working version of Rust, so it should be easier
to build.
With the changes today Servo now uses the faster pipes instead of the
slower comm, so the communication should be faster than it was. However,
kicking a sleeping Rust task awake is still more expensive than it
should be; it involves several locks. Fixing this will require the
scheduler rewrite that brson is currently working on. As per the current
plan for the rewrite, content will be able to atomically steal the
sleeping layout task and context switch into it if it is sleeping, which
should be very fast; overhead over a function call is one atomic
operation plus some more register saves/restores.
Maybe for a performance test we could just have the layout spin in a
separate thread. Communication is lock-free as long as the layout task
is awake at the time of the send. This may not be as fast as the
sleeping case under the scheduler rewrite, however, because it increases
the multi-CPU bus traffic.
Ultimately we will need the scheduler rewrite in order to get meaningful
numbers out of these performance benchmarks. Essentially this boils down
to how fast a function call (Gecko/WebKit) performs compared to a
context switch (Rust scheduler/Servo). We know that some sort of
architecture that allows a message send to avoid a round trip through
the scheduler is needed to achieve this. We won't know until the
scheduler rewrite is complete.
I could microbenchmark the cost of an atomic operation and a register
context switch compared to a function call, perhaps...
I believe that's higher priority than pretty much anything else right
now, because we need that to know whether the general architecture is
getting us the performance we want.
That said, what is "crow"?
A simple frontend to establish the multi-process model. The rationale is
that getting multi-process working early is better than putting it off
to avoid the situation we are in with Gecko.
How about deciding on an actual implementation strategy for the DOM?
Simple things like how we actually plan to represent DOM objects in Rust
in a way that allows bindings to work with reasonable performance (i.e.
without having to make everything a virtual call) would be a good
start... I've tried bringing this up before and keep being told that
the relevant parts of Rust are in flux so we have to decide later.
I plan to write up my thoughts more on the wiki tomorrow, but I am
currently leaning toward not using copy-on-write and instead just having
the DOM objects' contents be immutable while layout is running. Thus we
avoid having to allocating handles and have multiple pointers. This is
basically the way Gecko and WebKit do it, so this reduces the
single-threaded performance risk. For now JS will just block if it wants
to mutate the DOM while layout is running. If we want JS to be able to
mutate the DOM while layout is running without blocking, then we could
add some sort of change queue or journal later on top of this design.
I think we should just ignore the fact that Rust cannot currently
inherit traits from structs for now and implement the DOM object methods
that have to be virtual using unsafe Rust code. Basically we can just
embed a vtable full of "extern fn"s into the structs that represent the
DOM and manually cast to obtain the self pointer. (Inheritance of traits
from structs is the missing feature that we would need in Rust to make
this safe.) Later we can add that feature to Rust and make it safe. But
for now this would give us the right performance model: a struct with
flat fields, supporting a combination of nonvirtual and virtual methods.
Regarding stack switching, I have a proposal that has achieved tentative
consensus on the Rust team that should allow us to remove the stack
switching burden from the DOM task entirely for calls from Rust into the
JS engine and vice versa. So we should be good there. It needs to be
implemented, of course.
Patrick
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
