Re: [webkit-dev] Importing W3C tests to webkit

[Dirk Pranke]

On Wed, May 23, 2012 at 2:59 PM, Jacob Goldstein  wrote:
> As a side note to this discussion, there is talk in the W3C community
> regarding their test approval process.  At the recent working group
> meetings in Germany the idea was floated to simply approve all tests that
> are currently waiting for review (and doing this going forward, e.g. no
> longer requiring approval upon submission).
>
> Apparently, not enough people are reviewing tests, and as a result, tests
> can linger for months (or longer) before ever being looked at.  Once
> browser vendors start implementing features, associated tests will be
> revisited for that area.
>
> This has by no means been decided, but something we should consider if it
> ultimately does come to fruition.  If W3C tests are no longer
> reviewed, this would mean importing tests without any knowledge of their
> accuracy - though that will still allow us to catch regressions.

Ick :(. I suppose if the test suites are mostly coming from
established browser vendors or other trusted sources (who have been
running them on their own browsers for a while) this isn't so bad, but
it would be nice to see the suites get vetted somehow prior to them
getting blessed by the w3c. Levels of approval, or something?

> Dirk, I've updated the process on the Wiki page with the feedback you
> provided.  I hope I captured it all - I included everything that appeared
> to have agreement between you and Ryosuke.  Feel free to modify it
> directly if I missed anything, or let me know and I can refine it further.

It looks much closer to what I'd like, thanks! I'll probably modify it
a bit and/or send you some suggestions offlist for some minor things.

The one major issue I still have that I wouldn't want to just
add/sneak into the wiki, is that I still don't see much of a
discussion for how we identify duplicate tests.

The mindset I would prefer would be that, for a given test suite, the
person or persons importing the test suite should have to start by
identifying which existing tests we have for similar functionality,
and produce lists of which existing tests look like they are
duplicates and should be remvoed, which tests we have that should be
submitted back to the w3c for future inclusion, and which tests are
clearly webkit-specific and should be kept but identified as clearly
webkit-specific.

For example, if we import a "flexbox" test suite from css3, we should
default to removing fast/flexbox (and possibly also
ietestcenter/css3/flexbox).

[ This is a purely hypothetical example (I know nothing about these
test suites). I wish to re-emphasize that we will have to look at
these things on a case-by-case basis. ]

I have no idea how much work we'd be asking the importer to undertake,
but that's kinda the point. If we don't ask the importer to de-dup
things, who is realistically going to de-dup them later?

What do others thinks, is this too much to ask? If it is, how do we
avoid incurring further "test debt" over time?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Maciej Stachowiak]

On May 23, 2012, at 3:13 PM, Dirk Pranke  wrote:

> On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak  wrote:
>> 
>> Are you concerned just about the actual pixel results or also about keeping 
>> render tree dumps up to date?
> 
> Both are more maintenance than a text-only test. In my experience,
> maintaining pixel tests is more expensive, but I also don't have any
> experience maintaining a non-pixel-test-running port.

There are occasional changes that require rebaselining a very large number of 
render tree dumps. In my experience, this happens much less often than the 
frequency at which Chromium ports update pixel results, by several orders of 
magnitude.

> 
>> We can address the pixel result issue by introducing a new test that dumps 
>> its render tree but does not do pixel testing.
> 
> Yes, it might make sense to do this (although it's not obvious to me
> how we would do this without modifying the test sources). Maybe we
> would need to maintain a separate manifest or some other list
> somewhere to indicate which dirs or tests should include pixel
> results.

The quick and dirty way would be to add a SkipPixel directive (or whatever) to 
TestExpectations.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Dirk Pranke]

On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak  wrote:
>
> Are you concerned just about the actual pixel results or also about keeping 
> render tree dumps up to date?

Both are more maintenance than a text-only test. In my experience,
maintaining pixel tests is more expensive, but I also don't have any
experience maintaining a non-pixel-test-running port.

> We can address the pixel result issue by introducing a new test that dumps 
> its render tree but does not do pixel testing.

Yes, it might make sense to do this (although it's not obvious to me
how we would do this without modifying the test sources). Maybe we
would need to maintain a separate manifest or some other list
somewhere to indicate which dirs or tests should include pixel
results.

