It is mentioned briefly here: http://docs.julialang.org/en/release-0.2/manual/performance-tips/#type-declarations
and http://docs.julialang.org/en/release-0.2/manual/performance-tips/#separate-kernel-functions But it could be made more explicit (or maybe it is somewhere). On Wed, Jan 22, 2014 at 4:17 PM, John Myles White <[email protected]>wrote: > 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? >>>> >>> > >
