They can mean "real" boxing and consequent performance problems, but sometimes
these get auto-removed during compilation. I see this all the time when
writing array code, for example this function which takes an input tuple and
adds 1 to each element:
julia> @inline inc1(a) = _inc1(a...)
inc1 (generic function with 1 method)
julia> @inline _inc1(a1, a...) = (a1+1, _inc1(a...)...)
_inc1 (generic function with 1 method)
julia> _inc1() = ()
_inc1 (generic function with 2 methods)
julia> inc1((3,5,7))
(4,6,8)
# Let's try using inc1 in another function
julia> foo() = (ret = inc1((3,5,7)); prod(ret))
foo (generic function with 1 method)
julia> foo()
192
julia> @code_warntype inc1((3,5,7))
Variables:
#self#::#inc1
a::Tuple{Int64,Int64,Int64}
Body:
begin
SSAValue(1) = (Core.getfield)(a::Tuple{Int64,Int64,Int64},2)::Int64
SSAValue(2) = (Core.getfield)(a::Tuple{Int64,Int64,Int64},3)::Int64
return (Core.tuple)((Base.box)(Int64,(Base.add_int)((Core.getfield)
(a::Tuple{Int64,Int64,Int64},1)::Int64,1)),(Base.box)(Int64,(Base.add_int)
(SSAValue(1),1)),(Base.box)(Int64,(Base.add_int)(SSAValue(2),
1)))::Tuple{Int64,Int64,Int64}
end::Tuple{Int64,Int64,Int64}
julia> @code_llvm inc1((3,5,7))
define void @julia_inc1_67366([3 x i64]* noalias sret, [3 x i64]*) #0 {
top:
%thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
%2 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 1
%3 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 2
%4 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 0
%5 = load i64, i64* %4, align 8
%6 = add i64 %5, 1
%7 = load i64, i64* %2, align 8
%8 = add i64 %7, 1
%9 = load i64, i64* %3, align 8
%10 = add i64 %9, 1
%11 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 0
store i64 %6, i64* %11, align 8
%12 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 1
store i64 %8, i64* %12, align 8
%13 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 2
store i64 %10, i64* %13, align 8
ret void
}
julia> @code_llvm foo()
define i64 @julia_foo_67563() #0 {
top:
%thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
ret i64 192
}
I think you'd be hard-pressed to complain about inefficiencies in foo() ;-).
--Tim
On Tuesday, July 19, 2016 1:42:46 PM CDT Isaiah Norton wrote:
> On Fri, Jul 15, 2016 at 5:02 PM, David Anthoff <anth...@berkeley.edu> wrote:
> > What do these mean?
>
> http://stackoverflow.com/questions/13055/what-is-boxing-and-unboxing-and-wha
> t-are-the-trade-offs
> > And should I be worried, i.e. is this an indication that something slow
> > might be going on?
>
> Boxing requires allocation and can block optimizations, so it can be a
> problem to have box/unbox at points where you might hope to be working with
> contiguous primitive values (such as within a loop). But there's really no
> hard-and-fast rule.
>
> > --
> >
> > David Anthoff
> >
> > University of California, Berkeley
> >
> >
> >
> > http://www.david-anthoff.com