> I think there is a high value to importing standards test suites wholesale, 
> even if they overlap with our existing coverage. Picking and choosing subsets 
> makes things  more complicated. If there are significant externalities to 
> adding particular kinds of tests, I would prefer we mitigate those 
> externalities rather than run fewer tests.

I'm not a fan of importing subsets of tests :).

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Jacob Goldstein]

On 5/23/12 2:30 PM, "Maciej Stachowiak"  wrote:

>
>On May 23, 2012, at 2:16 PM, Dirk Pranke  wrote:
>
>> On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa  wrote:
> The only sane argument I've heard so far to gate pixel tests is that
>the
> correctness of such tests need to be manually inspected, which
>requires
> a
> lot of manual labor and is very error prone.
 
 I'm assuming the above includes the ongoing maintenance cost of
 keeping pixel tests up to date, as well as the cost at the initial
 checkin.
>>> 
>>> I'm not concerned of those. Once the correct expected result is
>>>checked in,
>>> it's pretty easy to rebaseline tests per rendering engine changes
>>>assuming
>>> people who are rebaselining tests know what they're doing.
>> 
>> You should be concerned; keeping pixel tests up-to-date is clearly a
>> non-zero cost that only the chromium port thus far has been willing to
>> bear, and I suspect that the cost of updating baselines is
>> substantially higher than the cost of the initial review over time
>> (since it's a recurring cost).
>
>Are you concerned just about the actual pixel results or also about
>keeping render tree dumps up to date? We can address the pixel result
>issue by introducing a new test that dumps its render tree but does not
>do pixel testing.
>
>I think there is a high value to importing standards test suites
>wholesale, even if they overlap with our existing coverage. Picking and
>choosing subsets makes things  more complicated. If there are significant
>externalities to adding particular kinds of tests, I would prefer we
>mitigate those externalities rather than run fewer tests.


As a side note to this discussion, there is talk in the W3C community
regarding their test approval process.  At the recent working group
meetings in Germany the idea was floated to simply approve all tests that
are currently waiting for review (and doing this going forward, e.g. no
longer requiring approval upon submission).

Apparently, not enough people are reviewing tests, and as a result, tests
can linger for months (or longer) before ever being looked at.  Once
browser vendors start implementing features, associated tests will be
revisited for that area.

This has by no means been decided, but something we should consider if it
ultimately does come to fruition.  If W3C tests are no longer
reviewed, this would mean importing tests without any knowledge of their
accuracy - though that will still allow us to catch regressions.



Dirk, I've updated the process on the Wiki page with the feedback you
provided.  I hope I captured it all - I included everything that appeared
to have agreement between you and Ryosuke.  Feel free to modify it
directly if I missed anything, or let me know and I can refine it further.


Jacob


>
>Regards,
>Maciej
>
>___
>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] Importing W3C tests to webkit

[Maciej Stachowiak]

On May 23, 2012, at 2:16 PM, Dirk Pranke  wrote:

> On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa  wrote:
 The only sane argument I've heard so far to gate pixel tests is that the
 correctness of such tests need to be manually inspected, which requires
 a
 lot of manual labor and is very error prone.
>>> 
>>> I'm assuming the above includes the ongoing maintenance cost of
>>> keeping pixel tests up to date, as well as the cost at the initial
>>> checkin.
>> 
>> I'm not concerned of those. Once the correct expected result is checked in,
>> it's pretty easy to rebaseline tests per rendering engine changes assuming
>> people who are rebaselining tests know what they're doing.
> 
> You should be concerned; keeping pixel tests up-to-date is clearly a
> non-zero cost that only the chromium port thus far has been willing to
> bear, and I suspect that the cost of updating baselines is
> substantially higher than the cost of the initial review over time
> (since it's a recurring cost).

Are you concerned just about the actual pixel results or also about keeping 
render tree dumps up to date? We can address the pixel result issue by 
introducing a new test that dumps its render tree but does not do pixel testing.

I think there is a high value to importing standards test suites wholesale, 
even if they overlap with our existing coverage. Picking and choosing subsets 
makes things  more complicated. If there are significant externalities to 
adding particular kinds of tests, I would prefer we mitigate those 
externalities rather than run fewer tests.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Dirk Pranke]

