[petsc-dev] put options into hash table

[Barry Smith]

   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.