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?
>>>
>>