On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa  wrote:
>> > The only sane argument I've heard so far to gate pixel tests is that the
>> > correctness of such tests need to be manually inspected, which requires
>> > a
>> > lot of manual labor and is very error prone.
>>
>> I'm assuming the above includes the ongoing maintenance cost of
>> keeping pixel tests up to date, as well as the cost at the initial
>> checkin.
>
> I'm not concerned of those. Once the correct expected result is checked in,
> it's pretty easy to rebaseline tests per rendering engine changes assuming
> people who are rebaselining tests know what they're doing.

You should be concerned; keeping pixel tests up-to-date is clearly a
non-zero cost that only the chromium port thus far has been willing to
bear, and I suspect that the cost of updating baselines is
substantially higher than the cost of the initial review over time
(since it's a recurring cost).

We only have to ask Emil and Levi what the cost of updating all of the
pixel tests were for the subpixel layout test change, or ask the skia
guys how many bug fixes they're reluctant to make because of the cost
of reviewing literally thousands of images that change
inconsequentially for empirical evidence for this.

>> There is also the fact that the more tests we have, the more tests we
>> have to run, and increasing cycle time by itself is a cost to developer
>> productivity.
>
> Sure, but I don't think that's a valid argument for not adding tests
> especially since there is no way for us to mechanically test whether two
> tests test the same set of features or not (this is an intractable problem
> even in its limited form and an undecidable one in its most general form).

At some point adding more tests will introduce a declining marginal
rate of return in finding more bugs; this is a truism of software
development, and is why *all* software testing efforts stop at some
point (ignoring formal proofs of completeness in model checkers).
Either you don't think this is true, or you think this is true and
we're just not at that point yet.

If you think the latter then we agree, but I don't understand why you
are arguing as if you believe the former.

To repeat myself, I have never said that we shouldn't ever add more
tests, just that we should have a rational process for doing so that
includes looking at what overlap we have with the existing tests and
making sure that adding more tests delivers value. Since you agree at
least that we shouldn't be adding duplicate tests, you clearly agree
with this to some degree, so I'm not sure if you and I have any real
disagreements or if we're just talking past each other.

> Also, using ref test or pixel test, etc... doesn't change the cycle time
> significantly so I don't understand what your argument is. Or are you
> suggesting that non-ref tests are somehow more redundant than ref tests?
> (please give us why).

I am saying that I believe that adding pixel tests incur more cost on
the project than adding ref tests, and since all testing is about cost
vs. benefit, you need to be more careful when adding pixel tests.
Since we actively discourage people from writing pixel tests in favor
of text-only or ref tests, I hardly think this is a controversial
stance.

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Ryosuke Niwa]

On Wed, May 23, 2012 at 1:25 PM, Dirk Pranke  wrote:
>
> Not so: if the tests we had had 100% coverage, then importing more
> tests would buy us nothing, but getting rid of the existing tests
> would be quite unfortunate.


We certainly don't have 100% test coverage.

Clearly adding tests incurs some costs and probably provides some benefit;
> the question is when does the cost exceed the benefit?
>

Doing anything incurs some cost. In fact, not adding a test itself incurs a
risk cost of potentially taking regressions in the future that could have
been caught by the test.

As I am not against importing more tests per se, I think this only
> makes sense to evaluate on a case-by-case basis.
>

Sure. We shouldn't be importing tests that are obviously duplicates of our
existing tests.

> The only sane argument I've heard so far to gate pixel tests is that the
> > correctness of such tests need to be manually inspected, which requires a
> > lot of manual labor and is very error prone.
>
> I'm assuming the above includes the ongoing maintenance cost of
> keeping pixel tests up to date, as well as the cost at the initial
> checkin.


I'm not concerned of those. Once the correct expected result is checked in,
it's pretty easy to rebaseline tests per rendering engine changes assuming
people who are rebaselining tests know what they're doing.

