I thought this was in the performance tips, but I couldn’t find it in a quick read. Definitely worth putting in there, because this is a really, really subtle point despite being so important.
— John On Jan 22, 2014, at 4:01 PM, Kevin Squire <[email protected]> wrote: > Thanks a lot for the correction, Tobias. I was confused on this point, but > it's easy to check: > > julia> c(a::Real, b::Real) = a+b > c (generic function with 1 method) > > julia> code_native(c, (Float64,Float64)) > .text > Filename: none > Source line: 1 > push RBP > mov RBP, RSP > Source line: 1 > addsd XMM0, XMM1 > pop RBP > ret > > julia> code_native(c, (BigFloat,BigFloat)) > .text > Filename: none > Source line: 1 > push RBP > mov RBP, RSP > push RBX > sub RSP, 40 > mov QWORD PTR [RBP - 40], 4 > Source line: 1 > movabs RBX, 139893810921040 > mov RAX, QWORD PTR [RBX] > mov QWORD PTR [RBP - 32], RAX > lea RAX, QWORD PTR [RBP - 40] > mov QWORD PTR [RBX], RAX > xorps XMM0, XMM0 > movups XMMWORD PTR [RBP - 24], XMM0 > movups XMM0, XMMWORD PTR [RSI] > Source line: 1 > movups XMMWORD PTR [RBP - 24], XMM0 > Source line: 1 > lea RSI, QWORD PTR [RBP - 24] > Source line: 1 > movabs RAX, 139893815571504 > mov EDI, 64233568 > mov EDX, 2 > call RAX > mov RCX, QWORD PTR [RBP - 32] > mov QWORD PTR [RBX], RCX > add RSP, 40 > pop RBX > pop RBP > ret > > Kevin > > > On Wed, Jan 22, 2014 at 3:55 PM, Tobias Knopp <[email protected]> > wrote: > No. Giving types in function definitions does not give you any speedup as the > function are always compiled for concrete types. > > When you define composite types it is however important to give concrete > types for optimal performance. > > Am Donnerstag, 23. Januar 2014 00:41:41 UTC+1 schrieb Patrick Foley: > Thanks! > > I've sorted it out and have solved my original problems. > > Would I get any speedup by defining > > function foo{TA<:Real, TB<:Real}(a::TA, b::TB) > > rather than > > function foo(a::Real, b::Real) > > ? > > My guess is .. yes? Since if I'm defining it the first way, I can compile > versions of foo like foo(a::Int8, b::Int8) automatically, which would be much > faster than defaulting to a foo(a::Real, b::Real) and reserving space for a > possible Float64 each time? > > > On Tuesday, January 21, 2014 7:17:36 PM UTC-5, Patrick Foley wrote: > Is there a way to get around this? I have a lot of types (foo1, foo2, ....) > all of which are subtypes of an abstract (bar). I want to be able to define > the behavior for arrays of any of the foos just by defining the behavior of > an array of 'bar's. Any advice? >
