Re: [Libmesh-devel] DofObject::var_to_vg()

[Derek G. <fri...@gm...>]

Interesting thoughts.

Right now I have exactly _one_ var group (which makes this even more
puzzling)... and I'm trying to just pull out the first dof from that group
using dof_indices().  I then do all the rest of my indexing off of that
first dof for all the other dofs in the group.

Maybe there's a better way to be doing that?  Is there a more
straightforward way to get the first dof in a var_group?

I think I wouldn't mind just storing a var_num->var_group vector somewhere
that every DofObject has access to.  The variable numbers are always
contiguous starting from 0 so we should just be able to index into it.

Derek

On Wed, Jun 20, 2018 at 8:11 AM Roy Stogner <roy...@ic...>
wrote:

>
> On Tue, 19 Jun 2018, Derek Gaston wrote:
>
> > (Note: this falls into the category of "microptimization" but with
> > my current app that's important).
>
> I've seen this method show up in other timings too... maybe it was
> RELAP-7?  Anyway, if we can speed it up your current app won't be the
> only beneficiary.
>
> > Something that consistently shows up in my timing with MOOSE and my
> > new app is DofObject::var_to_vg().  It is gets called in a number of
> > places throughout DofObject... and I'm wondering if it's currently
> > implemented in the most optimal way.
> >
> > It's doing a small loop in there and I'm wondering if it's
> > necessary.  Is it not possible to directly compute the var group?
> >
> > vg_dof_base() seems to do some direct calculation - can we use that
> > instead?
>
> vg_dof_base already has the variable group index vg, which is what we
> can use for a direct lookup of data related to all variables in that
> group; buried in that index buffer are subbuffers indexed by vg.
>
> var_to_vg has the variable index v, and is trying to figure out vg.
> We can only do that implicitly right now, since there may be an
> arbitrary number of variables in each group.
>
> I can think of ways to make that lookup faster in some cases, but
> always at the cost of more space or more time in other cases or much
> less code modularity, so I guess my first question is: what's your
> case look like?
>
> How many variables, and how are they grouped?
>
> What is the heavy user of var_to_vg() for you?
>
>
> A couple random ideas that might be worth trying:
>
> We could cache a var_to_vg lookup table, and give every DofObject a
> pointer to that table.  Less modular and an extra 8 bytes per object
> but it'd be faster in at least some cases.
>
> We could store n_vars in a cumulative sense, which would then let us
> do a binary search instead of a linear search.  Slightly slower for
> most use cases, but much faster for cases with lots of variable
> groups.
>
> We could try to avoid using var_to_vg-reliant methods in more places?
> Or maybe that's already been done... we're consistently using
> set_n_comp_group instead of set_n_comp, we're not using set_dof_number
> internally anymore... but n_comp and dof_number both rely on
> var_to_vg, and we don't use n_comp_group everywhere we might, and we
> don't even *have* a dof_number_group, even though we use both n_comp
> and dof_number in lots of loops that could be optimized in such a way.
> ---
> Roy