August 2009 - webkit-dev - lists.webkit.org

what's purpose of the functions Branch(Add Sub Mul)32 in MacroAssembler ?
by Felix long 02 Aug '09

02 Aug '09

Hi: I'm trying to port jit of JavaScriptCore to mips, but I failed to implement Branch(Add Sub Mul)32 for mips since I don't know a simple way to do overflow detection on MIPS like ARM or X86. is it possible to remove these Overflow detect in jit runtime? or who can tell me a simple way to do Overflow detect on MIPS? -- Best Regards Felix Long

1 0

LayoutTests take too long to run
by Eric Seidel 01 Aug '09

01 Aug '09

681.70s total testing time That's 11.5 minutes for every patch I want to land. (because I run the layout tests before landing anything, as part of bugzilla-tool). I'm very interested in any suggestions folks have to make that number smaller. I know Chromium runs the layout tests in parallel using their python run_webkit_tests.py harness. Try-bots would be another solution to the "make sure it passes all the tests before landing". Again, very interested in suggestions as to how to improve this. -eric

5 8

Grant Gayed is out of the office.
by Grant Gayed 01 Aug '09

01 Aug '09

I will be out of the office starting 07/31/2009 and will not return until 08/17/2009. I will respond to your message when I return.

1 0

Re: [webkit-dev] parallel layout research
by lmeyerov 01 Aug '09

01 Aug '09

> It reminds me a lot of the work Badros did circa 2000 [1]. > That work added linear constraints to CSS and a variety of other languages. It did not show how to do flow-based layout with linear constraints: ultimately, the utility and applicability of their techniques to actual layout systems was never really understood (e.g., can we cleanly implement and specify CSS with linear constraints? quadratic ones?). I don't recall the end-to-end solving time, but, in my experience, it's not the constraint solving of stuff like finding what point of font (which is essentially what they support). The way I think about that work is that there is awkwardness with strictly flow-based layout and Badros showed a useful primitive -- linearly constrained variables -- to help with some of it. > they've implemented an abstract language for describing the CSS > spec for parameterizing layout. > Most of my implementation work has actually been on tweaking out selectors as a way to get used to multicore performance concerns in this space :) I'm working on language subsets, not full ones, in order to experiment with actual implementations and iterate over many algorithm ideas. For layout, I started with formalizing a subset of CSS 2.1 -- essentially inlines, inline blocks, blocks, and left-floats with no margins/padding/explicit positioning. Given that subset, I found places for parallelism at the node-level (with speculation that floats don't have an impact at the local level, which seems founded). Next I'll be bouncing between expanding it and implementing and then tweaking it for various memory systems. > They suggest that this model does layout of the CSS 2.1 spec in time > similar to the hand-tuned sequential engine in Gecko [2] > using Cilk++ to handle low-level paralleism, they've seen > significant speedups beyond that for multi-core [2] > That work is now moving into the implementation phase: the slides were for a model showing a minimum of what we'd expect if solving constraints was the bottleneck (so parallelizing a tree of slow constraints). Interesting, they're not -- it's stuff like dealing with text and images that come into play -- so I actually expect a much better speedup. Because of this, my first implementation step was to actually reexamine how to call into a font library like freetype2 for better caching and multicore behavior. > I think parallel layout is an interesting topic to explore, in light of > where CPUs are going... We have had a lot of success with improving layout > performance given test cases that demonstrate slowness. > Worth mentioning our interest is half in traditional browser settings (faster slashdot) and half in the mobile space. For the former, you may or may not care if opening a page is as fast as hitting the back button (though there are studies to show this has a big impact on usability in practice), but, for the latter, we want to do at least a magnitude better *everywhere*. Moh has had luck with firefox in terms of better memory usage, but I think that's telling: you need to take advantage of the hardware with the algorithms, whether it be CPU or L1. > We probably can't use code in Cilk++ directly, > TBB might be a more viable route in terms of licensing (and more amenable to performance tools). Currently, I benefit from Cilk most in the early prototyping phases -- I then rewrite in TBB because the compiler seems to do better and I can do better profiling. I'll be back in the bay area starting mid-September and would love to meet anybody interested in this stuff. There are approaches that might work (e.g., STM or rewriting in a pure language), but at least we're starting to get proof that multicore helps for at least one approach :) Finally, it's worth noting that I also get significant speedups by being careful about l1/l2 usage -- I doubt that style of optimization works well in a huge codebase with many contributors, so parallelization (with a sane framework like cilk/tbb) might better scale with the code over time. -- View this message in context: http://www.nabble.com/parallel-layout-research-tp24761520p24765531.html Sent from the Webkit mailing list archive at Nabble.com.

1 0

webkit C++ style checking tool
by Shinichiro Hamaji 01 Aug '09

01 Aug '09

Hi folks, > Adam Treat, David Levin, Jakob Petsovits, Kenneth Rohde Christiansen, and I have been working on ./WebKitTools/Scripts/check-webkit-style to check code for WebKit style violations. Let me introduce the tool to you. Simply, check your current patch by running the tool: % ./WebKitTools/Scripts/check-webkit-style This checks the files you have modified locally. If any style issues are found in a line that you modified, it outputs a warning for the violation. If you are using git, you can use the tool for your local commits: % ./WebKitTools/Scripts/check-webkit-style --git-commit=HEAD~1 You can also run the tool for specified file(s): > % ./WebKitTools/Scripts/check-webkit-style WebCore/rendering/RenderBox.cpp % ./WebKitTools/Scripts/check-webkit-style WebCore/rendering/*.cpp I believe this tool can save the time for both reviewers/reviewees, so I'm inviting you to try it out on your patches. Also, if you find any issues or desire certain improvements, please file bugs. Thanks! PS Special thanks to Albert Wong for getting a WebKit compatible license on the cpplint.py code, David Kilzer and Eric Seidel for helpful feature suggestions, and Mark Rowe for nudging us toward a good name for the tool. Sorry if I missed anyone.

1 0

parallel layout research
by Alex Russell 01 Aug '09

01 Aug '09

After a discussion this morning about the potential for parallel CSS layout with Erik Aarvidson, he pointed out a group at Berkeley doing research in this area: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/ The bits that jumped out to me were: * the source is available [0] * they've implemented an abstract language for describing the CSS spec for parameterizing layout. It reminds me a lot of the work Badros did circa 2000 [1]. They suggest that this model does layout of the CSS 2.1 spec in time similar to the hand-tuned sequential engine in Gecko [2] * using Cilk++ to handle low-level paralleism, they've seen significant speedups beyond that for multi-core [2] It's exciting to me to see this kind of parallelism being extracted from CSS layout operations, which have shown up in profiling of Google apps as a serious bottleneck. I hesitate to ask about the WebKit community's interest in this since I assume that if patches show up and can prove their value, they'll be accepted, but I would like to know where people are either supportive or skeptical about such an approach. Regards [0]: http://code.google.com/p/pbrowser/source/browse/#svn/trunk [1]: http://www.badros.com/greg/papers/gjbadros-dissertation.pdf [2]: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/retreatwinter2009/… , slide #19

5 4