Oh it's that same issue? Thanks for pointing it out. That means every one 
of my performance problems are due to the same issue... that's both a good 
thing and a bad thing I guess. So would your suggestion just be to move 
forward doing things like this, knowing that this issue will get fixed? If 
it will be possible to have good performance with closures on a type like 
that, then I'll be moving forward with a larger design change 
<https://github.com/ChrisRackauckas/DifferentialEquations.jl/issues/41#issuecomment-242310914>
 in 
hopes that it will improve. But right now I'm in limbo because I don't know 
what to do about this!

On Thursday, August 25, 2016 at 1:43:56 AM UTC-7, Yichao Yu wrote:
>
>
>
> On Thu, Aug 25, 2016 at 4:12 PM, Chris Rackauckas <[email protected] 
> <javascript:>> wrote:
>
>> It seems like a closure on a non bitstype still has issues, or is there 
>> something wrong with doing this?
>>
>> immutable Params
>>   α::Float64
>> end
>>
>> function test()
>>   h = (t,u,du,p) -> @inbounds begin
>>     du[1] = 1.01u[1]
>>     du[2] = p.α*u[2]
>>   end
>>   h2 = (t,u,du) -> @inbounds begin
>>     du[1] = 1.01u[1]
>>     du[2] = 1.0*u[2]
>>   end
>>   const u = [0.1,0.2]
>>   const du = zeros(2)
>>   const p = Params(1.0)
>>   l = (t,u,du) -> h(t,u,du,p)
>>   println("Pass In Parameters")
>>   @code_native h(1.0,u,du,p)
>>   println("No Parameters")
>>   @code_native h2(1.0,u,du)
>>   println("Closures")
>>   @code_native l(1.0,u,du)
>> end
>> test()
>>
>> Pass In Parameters
>> .text
>> Filename: replacement_macros_tests.jl
>> pushq %rbp
>> movq %rsp, %rbp
>> Source line: 29
>> movq (%rdi), %rax
>> movsd (%rax), %xmm0           # xmm0 = mem[0],zero
>> movabsq $140006850762016, %rcx  # imm = 0x7F55E29B1520
>> mulsd (%rcx), %xmm0
>> movq (%rsi), %rcx
>> movsd %xmm0, (%rcx)
>> Source line: 30
>> movsd (%rdx), %xmm0           # xmm0 = mem[0],zero
>> mulsd 8(%rax), %xmm0
>> movsd %xmm0, 8(%rcx)
>> popq %rbp
>> retq
>>
>> No Parameters
>> .text
>> Filename: replacement_macros_tests.jl
>> pushq %rbp
>> movq %rsp, %rbp
>> Source line: 33
>> movq (%rdi), %rax
>> movsd (%rax), %xmm0           # xmm0 = mem[0],zero
>> movabsq $140006850762144, %rcx  # imm = 0x7F55E29B15A0
>> mulsd (%rcx), %xmm0
>> movq (%rsi), %rcx
>> movsd %xmm0, (%rcx)
>> Source line: 34
>> movq 8(%rax), %rax
>> movq %rax, 8(%rcx)
>> popq %rbp
>> retq
>> nopw (%rax,%rax)
>>
>>
>> Closures
>> .text
>> Filename: replacement_macros_tests.jl
>> pushq %rbp
>> movq %rsp, %rbp
>> pushq %r15
>> pushq %r14
>> pushq %r13
>> pushq %r12
>> pushq %rbx
>> subq $72, %rsp
>> movq %rdx, %r14
>> movq %rsi, %r15
>> movsd %xmm0, -112(%rbp)
>> movabsq $140007647692112, %rbx  # imm = 0x7F56121B4550
>> movq %fs:0, %r12
>> addq $-2672, %r12            # imm = 0xFFFFFFFFFFFFF590
>> xorpd %xmm0, %xmm0
>> movupd %xmm0, -64(%rbp)
>> movupd %xmm0, -80(%rbp)
>> movq $0, -48(%rbp)
>> movq $12, -104(%rbp)
>> movq (%r12), %rax
>> movq %rax, -96(%rbp)
>> leaq -104(%rbp), %rax
>> movq %rax, (%r12)
>> movq $0, -88(%rbp)
>> Source line: 39
>> movq (%rdi), %rax
>> movq (%rax), %r13
>> testq %r13, %r13
>> je L232
>> movq %r13, -88(%rbp)
>> movq %rbx, -80(%rbp)
>> movabsq $jl_gc_pool_alloc, %rax
>> movl $1432, %esi             # imm = 0x598
>> movl $16, %edx
>> movq %r12, %rdi
>> callq *%rax
>> addq $1072064, %rbx          # imm = 0x105BC0
>> movq %rbx, -8(%rax)
>> movsd -112(%rbp), %xmm0       # xmm0 = mem[0],zero
>> movsd %xmm0, (%rax)
>> movq %rax, -72(%rbp)
>> movq %r15, -64(%rbp)
>> movq %r14, -56(%rbp)
>> movq %r13, -48(%rbp)
>> movabsq $jl_apply_generic, %rax
>> movl $5, %esi
>> leaq -80(%rbp), %rdi
>> callq *%rax
>> movq -96(%rbp), %rax
>> movq %rax, (%r12)
>> addq $72, %rsp
>> popq %rbx
>> popq %r12
>> popq %r13
>> popq %r14
>> popq %r15
>> popq %rbp
>> retq
>> L232:
>> addq $1448, %rbx             # imm = 0x5A8
>> movabsq $jl_throw, %rax
>> movq %rbx, %rdi
>> callq *%rax
>> nop
>>
>>
>> Clearly the 3rd method (using a closure on a parameter type) has a lot 
>> more steps. My untrained eye says that means it's bad... is that simple 
>> analysis wrong?
>>
>>
> The issue is https://github.com/JuliaLang/julia/issues/15276 See
> https://github.com/JuliaLang/julia/issues/17395#issuecomment-241911387 
> for a workaround that works for me most of the time.
>
>

Reply via email to