Groups 146 of 99+ julia-users › Fast vector element-wise multiplication 15 posts by 7 authors Lionel du Peloux 10/6/15 Dear all, I'm looking for the fastest way to do element-wise vector multiplication in Julia. The best I could have done is the following implementation which still runs 1.5x slower than the dot product. I assume the dot product would include such an operation ... and then do a cumulative sum over the element-wise product. The MKL lib includes such an operation (v?Mul) but it seems OpenBLAS does not. So my question is : 1) is there any chance I can do vector element-wise multiplication faster then the actual dot product ? 2) why the built-in element-wise multiplication operator (*.) is much slower than my own implementation for such a basic linealg operation (full julia) ? Thank you, Lionel Best custom implementation : function xpy!{T<:Number}(A::Vector{T},B::Vector{T}) n = size(A)[1] if n == size(B)[1] for i=1:n @inbounds A[i] *= B[i] end end return A end Bench mark results (JuliaBox, A = randn(300000) : function CPU (s) GC (%) ALLOCATION (bytes) CPU (x) dot(A,B) 1.58e-04 0.00 16 1.0 xpy!(A,B) 2.31e-04 0.00 80 1.5 NumericExtensions.multiply!(P,Q) 3.60e-04 0.00 80 2.3 xpy!(A,B) - no @inbounds check 4.36e-04 0.00 80 2.8 P.*Q 2.52e-03 50.36 2400512 16.0 ############################################################ Tomas Lycken 10/6/15 I made some simple changes to your `xpy!`, and managed to get it to allocate nothing at all, while performing very close to the speed of `dot`. I don't know anything about e.g. `@simd` instructions, but I imagine they could help speeding this up even further. The most significant change was switching `size(A)[1]` to `size(A,1)` (and similarly for `B`) - the former has to construct and index into a tuple, while the latter won't have to do that. `length(A)` would have worked too. Notebook, also produced on JuliaBox (running Julia 0.4-rc2): http://nbviewer.ipython.org/github/tlycken/IJulia-Notebooks/blob/master/dot%20vs%20xpy%21.ipynb // T - show quoted text - Patrick Kofod Mogensen 10/6/15 Well, I guess your table pretty much shows it, right? It seems as it allocates a lot of temporary memory to carry out the calculations. - show quoted text - Christoph Ortner 10/6/15 a *= b is equivalent to a = a * b, which allocates a temporary variable I think? Try @fastmath @inbounds @simd for i=1:n A[i] *= B[i] end Christoph Ortner 10/6/15 or, possibly A[i] = A[i] * B[i] (I'm not sure whether @simd automatically translates *= to what it needs) - show quoted text - Steven G. Johnson 10/6/15 On Tuesday, October 6, 2015 at 12:29:04 PM UTC-4, Christoph Ortner wrote: a *= b is equivalent to a = a * b, which allocates a temporary variable I think? A * A only allocates memory on the heap if A is an array or something other heap-allocated datatype. For A[i] *= B[i] where A[i] and B[i] are small scalar types like Float64, no temporary is allocated, the compiler just puts the result in a register. Patrick Kofod Mogensen 10/6/15 That was supposed to be "A * B only allocates..." right? - show quoted text - Steven G. Johnson 10/6/15 On Tuesday, October 6, 2015 at 2:23:33 PM UTC-4, Patrick Kofod Mogensen wrote: That was supposed to be "A * B only allocates..." right? Yes. Steven G. Johnson 10/6/15 Note that the BLAS dot product probably uses all sorts of tricks to squeeze the last cycle of SIMD performance out of the CPU. e.g. here is the OpenBLAS ddot function for SandyBridge, which is hand-coded in assembly: https://github.com/xianyi/OpenBLAS/blob/develop/kernel/x86_64/ddot_microk_sandy-2.c Getting the last 30% or so of this performance can be extremely tricky. Lionel du Peloux 10/6/15 Thank you for all of your suggestions. The @simd macro effectively gives a (very) slightly improved performance (5%). chobb...@gmail.com Jun 20 I have the same question regarding how to calculate the entry-wise vector product and find this thread. As a novice, I wonder if the following code snippet is still the standard for entry-wise vector multiplication that one should stick to in practice? Thanks! @fastmath @inbounds @simd for i=1: n A[i] *= B[i] end - show quoted text - Chris Rackauckas Jun 20 I think that for medium size (but not large) arrays in v0.5 you may want to use @threads from the threadding branch, and then for really large arrays you may want to use @parallel. But you'd have to test some timings. - show quoted text - chobb...@gmail.com Jun 20 Thanks! I'm still using v0.4.5. In this case, is the code I highlighted above still the best choice for doing the job? - show quoted text - Chris Rackauckas Jun 20 Most likely. I would also time it with and without @simd at your problem size. For some reason I've had some simple loops do better without @simd. - show quoted text - chobb...@gmail.com Jun 20 Thanks for the confirmation! Yes, I need more tests to see what the best practice is for my particular problem. - show quoted text -