Ah, ok, so I can just safely ignore it! Thanks, David
> -----Original Message----- > From: julia-users@googlegroups.com [mailto:julia- > us...@googlegroups.com] On Behalf Of Yichao Yu > Sent: Thursday, July 21, 2016 2:40 PM > To: Julia Users <julia-users@googlegroups.com> > Subject: Re: [julia-users] What does Base.box mean in code_warntype? > > 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- > unboxin > >> > g- > >> 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 > >> > >
