Re: [webkit-dev] Iterating SunSpider
On Sat, Jul 4, 2009 at 3:27 PM, Maciej Stachowiak m...@apple.com wrote: On Jul 4, 2009, at 11:47 AM, Mike Belshe wrote: I'd like to understand what's going to happen with SunSpider in the future. Here is a set of questions and criticisms. I'm interested in how these can be addressed. There are 3 areas I'd like to see improved in SunSpider, some of which we've discussed before: #1: SunSpider is currently version 0.9. Will SunSpider ever change? Or is it static? I believe that benchmarks need to be able to move with the times. As JS Engines change and improve, and as new areas are needed to be benchmarked, we need to be able to roll the version, fix bugs, and benchmark new features. The SunSpider version has not changed for ~2yrs. How can we change this situation? Are there plans for a new version already underway? I've been thinking about updating SunSpider for some time. There are two categories of changes I've thought about: 1) Quality-of-implementation changes to the harness. Among these might be ability to use the harness with multiple test sets. That would be 1.0. Cool 2) An updated set of tests - the current tests are too short, and don't adequately cover some areas of the language. I'd like to make the tests take at least 100ms each on modern browsers on recent hardware. I'd also be interested in incorporating some of the tests from the v8 benchmark suite, if the v8 developers were ok with this. That would be SunSpider 2.0. Cool. Use of v8 tests is just fine; they're all open source. The reason I've been hesitant to make any changes is that the press and independent analysts latched on to SunSpider as a way of comparing JavaScript implementations. Originally, it was primarily intended to be a tool for the WebKit team to help us make our JavaScript faster. However, now that third parties are relying it, there are two things I want to be really careful about: a) I don't want to invalidate people's published data, so significant changes to the test content would need to be published as a clearly separate version. Of course. Small UI nit - the current SunSpider benchmark doesn't make the version very prominent at all. It would be nice to make it more salient. b) I want to avoid accidentally or intentionally making changes that are biased in favor of Safari or WebKit-based browsers in general, or that even give that impression. That would hurt the test's credibility. When we first made SunSpider, Safari actually didn't do that great on it, which I think helped people believe that the test wasn't designed to make us look good, it was designed to be a relatively unbiased comparison. Of course. Thus, any change to the content would need to be scrutinized in some way. I'm not sure what it would take to get widespread agreement that a 2.0 content set is fair, but I agree it's time to make one soonish (before the end of the year probably). Thoughts on this are welcome. #2: Use of summing as a scoring mechanism is problematic Unfortunately, the sum-based scoring techniques do not withstand the test of time as browsers improve. When the benchmark was first introduced, each test was equally weighted and reasonably large. Over time, however, the test becomes dominated by the slowest tests - basically the weighting of the individual tests is variable based on the performance of the JS engine under test. Today's engines spend ~50% of their time on just string and date tests. The other tests are largely irrelevant at this point, and becoming less relevant every day. Eventually many of the tests will take near-zero time, and the benchmark will have to be scrapped unless we figure out a better way to score it. Benchmarking research which long pre-dates SunSpider confirms that geometric means provide a better basis for comparison: http://portal.acm.org/citation.cfm?id=5673 Can future versions of the SunSpider driver be made so that they won't become irrelevant over time? Use of summation instead of geometric mean was a considered choice. The intent is that engines should focus on whatever is slowest. A simplified example: let's say it's estimated that likely workload in the field will consist of 50% Operation A, and 50% of Operation B, and I can benchmark them in isolation. Now let's say implementation in Foo these operations are equally fast, while in implementation Bar, Operation A is 4x as fast as in Foo, while Operation B is 4x as slow as in Foo. A comparison by geometric means would imply that Foo and Bar are equally good, but Bar would actually be twice as slow on the intended workload. I could almost buy this if: a) we had a really really representative workload of what web pages do, broken down into the exactly correct proportions. b) the representative workload remains representative over time. I'll argue that we'll never be very good at (a), and that (b) is impossible. So, what
Re: [webkit-dev] [V8] It's time for V8Proxy to come to Jesus
On Sat, Jul 4, 2009 at 9:13 PM, Maciej Stachowiakm...@apple.com wrote: If you have specific ideas about changes to the JS bindings we can go over them soon. The general idea of factoring out a separate class to handle security policy seems good. Manager is one of the things in class names I tend to be allergic to. Instead of SecurityManager I would consider names like SameOriginPolicy or SameOriginAuditor or something like that (assuming the main security-related thing it does is enforce the same-origin policy). The same-origin policy itself mostly handled by the SecurityOrigin class in WebCore proper. The main purpose I plan for this new class is to understand the mapping between the current state of the JavaScript engine (the ExecState in JSC terms) and a security context (be it a Frame, a Document, or a SecurityOrigin) and how to get useful information from these objects (e.g., how to call SecurityOrigin::canAccess, log the warning message, etc). Maybe JSSecurityContext would be a better name? In general I can do lunch meetings in SF with some advance notice, but this coming week is probably out, at least for me, due to various prior commitments. (I think we have a tentative plan to have lunch with some Chrome folks at Apple's Cupertino campus though.) Ok. I might pester you via email or IRC then. :) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [V8] It's time for V8Proxy to come to Jesus
On Sat, Jul 4, 2009 at 9:29 PM, Jian Lijia...@chromium.org wrote: FYI, we've also another WorkerContextExecutionProxy that acts like V8Proxy in order to talk to V8 engine for everything needed in WorkerContext. When we do refactoring for V8Proxy, we also need to make it be able to support different execution context. Thanks for bringing this class to my attention. I will study it also. Hopefully the two will be able to share virtually all of their code. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Iterating SunSpider
Maciej Stachowiak wrote: I think the pauses were large in an attempt to get stable, repeatable results, but are probably longer than necessary to achieve this. I agree with you that the artifacts in balanced power mode are a problem. Do you know what timer thresholds avoid the effect? I think this would be a reasonable 1.0 kind of change. Just a gut feeling, but I suspect the exact throttling algorithm would vary too much from machine to machine and OS version to OS version to ever find a good threshold to avoid it. The best thing to do would be to have the harness turn off CPU throttling when it starts. (This is possible from the commandline under Linux, and I assume in Mac, but Windows might be a problem.) Joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bug 22759 - dropdown menu disappears on mouse-over
Hi, this post is related to issue
https://bugs.webkit.org/show_bug.cgi?id=22759.
corresponding chrome issue is
http://code.google.com/p/chromium/issues/detail?id=2019
This post discusses the issue using the reduction HTML file available on the
issue.
Following calculations calculate the expected results for the
reduction HTML file attached to the issue.
Root ListItem vertical size, RLITotal = 0.6em top padding + text
line height + 0.7em bottom padding, where
Text line height = 16px * 70/100 * 1.5 = 16.8
So RLITotal = 0.6 * 16 * 70 / 100 + 16.8 + 0.7 * 16 * 70 / 100
= 6.72 + 16.8 + 7.84
= 31.36
The absolute positioned popup list's vertical position = 2.8em
= 2.8 * 16 * 70 /100
= 31.36
Though there is no gap between root element and popup, in Chrome we
see some gap.
What happens inside code during parsing the HTML file is that floating
pointing number gets converted to integer without rounding off. So
6.72 becomes 6, 7.84 becomes 7 and 16.8 becomes 16 resulting in total
for RLITotal as 29.
And absolute vertical location for popup, 31.36 becomes 31.
Clearly two pixel gap results because of this rounding off behaviour.
Inside following function,
int computedLineHeight() const
{
Length lh = lineHeight();
// Negative value means the line height is not set. Use the
font's built-in spacing.
if (lh.isNegative())
return font().lineSpacing();
if (lh.isPercent())
return lh.calcMinValue(fontSize(), true);
return lh.value();
}
The line, return lh.calcMinValue(fontSize(), true); was changed by
adding true as second parameter, which lets the calcMinValue to round
off the result to nearest integer. So in above example 16.82 becomes
17.
But that will not be sufficient because we'll still have 1 pixel gap.
So adding 0.5 to result before casting it to integer in the following
function fixes the issue. This function is a generic function used
during HTML/CSS file parsing.
int CSSPrimitiveValue::computeLengthIntForLength(RenderStyle* style,
double multiplier)
{
double result = computeLengthDouble(style, multiplier);
// This conversion is imprecise, often resulting in values of,
e.g., 44.8. We
// need to go ahead and round if we're really close to the next
integer value.
result += result 0 ? -0.01 : +0.01;
if (result intMaxForLength || result intMinForLength)
return 0;
return static_castint(result);
}
I am not sure how critical the comment is in above function. Code
rounds off only if it is too close to integer. Could anyone tell more
about it, as in why 0.01 why not 0.5?
Thanks.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [V8] It's time for V8Proxy to come to Jesus
On Jul 5, 2009, at 5:19 AM, Adam Barth wrote: On Sat, Jul 4, 2009 at 9:13 PM, Maciej Stachowiakm...@apple.com wrote: If you have specific ideas about changes to the JS bindings we can go over them soon. The general idea of factoring out a separate class to handle security policy seems good. Manager is one of the things in class names I tend to be allergic to. Instead of SecurityManager I would consider names like SameOriginPolicy or SameOriginAuditor or something like that (assuming the main security-related thing it does is enforce the same-origin policy). The same-origin policy itself mostly handled by the SecurityOrigin class in WebCore proper. The main purpose I plan for this new class is to understand the mapping between the current state of the JavaScript engine (the ExecState in JSC terms) and a security context (be it a Frame, a Document, or a SecurityOrigin) and how to get useful information from these objects (e.g., how to call SecurityOrigin::canAccess, log the warning message, etc). Maybe JSSecurityContext would be a better name? That sounds like a pretty good name based on your description. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git Familiarity (was ChangeLog)
However, not everyone on the project is comfortable with git (or is willing to give up svn), so I don't see a near-term solution at the moment other than improving the existing tools (prepare-ChangeLog, resolve-ChangeLogs, etc.). I have heard this for about a year and presumable it has gone down over the year so I am curious what percentage of developers use Git or more importantly don't know git today. Both Nokia and TorchMobile use Git completely. Gnome has switch to Git earlier this year so presumably the Gtk developers know Git (correct me if I am wrong). Can someone from Apple and Google comment on how much Git usage you guys have? I am curious how close (or far away) we are to a tipping point where most of the devs know or are familiar with Git. -Benjamin Meyer ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git Familiarity (was ChangeLog)
On Jul 5, 2009, at 5:00 PM, Benjamin Meyer wrote: However, not everyone on the project is comfortable with git (or is willing to give up svn), so I don't see a near-term solution at the moment other than improving the existing tools (prepare-ChangeLog, resolve-ChangeLogs, etc.). I have heard this for about a year and presumable it has gone down over the year so I am curious what percentage of developers use Git or more importantly don't know git today. Both Nokia and TorchMobile use Git completely. Gnome has switch to Git earlier this year so presumably the Gtk developers know Git (correct me if I am wrong). Can someone from Apple and Google comment on how much Git usage you guys have? I am curious how close (or far away) we are to a tipping point where most of the devs know or are familiar with Git. At Apple, most developers use svn for day-to-day development. Some use git. Some use git for special projects like branch rebasing, but otherwise use Subversion for normal development. Some haven't tried git at all. I don't know the exact proportions, but from looking at patch files from my colleagues, less then a quarter submit patches that appear to be generated by git. So far, none of the git users at Apple have advocated changing over wholesale, though it's possible they would prefer that but have been reluctant to say so. I think at some point we need to consider a change in version control system. I would like us to work on the bug tracker and patch review system first, to avoid making too many tools changes at once, and because that issue seems to be more urgent and disruptive of workflow. I'm whipping up an email on what I think are the right short-term and medium-term steps. Once we have that well in hand, then revision control and build system would probably be the next things to review for change. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Iterating SunSpider
On 4-Jul-09, at 2:47 PM, Mike Belshe wrote: #2: Use of summing as a scoring mechanism is problematic Unfortunately, the sum-based scoring techniques do not withstand the test of time as browsers improve. When the benchmark was first introduced, each test was equally weighted and reasonably large. Over time, however, the test becomes dominated by the slowest tests - basically the weighting of the individual tests is variable based on the performance of the JS engine under test. Today's engines spend ~50% of their time on just string and date tests. The other tests are largely irrelevant at this point, and becoming less relevant every day. Eventually many of the tests will take near- zero time, and the benchmark will have to be scrapped unless we figure out a better way to score it. Benchmarking research which long pre-dates SunSpider confirms that geometric means provide a better basis for comparison: http://portal.acm.org/citation.cfm? id=5673 Can future versions of the SunSpider driver be made so that they won't become irrelevant over time? Actually this doesn't happen on all CPUs. For example CPUs without FPU have very different results. memory performance is also a big factor. #3: The SunSpider harness has a variance problem due to CPU power savings modes. Because the test runs a tiny amount of Javascript (often under 10ms) followed by a 500ms sleep, CPUs will go into power savings modes between test runs. This radically changes the performance measurements and makes it so that comparison between two runs is dependent on the user's power savings mode. To demonstrate this, run SunSpider on two machines- one with the Windows balanced (default) setting for power, and then again with high performance. It's easy to see skews of 30% between these two modes. I think we should change the test harness to avoid such accidental effects. I've noticed this issue too. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git Familiarity (was ChangeLog)
On Jul 5, 2009, at 9:00 PM, Justin Haygood wrote: - Original Message - From: Maciej Stachowiak m...@apple.com To: Benjamin Meyer b...@meyerhome.net Cc: WebKit Development webkit-dev@lists.webkit.org Sent: Sunday, July 05, 2009 8:15 PM Subject: Re: [webkit-dev] Git Familiarity (was ChangeLog) I think at some point we need to consider a change in version control system. I would like us to work on the bug tracker and patch review system first, to avoid making too many tools changes at once, and because that issue seems to be more urgent and disruptive of workflow. I'm whipping up an email on what I think are the right short-term and medium-term steps. Once we have that well in hand, then revision control and build system would probably be the next things to review for change. The one thing bad about git is for people who don't use a *nix: Subversion works quite well on Windows, including powerful GUI tools. Git just isn't the same. (For one, it won't work without Cygwin. I can currently build WebKit/Qt without having Cygwin anywhere near my computer). I'm not familiar with other DVCS, but until one has good Windows support, that would rule out a portion of developers. At least on Windows I use mysygit myself (http://code.google.com/p/msysgit/ ) From the project description: Historically, Git on Windows was only officially supported using Cygwin. To help make a native Windows version, this project was started, based on the fork. -Benjamin Meyer ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git Familiarity (was ChangeLog)
- Original Message - From: Benjamin Meyer b...@meyerhome.net To: WebKit Development webkit-dev@lists.webkit.org Sent: Sunday, July 05, 2009 11:25 PM Subject: Re: [webkit-dev] Git Familiarity (was ChangeLog) At least on Windows I use mysygit myself (http://code.google.com/p/msysgit/ ) From the project description: Historically, Git on Windows was only officially supported using Cygwin. To help make a native Windows version, this project was started, based on the fork. Still has the following problems: 1. No Windows integrated UI. Windows is very UI driven, and all of the development tools are UI based. Why should I open up a command line to do VCS stuff? I don't have to open up a command line now. 2. No Visual Studio integration. Subversion not only has TortoiseSVN, but there's AnkhSVN that lets you manage it entirely inside Visual Studio. I'd vote against any VCS that doesn't match features provided by Subversion on all 3 platforms (Mac, Linux, and Windows). *nix devs might think opening up a command line to do some development is fine, but Windows devs aren't nearly as willing. Why, when all of the functionality is available from a UI? I can't think of any major feature of Subversion that isn't available from TortoiseSVN. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git Familiarity (was ChangeLog)
Xcode also has Subversion support, but not Git support. I personally want that Git integration, because I actually use Git fairly often. But for them Windows users, I think we best stick with Subversion. Darren VanBuren - Sent from my iPod Try Fedora 10 today. Fire it up. http://fedoraproject.org/ On Jul 5, 2009, at 22:22, Justin Haygood jhayg...@reaktix.com wrote: - Original Message - From: Benjamin Meyer b...@meyerhome.net To: WebKit Development webkit-dev@lists.webkit.org Sent: Sunday, July 05, 2009 11:25 PM Subject: Re: [webkit-dev] Git Familiarity (was ChangeLog) At least on Windows I use mysygit myself (http://code.google.com/p/msysgit/ ) From the project description: Historically, Git on Windows was only officially supported using Cygwin. To help make a native Windows version, this project was started, based on the fork. Still has the following problems: 1. No Windows integrated UI. Windows is very UI driven, and all of the development tools are UI based. Why should I open up a command line to do VCS stuff? I don't have to open up a command line now. 2. No Visual Studio integration. Subversion not only has TortoiseSVN, but there's AnkhSVN that lets you manage it entirely inside Visual Studio. I'd vote against any VCS that doesn't match features provided by Subversion on all 3 platforms (Mac, Linux, and Windows). *nix devs might think opening up a command line to do some development is fine, but Windows devs aren't nearly as willing. Why, when all of the functionality is available from a UI? I can't think of any major feature of Subversion that isn't available from TortoiseSVN. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git Familiarity (was ChangeLog)
On Mon, Jul 06, 2009 at 01:22:26AM -0400, Justin Haygood wrote: Still has the following problems: 1. No Windows integrated UI. Windows is very UI driven, and all of the development tools are UI based. Why should I open up a command line to do VCS stuff? I don't have to open up a command line now. http://code.google.com/p/tortoisegit/ 2. No Visual Studio integration. Subversion not only has TortoiseSVN, but there's AnkhSVN that lets you manage it entirely inside Visual Studio. http://code.google.com/p/gitextensions/ Mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
