[petsc-dev] put options into hash table

[Dmitry Karpeyev]

I think that currently there is an expectation on the user's part that most
of the necessary options can obtained by the object from the options
database right before (or during) XXXSetUp() -- a sort of "pull" model,
rather than the explicit "push" with XXXSetYYY().  In particular, we can
probably rule out the additional flexibility of setting from options and
then overriding some of those options programmatically with XXXSetYYY().
 We can legislate that expectation by simply moving all XXXSetFromOptions()
calls inside XXXSetUp() so that it's called only once right before the
setup code runs.

That allows us to enclose all of the options in PetscOptionsBegin()/End()
and friends, which is useful for -help, publishing, etc. (There may be a
minor exception here or there, e.g., when PetscOptionsFindPair_Private()
and such intervene).  That might also force a reorganization of some of the
setup code (e.g., PCFieldSplit's), that has gotten to be hard to follow. We
can also protect against repeated string checking with a flag checked at
the granularity of XXXSetUp().

There may be a corner case where for some private object we might not want
to acquire options from the database. That can be prevented by setting some
obscure prefix that would match nothing in the database.  An alternative
would be to move the code from XXXSetFromOptions() into XXXSetUp(), but
make XXXSetFromOptions() only set a flag (true by default), that would turn
on/off the setting of the options from the database.  That would be a bit
with odds with the semantics of XXXViewFromOptions(), though.

I'm not sure how to short-circuit the options checking at runtime short of
dlsym() of different versions of the same routine.

Dmitry.


On Mon, Nov 25, 2013 at 8:03 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>    Trying again then:  I see two types of option checking
>
>    1) Inside XXXSetFromOptions(), I believe we can protect these so they
> are only called when they can actually have an affect to actually set some
> options
>
>     2) All the various -xxx_view that are in the code to help with
> understand what it is doing, what the matrices look like etc.  For example
> -ksp_mat_view that allows saving the matrix right before a solve or
> -pc_factor_mat_view etc. These are called in tight loops sometimes because
> we want to check things in those tight loops.
>
>     It may be possible to organize all the -xxx_view calls through a
> universal PetscObject/XXXViewFromOptions() call that gets dropped into the
> source code wherever we like. But we have a runtime option that
> short-circuits the call so no checks are actually made and hence no cost.
> Conceivably you could even apply this option selectively to only some
> objects.
>
>    I’ll see if I can organize XXXViewFromOptions() universally and make a
> branch to see if this API makes sense. Regardless using
> XXXViewFromOptions() consistently will be better than the hodgepodge we
> have now.
>
>    Barry
>
>
>
> On Nov 25, 2013, at 6:38 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> > Barry Smith <bsmith at mcs.anl.gov> writes:
> >
> >>   If we put all the options passed in into a hash table then won’t a
> >>   PetscOptions look up be pretty cheap, compute the hash, look in the
> >>   table, check that the strings match with a strncmp, done (usually)
> >>   and at worst do 2 or 3 string compares?
> >
> > Yes, I have always thought that we should use a hash for the options
> table...
> >
> >>   If we adopt the view that an options check is very cheap that we
> >>   don’t need to worry much about options being rechecked right?
> >
> > ... however, I don't think it changes the picture that we should move
> > options testing out of the fast path for algorithms.  The hash just
> > pushes the pain point down somewhat, most importantly, in a way that is
> > scalable in the total number of options in the options table.  But with
> > a big options table, it's still a lot of string hashing and a lot of
> > likely cache misses probing into the options hash.
> >
> > I would like to make PETSc competitive for integrating 20-species
> > chemical systems, and I don't see room for string operations in that
> > world.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131125/46f591ae/attachment.html>