There is also the fact that the more tests we have, the more tests we
> have to run, and increasing cycle time by itself is a cost to developer
> productivity.


Sure, but I don't think that's a valid argument for not adding tests
especially since there is no way for us to mechanically test whether two
tests test the same set of features or not (this is an intractable problem
even in its limited form and an undecidable one in its most general form).

Also, using ref test or pixel test, etc... doesn't change the cycle time
significantly so I don't understand what your argument is. Or are you
suggesting that non-ref tests are somehow more redundant than ref tests?
(please give us why).

Of course, it's also potentially the case that
> we have to update tests from time to time, although this doesn't
> happen often.
>

Because the current process is broken :) In the ideal world, we would be
updating our copy of W3C tests every so often (e.g. every month or so).

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Jacob Goldstein]

Dirk, my apologies, I was on travel the week you replied and missed your
message.  I found it and will review / update now.



On 5/23/12 1:25 PM, "Dirk Pranke"  wrote:

>On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa  wrote:
>> As I have said in the past, we should just import all tests, and treat
>> non-text, non-ref tests as pixel tests. If we wanted to reduce the
>>number of
>> pixel tests we import, then we should submit those patches to W3C
>>instead of
>> directly submitting them to WebKit.
>>
>> In general, I don't buy the argument that adding more pixel tests incurs
>> more cost than the benefit we get from importing the tests. If that
>>were the
>> case, we can just get rid of the existing pixel tests we have.
>>
>
>Not so: if the tests we had had 100% coverage, then importing more
>tests would buy us nothing, but getting rid of the existing tests
>would be quite unfortunate. Clearly adding tests incurs some costs and
>probably provides some benefit; the question is when does the cost
>exceed the benefit?
>
>As I am not against importing more tests per se, I think this only
>makes sense to evaluate on a case-by-case basis.
>
>> The only sane argument I've heard so far to gate pixel tests is that the
>> correctness of such tests need to be manually inspected, which requires
>>a
>> lot of manual labor and is very error prone.
>>
>
>I'm assuming the above includes the ongoing maintenance cost of
>keeping pixel tests up to date, as well as the cost at the initial
>checkin.
>
>There is also the fact that the more tests we have, the more tests we
>have to run, and increasing cycle time by itself is a cost to
>developer productivity. Of course, it's also potentially the case that
>we have to update tests from time to time, although this doesn't
>happen often.
>
>Jacob, I gave you a bunch of feedback not long after you published the
>initial writeup, but it doesn't look like any of that has been
>incorporated?
>
>-- Dirk

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Dirk Pranke]

On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa  wrote:
> As I have said in the past, we should just import all tests, and treat
> non-text, non-ref tests as pixel tests. If we wanted to reduce the number of
> pixel tests we import, then we should submit those patches to W3C instead of
> directly submitting them to WebKit.
>
> In general, I don't buy the argument that adding more pixel tests incurs
> more cost than the benefit we get from importing the tests. If that were the
> case, we can just get rid of the existing pixel tests we have.
>

Not so: if the tests we had had 100% coverage, then importing more
tests would buy us nothing, but getting rid of the existing tests
would be quite unfortunate. Clearly adding tests incurs some costs and
probably provides some benefit; the question is when does the cost
exceed the benefit?

As I am not against importing more tests per se, I think this only
makes sense to evaluate on a case-by-case basis.

> The only sane argument I've heard so far to gate pixel tests is that the
> correctness of such tests need to be manually inspected, which requires a
> lot of manual labor and is very error prone.
>

I'm assuming the above includes the ongoing maintenance cost of
keeping pixel tests up to date, as well as the cost at the initial
checkin.

There is also the fact that the more tests we have, the more tests we
have to run, and increasing cycle time by itself is a cost to
developer productivity. Of course, it's also potentially the case that
we have to update tests from time to time, although this doesn't
happen often.

Jacob, I gave you a bunch of feedback not long after you published the
initial writeup, but it doesn't look like any of that has been
incorporated?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Jacob Goldstein]

I agree.  If nothing else, getting W3C tests into the WebKit repository will 
help catch regressions.

