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 <royst...@ices.utexas.edu>
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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
