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.

Sign up for GitHub

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

Jump to bottom

Decide and document behavior of map! and broadcast! when function throws #32047

Open
chethega opened this issue May 16, 2019 · 2 comments
Open

Decide and document behavior of map! and broadcast! when function throws #32047

chethega opened this issue May 16, 2019 · 2 comments
Labels
broadcast Applying a function over a collection docs This change adds or pertains to documentation

Comments

@chethega
Copy link
Contributor

Currently, broadcast! into BitArray caches some results and only writes them back later. If the function that is broadcast happens to throw, then we leave the destination in an undefined state.

I think this is fine, and we should decide and document that map!, broadcast!, etc leave the destination with undefined contents if the mapped / broadcast function happens to throw. If we tried to make any guarantees we would prevent a lot of possible optimizations (e.g. hypothetical future multi-threaded implementations, caching without exception handlers, etc).
@chethega chethega mentioned this issue May 16, 2019
Merged
@vchuravy
Copy link
Member

I think we should document that side-effect may happen in any order. We might even want to state that they may happen in parallel.

@fredrikekre fredrikekre added broadcast Applying a function over a collection docs This change adds or pertains to documentation labels May 16, 2019
@mbauman
Copy link
Member

mbauman commented May 16, 2019 •
edited
Loading

Agreed. We're already doing this with BitArrays and other packages are taking it even further with GPU kernels and such. We do need to document it, though, and I agree we should go beyond errors: side-effects will happen, but their order is not guaranteed. A good example of this behavior is:

A .= rand.()

That should initialize all elements of A to be drawn from a random distribution, but the order in which they pull from the RNG is arbitrary.

vtjnash added a commit that referenced this issue Nov 4, 2023
@chethega @vtjnash
changed broadcast! into bitarray algorithm (#32048)
f3ae44c 
Cf
https://discourse.julialang.org/t/broadcast-vs-slow-performance-allocations/24259/6
for some more discussion and
#32047 for the question of
validity in view of exceptions.

Before:
```
julia> using BenchmarkTools, Random
julia> y=1; xsmall=[1]; Random.seed!(42); xlarge=rand(1:4, 100_003);
julia> @Btime broadcast(==, $xsmall, $y); @Btime  broadcast(==, $xlarge, $y); @show hash(broadcast(==, xlarge, y).chunks);
  860.500 ns (3 allocations: 4.31 KiB)
  152.971 μs (3 allocations: 16.59 KiB)
hash((broadcast(==, xlarge, y)).chunks) = 0xaa3b5a692968e128
```
After:
```
julia> @Btime broadcast(==, $xsmall, $y); @Btime  broadcast(==, $xlarge, $y); @show hash(broadcast(==, xlarge, y).chunks);
  65.466 ns (2 allocations: 128 bytes)
  42.927 μs (2 allocations: 12.41 KiB)
hash((broadcast(==, xlarge, y)).chunks) = 0xaa3b5a692968e128
```

Co-authored-by: Jameson Nash <vtjnash@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
broadcast Applying a function over a collection docs This change adds or pertains to documentation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@vchuravy @mbauman @fredrikekre @chethega