From: Ryosuke Niwa mailto:rn...@webkit.org>>
To: Jacob Goldstein mailto:jac...@adobe.com>>
Cc: WebKit Development 
mailto:webkit-dev@lists.webkit.org>>
Subject: Re: [webkit-dev] Importing W3C tests to webkit

As I have said in the past, we should just import all tests, and treat 
non-text, non-ref tests as pixel tests. If we wanted to reduce the number of 
pixel tests we import, then we should submit those patches to W3C instead of 
directly submitting them to WebKit.

In general, I don't buy the argument that adding more pixel tests incurs more 
cost than the benefit we get from importing the tests. If that were the case, 
we can just get rid of the existing pixel tests we have.

The only sane argument I've heard so far to gate pixel tests is that the 
correctness of such tests need to be manually inspected, which requires a lot 
of manual labor and is very error prone.

For script-based tests that print PASS/FAIL, it seems better to just check in 
*-expected-failure.txt or even -expected.txt files because we'll see PASS/FAIL 
in the expected tests themselves.

- Ryosuke

On Wed, May 23, 2012 at 10:26 AM, Jacob Goldstein 
mailto:jac...@adobe.com>> wrote:
At the WebKit contributor's meeting in April, we discussed a process for 
importing third party tests into the WebKit repository (specifically, from the 
W3C test repository).

I documented the process that we came up with at the meeting on the WebKit 
wiki, here:
http://trac.webkit.org/wiki/ImportingThirdPartyTests

It would be great if we could get some feedback on this process.

Once we can finalize the details for how this should function, the effort can 
proceed - scripts can be written to help automate the effort and an actual 
import of select W3C test suites can be performed.

___
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

[webkit-dev] scrollInToView(true) have different behavior on WebKit and Firefox

[Hugo Parente Lima]

Hi,

While taking a look into bug 83419 (about fast/transforms/scrollIntoView-
transformed.html) I faced with the following render issue:

When using Element::scrollInToView(true) on blocking elements that have bigger 
child elements with margins webkit and Firefox show different results.

I attached the html file [1] and the render results on Firefox[2] and WebKit[3] 
into the bug, so what's the correct result?

IMO the Firefox behavior seems right, but before trying to fix anything better 
to know if a consensus on what is right exists.

The scrollInToView spec[4] says:

"If the align to top flag is set align the top of the border box of the element 
to be scrolled into view with the top of the scrolling box."

[1] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143619
[2] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143620
[3] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143621
[4] http://dev.w3.org/csswg/cssom-view/

Regards,
Hugo Parente Lima

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Importing W3C tests to webkit

[Ryosuke Niwa]

As I have said in the past, we should just import all tests, and treat
non-text, non-ref tests as pixel tests. If we wanted to reduce the number
of pixel tests we import, then we should submit those patches to W3C
instead of directly submitting them to WebKit.

In general, I don't buy the argument that adding more pixel tests incurs
more cost than the benefit we get from importing the tests. If that were
the case, we can just get rid of the existing pixel tests we have.

The only sane argument I've heard so far to gate pixel tests is that the
correctness of such tests need to be manually inspected, which requires a
lot of manual labor and is very error prone.

For script-based tests that print PASS/FAIL, it seems better to just check
in *-expected-failure.txt or even -expected.txt files because we'll see
PASS/FAIL in the expected tests themselves.

- Ryosuke

On Wed, May 23, 2012 at 10:26 AM, Jacob Goldstein  wrote:

> At the WebKit contributor's meeting in April, we discussed a process for
> importing third party tests into the WebKit repository (specifically, from
> the W3C test repository).
>
> I documented the process that we came up with at the meeting on the WebKit
> wiki, here:
> http://trac.webkit.org/wiki/ImportingThirdPartyTests
>
> It would be great if we could get some feedback on this process.
>
> Once we can finalize the details for how this should function, the effort
> can proceed - scripts can be written to help automate the effort and an
> actual import of select W3C test suites can be performed.
>
> ___
> 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

[webkit-dev] Importing W3C tests to webkit

[Jacob Goldstein]

At the WebKit contributor's meeting in April, we discussed a process for 
importing third party tests into the WebKit repository (specifically, from the 
W3C test repository).

