-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A test suite for fusion #229
Comments
see the comments in `fusion-test/Canary.hs` for an outline. Currently, “only” 71 tests are defined; there is more tedious work to be done if this approach is found to be good. This words towards fixing haskell#229.
I started some work in a fork, see https://github.com/haskell/vector/compare/master...nomeata:fusion-tests?expand=1 for a comparison. This is what it looks like:
It is a relatively tedious process, including having to copy all fusion-related rules, so before I continue I'd like some discussion if this is wanted. Some findings so far:
Any surprises so far? |
@dcoutts This is what we briefly talked about this morning. |
Currently, this tests fusion only against I could imagine a list with entries like
that specify the fusion-behavior of the function’s arguments and return type ( And maybe we can put these annotations somehow into the haddocks of the function, to publicly document the fusion behaviour. |
Ok, this is very cool! I’m in the middle of holidays and fam stuff but I’m
doing some prelim stuff to vector. This is a great little bunch. I’ll
carve some time soon to work through what you’ve put down.
…On Sat, Nov 17, 2018 at 9:58 AM Joachim Breitner ***@***.***> wrote:
Currently, this tests fusion only against fromList and toList, two “known
good consumers/producers”. It might be more interesting to create random
expressions and pipelines.
I could imagine a list with entries like
[ ('map, O ~> V ~> F ~> V)
, ('reverse, V ~> F)
, ('backpermute, V ~> F ~> V)
]
that specify the fusion-behavior of the function’s arguments and return
type (F = fusing vector, V = non-fusing vector, O = other type), and then
lego-like putting these pieces together to create big pipelines (or even
trees – some functions can fuse with multiple arguments) to create more
interesting test cases.
And maybe we can put these annotations somehow into the haddocks of the
function, to publicly document the fusion behaviour.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#229 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAQwh_jZAKAyHUiiugjW2mzgHX22oxiks5uwCQegaJpZM4YncTD>
.
|
i'll pull this back onto my todo list in the next month or so, |
this should be done after this current release this winter |
see the comments in `fusion-test/Canary.hs` for an outline. Currently, “only” 71 tests are defined; there is more tedious work to be done if this approach is found to be good. This words towards fixing haskell#229.
I'm copying @Bodigrim's comment #389 (comment)
|
The vector library puts in lots of effort to ensure that pipelines of vector functions fuse properly, but this is not really tested. In the similar fusion system in
text
, I found that not all intended fusion actually happened, and usedinspection-testing
to comprehensively check for fusion.I believe the vector library would benefit from this as well. I started working on such a test suite, and want to use this issue to discuss the approach.
The text was updated successfully, but these errors were encountered: