[dev-servo] Quantifying the impact of floats on parallelism
Hi everyone, I did some preliminary investigation into how much floats are likely to impact parallelism in the wild. I wrote a quick script [1] that looks at how many nodes could have their heights assigned in parallel and ran it on the Alexa Top 50 in the US. I assume that a node can be laid out in parallel unless it is "impacted by floats". A node is said to be "impacted by floats" in a direction (left or right) if any of the following is true: (1) The node contains a float descendant that is part of the same block formatting context. (2) Any of its previous siblings could be impacted by floats, unless the sibling has the "clear" property set and there are no siblings impacted by floats in the direction(s) cleared. (3) A parent in a separate block formatting context is itself impacted by floats. (This accounts for the fact that "clear" does not clear floats in separate block formatting contexts.) I believe these rules are sufficient to capture the idea of a node that can be laid out in parallel with its siblings, although I could definitely be wrong here. Take these numbers with a grain of salt, because it's very possible I'm missing something in the algorithm. Anyway, the results are in this Google Doc [2]. In summary: On average 85.16% of nodes can be laid out in parallel. There is some variability: two of the sites (reddit.com and buzzfeed.com) were below 60% parallel. However, the numbers seemed overall promising: 73% of the sites had > 80% of the nodes able to be laid out in parallel. Patrick [1]: https://gist.github.com/pcwalton/9064215 [2]: https://docs.google.com/spreadsheet/ccc?key=0AmYOd6rv-l1OdHA0bVVRd3I4OW1xTEV1SERYUldrU2c&usp=sharing ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Quantifying the impact of floats on parallelism
On 2/17/14 7:51 PM, Patrick Walton wrote: Hi everyone, I did some preliminary investigation into how much floats are likely to impact parallelism in the wild. I wrote a quick script [1] that looks at how many nodes could have their heights assigned in parallel and ran it on the Alexa Top 50 in the US. I assume that a node can be laid out in parallel unless it is "impacted by floats". A node is said to be "impacted by floats" in a direction (left or right) if any of the following is true: (1) The node contains a float descendant that is part of the same block formatting context. (2) Any of its previous siblings could be impacted by floats, unless the sibling has the "clear" property set and there are no siblings impacted by floats in the direction(s) cleared. (3) A parent in a separate block formatting context is itself impacted by floats. (This accounts for the fact that "clear" does not clear floats in separate block formatting contexts.) Oh, one more thing: Servo currently does not use this algorithm, resulting in poor parallel performance on many sites at the moment. In particular: 1. Servo does not know that floats cannot spill out of block formatting contexts, so the has-floated-children flag applies to more nodes than necessary. 2. Servo does not take clearance into account when deciding how to propagate the impacted-by-floats flag to siblings, so the impacted-by-floats flag applies to more nodes than necessary. This work seems to indicate that these two optimizations are very important for achieving parallelism in the real world. Practically all Alexa Top 50 use floats for parallelism, but they seem to constrain it. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Parallel hazards with absolutely positioned blocks
On 2/16/14 7:15 PM, Pradeep Kumar S wrote: Hi everyone, Just wanted to weigh in about the algorithm mentioned by Boris and Patrick above: I think it won't work for calculating height for absolutely positioned elements because we aren't calculating the static position y-coordinate anywhere. This needs to be done by adding up the heights of all the "frames" between the hypothetical box and the actual Containing Block. The dependency is like (assign-height for in-flow frames) -> (calculate static position y-coordinate for hypothetical boxes) -> (assign-height for absolutely positioned elements) -> (send back overflow from absolutely positioned elements) This seems to suggest that we need some sort of a traversal after the normal assign-heights traversal. Yes, that's true. Good point. > + (2) Traverse back to the containing block from each hypothetical frame to calculate the static position y-coordinate An alternative would be to bubble up y coordinates of hypothetical frames during assign-heights. (We could just keep a count of absolute children during flow construction and preallocate those slots at that time.) That would potentially be better on the CPU cache because it avoids a separate sequential traversal but might be slower during style recalc due to having larger flows. > What do you think? Sounds good, thanks for bringing it up! Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
