There may be two separate issues here. - Without putting concrete types on x and y, it will never be fast. But let's suppose you planned to do that (as you did for the types in your gist), and were just being brief in your email. - There is no penalty for making B and C subtypes of A; myfunc(object::A) will be compiled twice, once for when object is a B and once when it is a C. Moreover, when Julia can infer types in functions that call myfunc, it will make that decision, too, at compile-time. So in favorable cases there is literally no run-time overhead for creating subtypes of an abstract type.
--Tim On Monday, January 06, 2014 11:53:33 AM John Myles White wrote: > I’m not really sure. My not totally informed sense is that this is likely to > be generally slow since you have to check the type every time to determine > what the inner field means. > > But someone with more knowledge of Julia internals would need to confirm > that. > > — John > > On Jan 6, 2014, at 10:34 AM, Brendan O'Connor <[email protected]> wrote: > > On Sunday, January 5, 2014 8:54:08 PM UTC-5, John Myles White wrote: > > Looking at this now, what are the types of the variables on the bolded > > lines? If they’re specific real-valued types, I’m surprised they’re so > > slow.> > > They're all Float64, or at least, they should be. code_typed() says they are: > > w0 = > > /(-(+(getindex(top(getfield)(n0,:counts),wordID::Int64),top(box)( > > Float64,top(div_float)(betaHere::Float64,top(box)($(Float64),top(s > > itofp)($(Float64),V::Int64))::Float64))::Float64),on0::Int64),-(+( > > top(getfield)(top(getfield)(n0,:counts),:total),betaHere::Float64) > > ,top(box)($(Int64),top(zext_int)($(Int64),on_cur::Bool))::Int64)) > > # line 338: w1 = > > /(-(+(getindex(top(getfield)(n1,:counts),wordID::Int64),top(box)( > > Float64,top(div_float)(betaHere::Float64,top(box)($(Float64),top(s > > itofp)($(Float64),V::Int64))::Float64))::Float64),on1::Int64),-(+( > > top(getfield)(top(getfield)(n1,:counts),:total),betaHere::Float64) > > ,top(box)($(Int64),top(zext_int)($(Int64),on_cur::Bool))::Int64)) > > # line 339: p0 = > > -(+(top(getfield)(top(getfield)(cur_docnode,:left),:count),top(bo > > x)(Float64,top(div_float)(top(getfield)(mm::TreeTM,:gammaConc)::Fl > > oat64,top(box)($(Float64),top(sitofp)($(Float64),2))::Float64))::F > > loat64),on0::Int64) # line 340: p1 = > > -(+(top(getfield)(top(getfield)(cur_docnode,:right),:count),top(b > > ox)(Float64,top(div_float)(top(getfield)(mm::TreeTM,:gammaConc)::F > > loat64,top(box)($(Float64),top(sitofp)($(Float64),2))::Float64)):: > > Float64),on1::Int64) # line 341:> > > q = /(*(p1,w1),+(*(p1,w1),*(p0,w0))) # line 343: > > Right now it’s not possible to have an abstract type with fields, so field > > lookup should be pretty consistently fast.> > > What I meant was: > > abstract A > > type B <: A > > > > x > > > > end > > type C<: A > > > > y > > > > end > > > > ... and you have a datastructure typed A, but actually contains a mix of > > B's and C's. You have code that knows it's always accessing type B, and > > accesses the "x" field. Under what circumstances is this fast? > > > > -Brendan