I documented the process that we came up with at the meeting on the WebKit 
wiki, here:
http://trac.webkit.org/wiki/ImportingThirdPartyTests

It would be great if we could get some feedback on this process.

Once we can finalize the details for how this should function, the effort can 
proceed - scripts can be written to help automate the effort and an actual 
import of select W3C test suites can be performed.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Announcing the New England Browser Authors Meetup

[Adam Treat]

Hey, I'd love to attend but I'm going to be away on vacation at that time.  
Maybe next time.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Gavin Peters (蓋文彼紱斯) [gav...@webkit.org]
Sent: Friday, May 18, 2012 3:46 AM
To: WebKit Development
Subject: Re: [webkit-dev] Announcing the New England Browser Authors Meetup

Here is the CORRECT attendee list and agenda: 
https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0

Apologies for getting it wrong in the announcement!


On Fri, May 18, 2012 at 4:38 PM, Gavin Peters (蓋文彼紱斯) 
mailto:gav...@webkit.org>> wrote:
Hi!

Are you a webkit contributor or other browser author in New England?  If so, 
read on, and consider coming to a half day unconference later this month on the 
web platform, to informally share your work, talk about the web platform, and 
meet other people working in browsers in the area!

On 5/29, for a half day (starting just after lunch), authors of web browsers 
are encouraged to come to (LOCATION TBA, NEAR MIT, CAMBRIDGE) for an 
unconference of browser authors.  We already have confirmed attendance from 
webkit contributors, mozilla committers, and chromium contributors who live and 
work in the New England area.  If you do related work, consider coming; we'd 
like to hear what you are doing that's interesting.  Don't prepare too long 
slide decks, but do prepare opinions about what browsers are getting right and 
getting wrong these days.

Here's the attendee list, add yourself at the bottom: 
https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0
Here's the session list, please sign up to give one, or ask for one here: 
https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0

When we start at 1pm, we'll go over the session list and assign slots.  So come 
ready to vote on what you like, too!

- Gavin


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DFG optimizations

[blake fiddler]

Hi,
Have you some news about dfg optimisations? what are you planing, what have
you now or what is your current work ?

Currently we do not have either LICM, or loop peeling, or GCSE. We do have
> a patch that implements LICM, but we are letting it simmer for now because
> under the current DFG IR, it is somewhat of a complicated beast. My main
> concern is just bug tail, due to the various stunts that the current LICM
> patch has to do to fool the DFG into moving code between basic blocks.
>
> We're fixing that by steadily moving the DFG IR towards SSA. Once we
> finish that, I think we'll implement either LICM or peeling+GCSE based on
> whatever appears to be the simplest. We already know that LICM is a pure
> performance win; but on the other hand, GCSE is likely to be more generic.
> I tend to think that extending our current CSE framework to support some
> maximally-profitable subset of GCSE will not be terribly difficult.
>
> We don't currently have PRE. It's not on my short list of optimizations to
> implement.
>
> But if we wanted to go down that route, it might be interesting to
> consider something like Van Drunen's GVN-PRE [1]. I have already been
> thinking about implementing GVN; maybe just going straight for GVN-PRE
> would turn out to be easy enough. But it goes without saying that GVN alone
> is a dead-simple optimization compared to Van Drunen's work, and, even
> according to his performance results, PRE is a *tiny* win over simpler
> redundancy elimination optimizations.
>
> -Filip
>
> [1] ftp://ftp.cs.purdue.edu/pub/hosking/papers/a-ssapre.pdf
>
>
>
> On Mar 25, 2012, at 4:59 PM, Nare Karapetyan wrote:
>
> > HI!
> >
> > There is a discussion about LICM implementation in DFG in one of
> previous posts.
> > There it was said that the developers had not decided yet which
> optimization to do: LICM or loop peeling with global CSE.
> > So is there any progress in this direction?
> >
> >
> > And about CSE, does it include the partial redundancy elimination (PRE)?
> >
> >
> > --
> >
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20120325/a57e47fa/attachment-0001.html
> >
>
> --
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> End of webkit-dev Digest, Vol 82, Issue 38
> **
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev