[webkit-dev] Running W3C tests using wptserve
Hi all, W3C wptserve server is now used to serve all tests under LayoutTests/imported/w3c/web-platform-tests. Currently, only two tests are run within that folder: - web-platform-tests/domparsing/DOMParser-parseFromString-html.html - web-platform-tests/domparsing/insert-adjacent.html Should there be any issus with those tests, the problem may be related to running wptserve. The wptserve server log is dumped in the the layout-test-results folder. Please let me know if you see any such issue, particularly on WebKit bots. Next planned steps in that area are: 1. Update Tools/Scripts/import-w3c-tests according this new set-up 2. Migrate already imported W3C WPT tests within LayoutTests/imported/w3c/web-platform-tests 3. Further improve the tools to make import of new tests and re-import existing tests as easy as possible Any suggestion welcome. Thanks, youenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for intuition: should switch statements be faster for the default case, or the explicit cases?
I’m having fun calculating the average performance of different switch
implementations, to be used in the DFG JIT and in our inline caching logic.
I’ve got two possible implementations that appear to be very nearly optimal
assuming the capabilities of the hardware we care about and other constraints
of our JITs. Both implementations involve a tree of branches, and they both
come into play in exactly those cases where a tree of branches is already known
to be less expensive than a lookup table.
Here’s the basic switch JIT algorithm:
jitSwitchRecurse(cases) {
if (cases.size N) {
for (C in cases) {
emit code that checks, and executes, C
}
fall through to default
} else {
// Note that this only divides-and-conquers and does not explicitly
check and execute the median case; I’ve calculated that this is the superior
choice. You can follow along with this here:
https://bugs.webkit.org/show_bug.cgi?id=141046
let M = right-median case in cases // for even sizes of cases, pick the
greater of the two medians; for odd cases, pick either the median or the value
to the right of the median at random. the point is to split the list into two
equal-sized lists
lessThanJump = emit lessThan comparison against M
jitSwitchRecurse(those cases that are = M)
lessThanJump.link()
jitSwitchRecurse(those cases that are M)
}
The two implementations of this algorithm that I’m picking between either have
N = 2 or N = 3 - i.e. we either stop divide-and-conquering once we have two
remaining cases, or when we have 3 remaining cases. Those two versions are the
most optimal for a variety of reasons, but neither is obviously better than the
other: N = 3 is more optimal for the case that the switch bottoms out in one of
the cases. N = 2 is more optimal if the switch bottoms out in the default
(“fall through”) case. N = 2 is significantly more optimal for default: it
usually results in two fewer comparisons before getting to default. N = 3 is
slightly more optimal for the non-default (i.e. hitting some explicit case)
case: it usually results in one fewer comparisons before getting to some case.
We could have a switch emitter that selects the strategy based on profiling
(did we hit the default case, or not?), but that isn’t always available and it
might be overkill. We could tune this for benchmarks, and I might do some of
that. But I’m curious what other people’s intuitions and experiences are: do
your switch statements usually hit some case, or take default? If you could
control which one was faster, which one of those would you be most likely to
make faster in the kind of code that you write?
-Filip
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for intuition: should switch statements be faster for the default case, or the explicit cases?
Ha - never mind, I was wrong. My calculation of cost for getting to default is
wrong. Please ignore.
-Filip
On Jan 31, 2015, at 12:40 PM, Filip Pizlo fpi...@apple.com wrote:
I’m having fun calculating the average performance of different switch
implementations, to be used in the DFG JIT and in our inline caching logic.
I’ve got two possible implementations that appear to be very nearly optimal
assuming the capabilities of the hardware we care about and other constraints
of our JITs. Both implementations involve a tree of branches, and they both
come into play in exactly those cases where a tree of branches is already
known to be less expensive than a lookup table.
Here’s the basic switch JIT algorithm:
jitSwitchRecurse(cases) {
if (cases.size N) {
for (C in cases) {
emit code that checks, and executes, C
}
fall through to default
} else {
// Note that this only divides-and-conquers and does not explicitly
check and execute the median case; I’ve calculated that this is the superior
choice. You can follow along with this here:
https://bugs.webkit.org/show_bug.cgi?id=141046
https://bugs.webkit.org/show_bug.cgi?id=141046
let M = right-median case in cases // for even sizes of cases, pick
the greater of the two medians; for odd cases, pick either the median or the
value to the right of the median at random. the point is to split the list
into two equal-sized lists
lessThanJump = emit lessThan comparison against M
jitSwitchRecurse(those cases that are = M)
lessThanJump.link()
jitSwitchRecurse(those cases that are M)
}
The two implementations of this algorithm that I’m picking between either
have N = 2 or N = 3 - i.e. we either stop divide-and-conquering once we have
two remaining cases, or when we have 3 remaining cases. Those two versions
are the most optimal for a variety of reasons, but neither is obviously
better than the other: N = 3 is more optimal for the case that the switch
bottoms out in one of the cases. N = 2 is more optimal if the switch bottoms
out in the default (“fall through”) case. N = 2 is significantly more
optimal for default: it usually results in two fewer comparisons before
getting to default. N = 3 is slightly more optimal for the non-default (i.e.
hitting some explicit case) case: it usually results in one fewer comparisons
before getting to some case.
We could have a switch emitter that selects the strategy based on profiling
(did we hit the default case, or not?), but that isn’t always available and
it might be overkill. We could tune this for benchmarks, and I might do some
of that. But I’m curious what other people’s intuitions and experiences are:
do your switch statements usually hit some case, or take default? If you
could control which one was faster, which one of those would you be most
likely to make faster in the kind of code that you write?
-Filip
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Painting /Drawing mechanism in webkit
Take a look at the ImageLoader class. This is involved when new bytes of an image are downloaded, and thus eventually ends up triggering the update of the relevant portion of the screen. You can use this class as a model for updating the screen once your algorithm is complete. —Myles On Jan 30, 2015, at 8:58 PM, ankit srivastav ank@gmail.com wrote: Hi All, I'm new to webkit in context of Painting/Drawing. I'm trying to use my own algo instead of Webkit defaults Bilenear Interpolation algo for interpolation of images on a webpage. That is if destImage Size is greater then SrcImage Size my algo will also come into picture alongside Webkit Bilinear. But the problem is my algo take lots of time to do the interpolation, hence the page load becomes slow. Specially for large images it takes too much time to load the image and hence the webpage. I have tried to use my algo in PlatformGraphicsContext.cpp along with Bilinear. If I'm using a separate thread to for my algo. I'm not getting the exact result i.e. once the images are drawn by Bilinear it is not been drawn after my algo. It means I need to fire an event after interpolation is done by my algo, so that images will be drawn using the data from my algo. Please if someone can tell me the Painting/Drawing mechanism of webkit it would be great. Regards, Ank ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Running W3C tests using wptserve
31 янв. 2015 г., в 11:57, youenn fablet youe...@gmail.com написал(а): Currently, only two tests are run within that folder: - web-platform-tests/domparsing/DOMParser-parseFromString-html.html - web-platform-tests/domparsing/insert-adjacent.html Should there be any issus with those tests, the problem may be related to running wptserve. I see that these tests fail on EWS, any suggestions for how to debug the issue? The EWS setup is not much different from regular bots - the biggest difference is that EWS machines have more cores. https://webkit-queues.appspot.com/results/6309998137180160 - Alexey ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Running W3C tests using wptserve
Hi Youenn, Thanks for working on this. How do we run the imported tests? Do we just use run-webkit-test passing 'imported/w3c'? Is there a way to get the percentage of W3C tests that succeed? It would be useful to have a report per directory so that we improve it over time until we reach 100%. Benjamin On 1/31/15 11:57 AM, youenn fablet wrote: Hi all, W3C wptserve server is now used to serve all tests under LayoutTests/imported/w3c/web-platform-tests. Currently, only two tests are run within that folder: - web-platform-tests/domparsing/DOMParser-parseFromString-html.html - web-platform-tests/domparsing/insert-adjacent.html Should there be any issus with those tests, the problem may be related to running wptserve. The wptserve server log is dumped in the the layout-test-results folder. Please let me know if you see any such issue, particularly on WebKit bots. Next planned steps in that area are: 1. Update Tools/Scripts/import-w3c-tests according this new set-up 2. Migrate already imported W3C WPT tests within LayoutTests/imported/w3c/web-platform-tests 3. Further improve the tools to make import of new tests and re-import existing tests as easy as possible Any suggestion welcome. Thanks, youenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
