RE: [julia-users] What does Base.box mean in code_warntype?

2016-07-21 Thread David Anthoff 
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
> >>
> >

Re: [julia-users] What does Base.box mean in code_warntype?

2016-07-21 Thread Yichao Yu 
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
>>
>

RE: [julia-users] What does Base.box mean in code_warntype?

2016-07-21 Thread David Anthoff 
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
>

Re: [julia-users] What does Base.box mean in code_warntype?

2016-07-19 Thread Tim Holy 
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  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

Re: [julia-users] What does Base.box mean in code_warntype?

2016-07-19 Thread Isaiah Norton 
On Fri, Jul 15, 2016 at 5:02 PM, David Anthoff  wrote:

>
> What do these mean?
>

http://stackoverflow.com/questions/13055/what-is-boxing-and-unboxing-and-what-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
>
>
>

RE: [julia-users] What does Base.box mean in code_warntype?

2016-07-19 Thread Kristoffer Carlsson 
Pretty much this https://github.com/JuliaLang/julia/issues/15276

RE: [julia-users] What does Base.box mean in code_warntype?

2016-07-19 Thread David Anthoff 
Bump, does anyone have some info about this? Thanks, David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On
Behalf Of David Anthoff
Sent: Friday, July 15, 2016 2:02 PM
To: julia-users@googlegroups.com
Subject: [julia-users] What does Base.box mean in code_warntype?

 

I'm looking for type instabilities in a function with code_warntype, and I'm
seeing lots of ``(Base.box)`` terms there.

 

What do these mean? And should I be worried, i.e. is this an indication that
something slow might be going on?

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

[julia-users] What does Base.box mean in code_warntype?

2016-07-15 Thread David Anthoff 
I'm looking for type instabilities in a function with code_warntype, and I'm
seeing lots of ``(Base.box)`` terms there.

 

What do these mean? And should I be worried, i.e. is this an indication that
something slow might be going on?

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com