On Thu, Jul 21, 2016 at 5:33 PM, David Anthoff <anth...@berkeley.edu> wrote: > Thanks everyone for the answers! > > I guess Tim's email in particular means that the presence of box might > indicate a problem, or not ;)
Base.box in the ast doesn't indicate a problem. Any type instability should be highlighted independently. > > 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 >> >
