Thanks everyone for the answers! I guess Tim's email in particular means that the presence of box might indicate a problem, or not ;)
I guess it would be nice if there was some (easy) way to figure out whether things get boxed or not, apart from looking at the assembler/llvm code. > -----Original Message----- > From: julia-users@googlegroups.com [mailto:julia- > us...@googlegroups.com] On Behalf Of Tim Holy > Sent: Tuesday, July 19, 2016 10:55 AM > To: julia-users@googlegroups.com > Subject: Re: [julia-users] What does Base.box mean in code_warntype? > > 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- > a > > nd-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 >
