-
Notifications
You must be signed in to change notification settings - Fork 326
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
5) rust: use AsRef/AsMut in compute interface #1087
Conversation
f8efbfe
to
f6071ce
Compare
@sletz this one is also ready |
@@ -122,10 +122,7 @@ travis: | |||
######################################################################### | |||
# automatic github action test | |||
github_action: | |||
$(MAKE) -f Make.rust outdir=rust/osec CARGOOPTIONS="" FAUSTOPTIONS="-I ../../libraries/ -double -os -ec -rnt -a archs/rust/architecture_osecrnt.rs" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you remove the tests here ? (I think it makes sense to keep all of them)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rational was to only keep tests that relate to a change in ci. I don't have a strong opinion on this.
You wrote this change is fully backwards compatible but |
I made a mistake before because i thought i already implemented the most general interface. |
OK, |
I think i will update the PR one more time to match the function signature as i updated it in the pr description above. |
Sure I can look into this in a bit more detail, but will probably only get to it next weekend. |
ef18cd4
to
2d88c57
Compare
i just realized the function signature can be simplified with the same meaning:
I added a commit with this change. |
I had a closer look now into this, and as far as I can see this should be all fine! I was re-rerunning all my benchmarks before and after that change to get a better feeling of how the generated code looks, and if it has an impact on performance. For what I've seen it all looks fine to me, and I would assume that it likely produces the same assembly anyway. |
@sletz @bluenote10 thanks for having a look. I am also preparing benchmarks, but havnt cleaned them up. |
Should I wait for that before merging ? |
@sletz no need to wait for publishable benchmarks. |
instead of & or &mut so that &mut can be passed as input i changed some architecture files to cover different ways of passing buffers to compute
Merged, thanks. |
the current compute function signature looks like this:
this prevents us from passing a mutable reference as input buffer slice.
in the case one wants to chain dsps where the outputs of one dsp are used as the input of another it would be good if one can pass pass same slice that is used as the output of one dsp as input of another. but in that case one would pass a mutable reference. which is not possible with the current function signature.
this pr changes the functions to be more general. so that one can pass a mutable reference to the the input.
The new now looks like this:
this change should be fully backwards compatible. (as first attemps have shown that needs some review and improvements of testing)
Because I found out that my earlier introduced compute_array interface is not contributing to the performance i removed it here again because it would make this change more complicated.