A correction: the native Haswell build does use packed conversions for
32-bit integers, and valiantly mixes unpacked conversions with packed
division for 64-bit. I didn't see any of this from the pre-built binaries.
On Friday, September 16, 2016 at 10:22:16 PM UTC-4, Ralph Smith wrote:
>
> The
The integer vectors d and l have to be converted to floats before division.
Vectorization at this point means that the compiler writes code to use wide
registers to do more than one at a time (and lots of extra logic to handle
alignment and stragglers).
Something in the chain (LLVM front end, I
function
distance{T<:MutationType,A<:NucleotideAlphabet}(::Type{Proportion{T}},
seqs::Vector{BioSequence{A}})
d, l = distance(Count{T}, seqs)
D = Vector{Float64}(length(d))
@inbounds @simd for i in 1:length(D)
D[i] = d[i] / l[i]
end
return D, l
end
*julia>
What if you add @simd after @inbounds?
On Friday, September 16, 2016 at 5:48:00 PM UTC+2, Ben Ward wrote:
>
> The code for that function not shown is rather similar to the version that
> is shown:
>
> function
> distance{T<:MutationType,A<:NucleotideAlphabet}(::Type{Proportion{T}},
>
The code for that function not shown is rather similar to the version that
is shown:
function
distance{T<:MutationType,A<:NucleotideAlphabet}(::Type{Proportion{T}},
seqs::Vector{BioSequence{A}})
d, l = distance(Count{T}, seqs)
D = Vector{Float64}(length(d))
@inbounds for i in
SSAValue(15) = (Base.getfield)(SSAValue(0),1)
*::Union{Array{Float64,1},Array{Int64,1}}*
indicates that the first element of SSAValue(0) is ambiguous. Earlier it
shows that this means p from
p, l = distance(Proportion{AnyMutation}, seqs)
which we can't analyze from what you show here.
On
Removing the @inlines may be useful while investigating.
On Thursday, September 15, 2016 at 10:08:16 AM UTC-4, Ben Ward wrote:
>
> Hi I have two functions and a function which calls them:
>
> @inline function expected_distance(::Type{JukesCantor69}, p::Float64)
> return -0.75 * log(1 - 4 * p
