In-place "bang" versions of functions.

[ntessore]

This works great. Because I do not need the arrays after calculations, I added in-place "bang" versions of the functions. This keeps allocations down.

julia> using Accelerate

julia> X = rand(1000000);

julia> @time Y = Accelerate.log(X);
elapsed time: 0.006102273 seconds (8013904 bytes allocated)

julia> @time Accelerate.log!(X);
elapsed time: 0.006830005 seconds (36072 bytes allocated)

julia> X == Y
true

[simonbyrne]

Thanks, though I might modify this slightly: what if we were to use the same format as VML.jl, which uses an explicit output array: f!(out, args...)?

This can then also be used for 2-argument functions (pow, atan2).

[ntessore]

Yes, sounds like a good idea to have a unified interface. There is the caveat that I did not find any reference mentioning that it's ok to pass the input as output array.

[ntessore]

Actually it would be great to be as compatible as possible with similar frameworks, so that one might use one or the other as a drop-in replacement.

[simonbyrne]

Okay, I've just pushed a change, let me know what you think. I'll close this for now.

[ntessore]

Looks good. (There's a missing closing parenthesis on line 33.) Thanks!

[simonbyrne]

ah, thanks!

[ntessore]

How do you feel about not checking the input sizes? I feel it could be up to the user to make sure everything's fine when using a bang function.

[simonbyrne]

Hmm, I'm slightly hesitant, as it is only 1 check for the whole array, and it is so easy to get these things wrong. It would be useful to know the overhead: would you be able to profile it with and without the check?

Alternatively, it would be nice if there was a way to use the @inbounds macro for this: maybe once JuliaLang/julia#8227 gets sorted out?

[ntessore]

Just using my code

• without size checks

elapsed time: 34.14401566 seconds (4363129960 bytes allocated, 5.54% gc time)

• with size checks

elapsed time: 36.063292182 seconds (5379215972 bytes allocated, 6.19% gc time)

and these are consistent across multiple runs. So it seems to be a 5% - 10% effect, which is not much. I suppose having a @inbounds version eventually would be ideal.

[simonbyrne]

Hmm, that's more than I thought it would be, it also seems like a lot of extra allocation. Maybe I'll remove the checks for the time being and stick a big warning in the docs.