Since Base.OneTo
is not exported I am suspicious that there might be some gotchas with it.
I implemented a padded array interface to perform in-place r2c and c2r fft transformations.
For that I have to create views that are always something like (pseudo-code) @view a[begin:(end-2), : , : , ... , :]
where begin
is the first index of the first dimension.
As you can see below, using OneTo
s gives me the best performance.
I’ll be creating views of plain julia’s Array
s, so no array with custom indices. So, is it safe to use Base.OneTo
directly?
julia> data = rand(130,128,128);
julia> a = view(data,1:128,1:128,1:128);
julia> b = view(data,1:128,:,:);
julia> c = view(data,Base.OneTo(128),Base.OneTo(128),Base.OneTo(128));
julia> using BenchmarkTools
julia> @btime sum($a)
5.230 ms (0 allocations: 0 bytes)
1.0485345086366412e6
julia> @btime sum($b)
4.549 ms (0 allocations: 0 bytes)
1.0485345086366412e6
julia> @btime sum($c)
4.300 ms (0 allocations: 0 bytes)
1.0485345086366412e6
julia> versioninfo()
Julia Version 0.7.0-beta2.0
Commit b145832402* (2018-07-13 19:54 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin17.6.0)
CPU: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-6.0.0 (ORCJIT, broadwell)
Environment:
JULIA_NUM_THREADS = 2
Note that the :
creates ranges of type Slice{OneTo{Int}}
, so it is taking the advantages of OneTo
…