Incorrect promotion behavior of MVectors?

[danielmatz]

I'm not sure if this is intended, but it surprised me when I encountered it today:

julia> a = @MVector rand(3)
3-element MArray{Tuple{3},Float64,1,3}:
@ 0.20369959817130678
 0.6240643747079531
 0.08155951665146732

julia> b = @MVector rand(3)
3-element MArray{Tuple{3},Float64,1,3}:
 0.06021624735568731
 0.5019016054805225
 0.0691906293351614

julia> a + b
3-element SArray{Tuple{3},Float64,1,3}:
 0.2639158455269941
 1.1259659801884756
 0.15075014598662873

julia> a .+ b
3-element SArray{Tuple{3},Float64,1,3}:
 0.2639158455269941
 1.1259659801884756
 0.15075014598662873

I was expecting both a + b and a .+ b to return MArrays.

Interestingly, promote_type does the right thing:

julia> promote_type(MArray{Tuple{3}, Float64, 1, 3}, MArray{Tuple{3}, Float64, 1, 3})
MArray{Tuple{3},Float64,1,3}

[KristofferC]

AFAIU, this is intended to avoid a bunch of temporaries being allocated on the heap.

[ryanelandt]

I think it is the intended behavior. The decision to make it an SVector occurs here. There is a comment on line 60 that is related to your question.

Running a benchmark suggests that constructing a SVector is about 3x faster, and as @KristofferC mentioned doesn't allocate.

using BenchmarkTools
using StaticArrays

@btime SVector{3,Float64}(1.0, 2.0, 3.0)   # 1.896 ns (0 allocations: 0 bytes)

@btime MVector{3,Float64}(1.0, 2.0, 3.0)   # 5.717 ns (1 allocation: 32 bytes)

sv = SVector{3,Float64}(1.0, 2.0, 3.0)
@btime $sv + $sv                           # 2.207 ns (0 allocations: 0 bytes)

mv = MVector{3,Float64}(1.0, 2.0, 3.0)
@btime $mv + $mv                           # 2.207 ns (0 allocations: 0 bytes)

This behavior, although weird at first, makes sense from a speed point of view.

[andyferris]

Note that much of this might be better on Julia v1.0 in real code because the optimizer can remove heap allocations that have a (post-inlining) local scope lifetime.

I haven't investigated yet if this completely elliminates the performance difference, or not. There's also the possibility that these will escape the scope (e.g. returned from a non-inlined function, stashed in a Vector, etc) and thus be heap allocated.

We can also say "let the people using MArray to worry about their own performance concerns" (you can convert to SArray quickly at any point).

[c42f]

This has been changed and now returns an MVector.