Wow! That is a huge difference. I suspected that my benchmark was flawed, but I don't understand in what way, since is doesn't seem like anything is being inappropriately optimized away. Quite the contrary, my benchmark is running slowly with lots of allocations.
The question remains, though, when is Vector better/faster in cases when both vectors and tuples are possible to use? Are arrays always this slow compared to tuples? As for what's holding me back from using FixedSizeArray: nothing but pure ignorance! On Tuesday, April 12, 2016 at 11:06:25 AM UTC+2, Simon Danisch wrote: > > Your benchmark is flawed. > Try something like the Benchmarks > <https://github.com/johnmyleswhite/Benchmarks.jl> package, or use this: > > using FixedSizeArrays > Base.(:+){T}(p1::NTuple{2,T}, p2::NTuple{2,T}) = (p1[1]+p2[1], p1[2]+p2[2]) > function test(a, b, N) > ct = a+b > for _ in 1:N ct = ct+a+b end # use intermediate result so that llvm > doesn't just remove the loop > ct # return value so it doesn't get optimized away > end > a, b = randn(2), randn(2) > at, bt = (randn(2)...), (randn(2)...) > p1, p2 = Point2D(randn(2)...), Point2D(randn(2)...) > > #warm up > test(a,b,10^7) > test(at,bt,10^7) > test(p1,p1,10^7) > > > @time test(a,b,10^7) # 1.175718 seconds (40.00 M allocations: 1.788 GB, > 9.77% gc time) > @time test(at,bt,10^7) #0.017781 seconds (6 allocations: 208 bytes) > @time test(p1,p1,10^7) #0.017783 seconds (6 allocations: 208 bytes) > > > As you can see, tuples and types are pretty much the same, while Vector is > far behind. > In this benchmark, it's mainly because the Vector is heap allocated. > Tuples are preferable to types, since they have the same performance, but > you can implement n-dimensional point types. > If you already found FixedSizeArrays, what's holding you back of using it? > It already has the Point{N, T} type and GeometryTypes.jl > <https://github.com/JuliaGeometry/GeometryTypes.jl> has even more ;) > > Best, > Simon > Am Montag, 11. April 2016 22:00:59 UTC+2 schrieb Anonymous: >> >> If I have a vector of data which I don't intend to ever change, should I >> represent it as a tuple rather than a 1d array? Is there any benefit above >> and beyond protecting against mutability? Is it more efficient? >> >
