I can't read assembly very well, but if I'm not mistaken it seems to be
moving the .g and .b to xmm0 and xmm1, then back again. Timing it with
@benchmark shows that it's a negligible ~2% difference though. Cool!
function full_red!(vec::Vector{RGB{Float64}})
for i in 1:length(vec)
vec[i] = RGB(1.0, vec[i].g, vec[i].b)
end
vec
end
# compiles to
L56: cmpq 8(%rdi), %rcx
jae L128
imulq $-3, %rdx, %rax
movq (%rdi), %rsi
movsd 8(%rsi,%rax,8), %xmm0
movsd 16(%rsi,%rax,8), %xmm1
imulq $-24, %rdx, %rax
movsd %xmm1, 16(%rsi,%rax)
movsd %xmm0, 8(%rsi,%rax)
movq %r8, (%rsi,%rax)
incq %rcx
decq %rdx
cmpq %rdx, %r9
jne L56
----
function modify_3(vec::Vector{Float64})
for i in 1:3:length(vec)
vec[i] = 1.0
end
vec
end
#compiles to
L73 cmpq %rax, %rsi
jae L129
movq (%r14), %rdi
leaq (,%rdx,8), %rbx
negq %rbx
movq %r8, (%rdi,%rbx)
addq $3, %rsi
addq $-3, %rdx
cmpq %rdx, %rcx
jne L73
On Wednesday, May 11, 2016 at 8:09:50 AM UTC-4, Yichao Yu wrote:
>
> On Wed, May 11, 2016 at 8:01 AM, Cedric St-Jean <cedric...@gmail.com
> <javascript:>> wrote:
> > Tim,
> >
> > Isn't there an inefficiency here though? If my immutable had thirty
> fields
> > and I wanted to change the second field for each instance in an array of
> 1M
> > elements, I would have to read/write the whole array instead of just
> writing
> > one out of every thirty elements.
>
> What's described here is the schematics, not necessarily what it compiles
> to.
> LLVM is reasonably good at doing this optimization.
> There's also https://github.com/JuliaLang/julia/issues/11902 to add
> better syntax support.
>
> >
> > Cédric
> >
> > On Tue, May 10, 2016 at 9:42 PM, Tim Holy <tim....@gmail.com
> <javascript:>> wrote:
> >>
> >> The right way to think about it is that an immutable is like a number:
> >> you're
> >> used to being able to have an array of Float64 and replace those,
> right?
> >> You're not redefining the meaning of "5.2", you're overwriting the
> value
> >> stored
> >> in that slot. Arrays of immutables work exactly the same way: the
> >> container is
> >> not immutable, but the individual values stored in it are. That doesn't
> >> prevent you from replacing them.
> >>
> >> Best,
> >> --Tim
> >>
> >> On Tuesday, May 10, 2016 08:43:04 PM Boylan, Ross wrote:
> >> > But if I make an array of immutables I won't be able to change them
> >> > afterwards. Though I can replace them.
> >> >
> >> > With the old code except for
> >> >
> >> > immutable Stuff
> >> > a::Int
> >> > b::Int
> >> > end
> >> >
> >> > I now have
> >> > julia> v=Array(TT.Stuff, 2)
> >> > 2-element Array{TT.Stuff,1}:
> >> > TT.Stuff(140124021836848,140124000460928)
> >> > TT.Stuff(140124048730192,0)
> >> >
> >> > julia> v[1].a=44 # what I'd like to do
> >> > ERROR: type Stuff is immutable
> >> >
> >> > julia> v[1]=TT.Stuff(3, 4) # work-around
> >> > TT.Stuff(3,4)
> >> >
> >> > !julia> v
> >> > 2-element Array{TT.Stuff,1}:
> >> > TT.Stuff(3,4)
> >> > TT.Stuff(140124048730192,0)
> >> >
> >> > With immutable, is everything in the array laid out contiguous in
> >> > memory?
> >> > It seems sort of odd that the type is immutable yet I can overwrite
> data
> >> > of
> >> > that type. I suppose that would only be prohibited if the array were
> >> > immutable.
> >> >
> >> > Thanks for the tip about using Type to get the zero to work.
> >> > Ross
> >> >
> >> > ________________________________
> >> > From: julia...@googlegroups.com <javascript:> [
> julia...@googlegroups.com <javascript:>] on
> >> > behalf
> >> > of Cedric St-Jean [cedric...@gmail.com <javascript:>] Sent: Tuesday,
> May 10, 2016
> >> > 1:20 PM
> >> > To: julia-users
> >> > Subject: [julia-users] Re: newbie questions (was undefined reference
> >> > error)
> >> >
> >> > "normal" types are by definition heap-allocated, and are always
> >> > manipulated
> >> > them through pointers. What you want is
> >> >
> >> > immutables<
> http://docs.julialang.org/en/release-0.4/manual/types/#immutable
> >> > -composite-types>
> >> >
> >> > immutable Stuff
> >> > a::Int
> >> > b::Int
> >> > end
> >> >
> >> > # Also, for zeros to work,
> >> >
> >> > function zero(x::Type{Stuff})
> >> > Stuff(0, 0)
> >> > end
> >> >
> >> >
> >> > On Tuesday, May 10, 2016 at 4:04:37 PM UTC-4, Boylan, Ross wrote:
> >> > I'm puzzled that a type consisting only of 2 integers doesn't
> qualify
> >> > as
> >> > "bitstype". Further experiment shows that the array seems to be an
> >> > array
> >> > of references, I don't know how to implement zero, and generally that
> >> > I'm a
> >> > bit lost :) My goal is to get a densely packed array of data. I
> assume
> >> > that will use less memory and generate faster code; if not, maybe I
> >> > should
> >> > change my goal.
> >> >
> >> > BTW, my real use has a type more heterogeneous than 2 Int's, so a
> >> > solution
> >> > that uses a 2D array doesn't really generalize appropriately for me.
> >> >
> >> > module TT
> >> > import Base.zero
> >> >
> >> > type Stuff
> >> > a::Int
> >> > b::Int
> >> > end
> >> >
> >> > function zero(x::Stuff)
> >> > Stuff(0, 0)
> >> > end
> >> >
> >> > end
> >> >
> >> > julia> v=Array(TT.Stuff, 3) #as before
> >> > 3-element Array{TT.Stuff,1}:
> >> > #undef
> >> > #undef
> >> > #undef
> >> >
> >> > julia> s=TT.Stuff(3, 5)
> >> > TT.Stuff(3,5)
> >> >
> >> > julia> v=fill(s, 2)
> >> > 2-element Array{TT.Stuff,1}:
> >> > TT.Stuff(3,5)
> >> > TT.Stuff(3,5)
> >> >
> >> > julia> s.a=900
> >> > 900
> >> >
> >> > julia> v ###OOPS: every array element points to the same instance
> >> > 2-element Array{TT.Stuff,1}:
> >> > TT.Stuff(900,5)
> >> > TT.Stuff(900,5)
> >> >
> >> > julia> zero(TT.Stuff) # This is probably what needs to work for
> >> > zeros() to
> >> > work ERROR: MethodError: `zero` has no method matching
> >> > zero(::Type{TT.Stuff})
> >> >
> >> > !julia> zero(TT.Stuff(1, 1)) # this at least calls the right c'tor
> >> > TT.Stuff(0,0)
> >> >
> >> > Ross
> >> > ________________________________________
> >> > From: julia...@googlegroups.com<UrlBlockedError.aspx>
> >> > [julia...@googlegroups.com<UrlBlockedError.aspx>] on behalf of
> Lutfullah
> >> > Tomak [tomak...@gmail.com<UrlBlockedError.aspx>] Sent: Tuesday, May
> 10,
> >> > 2016 12:04 AM
> >> > To: julia-users
> >> > Subject: [julia-users] undefined reference error
> >> >
> >> > You need to initialize array entries if you don't have eltype as
> >> > bitstype.
> >> > Here, undefined reference means you had not initialize the entry.
> And,
> >> > full
> >> > type assignment works because it initializes the entry.
> >>
> >
>
