Skip to content
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

Deprecate vectorized & in favor of compact broadcast syntax #19709

Closed
wants to merge 1 commit into from

Conversation

Sacha0
Copy link
Member

@Sacha0 Sacha0 commented Dec 24, 2016

This pull request deprecates all remaining vectorized & methods in favor of compact broadcast syntax. Best!

@Sacha0 Sacha0 added the broadcast Applying a function over a collection label Dec 25, 2016
@Sacha0 Sacha0 added this to the 0.6.0 milestone Dec 25, 2016
@@ -1291,11 +1291,6 @@ for f in (:div, :mod)
end
end

function (&)(B::BitArray, x::Bool)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will lead to a performance regression, since the corresponding .& version will have to check each element?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see the discussion in #17623, specifically #17623 (comment), #17623 (comment), and #17623 (comment). Best!

@stevengj
Copy link
Member

Might be better to hold off on these boolean-operator deprecations for BitArray in 0.6, to be conservative about the potential performance implications.

@Sacha0
Copy link
Member Author

Sacha0 commented Dec 27, 2016

Might be better to hold off on these boolean-operator deprecations for BitArray in 0.6, to be conservative about the potential performance implications.

Thinking along similar lines, I planned to restore the efficient vectorized &, |, and xor methods as broadcast specializations so that they remain accessible without stalling deprecation of the vectorized methods. Would you be on board with that approach as well? Thanks!

@stevengj
Copy link
Member

stevengj commented Dec 28, 2016

I thought about that, but the problem as usual is that specialized broadcast methods often won't be called due to fusion.

On the other hand, in cases where fusion occurs, you probably don't want the specialized method. For example, on my machine, if I compare

f(A) = (A .> 0.3) .& (A .< 0.7)
g(A) = (A .> 0.3) & (A .< 0.7)

then f is about 30% faster than g for A = rand(10^5) (and allocates less memory) due to fusion, even though g calls the optimized &.

So I guess it makes sense to deprecate & etc., define specialized broadcast methods, and maybe revisit this whole issue later if there are further performance improvements to be had.

(Specialized broadcast methods can also be a bit of a pain because they often introduce method ambiguities, e.g. with the sparse methods.)

@Sacha0
Copy link
Member Author

Sacha0 commented Dec 30, 2016

Cheers, seems we're on the same page. Writing performant generic broadcast methods for BitArray (if necessary) seems the best long-run approach (e.g. as we've done for sparse vectors/matrices); broadcast specializations merely serve as a stopgap that teaches the new pattern while providing access to the former performance. Best!

@Sacha0
Copy link
Member Author

Sacha0 commented Dec 31, 2016

Subsumed by #19791.

@Sacha0 Sacha0 closed this Dec 31, 2016
@Sacha0 Sacha0 deleted the devecand branch December 31, 2016 05:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
broadcast Applying a function over a collection
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants