itaps-parallel [Fwd: **** iMesh.h and iBase.h changes ****]

[Tim Tautges]

I personally would be surprised if a reviewer did not bounce the paper 
if it lacked performance data for more than just GRUMMP.  That's why I 
didn't complain even though that data shows poor performance by MOAB. 
I'm ok with taking it out and trying our luck, but I won't be surprised 
if we have to put it back in.

On the subject of performance kernels, I've written such a test, the 
same one I've used to quote performance numbers.  It's in the ANL ITAPS 
repo, at 
https://svn.mcs.anl.gov/projects/ITAPS/Interfaces/Examples/perftest. 
That should really get committed to the Scorec repo, so I'll put that on 
my list.  The test:

a) creates an equal-interval-per-side hex mesh of specified # intervals
b) queries vertices then hexes connected to each vertex
c) queries hexes, vertices in each hex, and computes avg coordinates of 
those vertices
d) reports time and memory usage for individual steps and sum of all steps.

I think that's a pretty representative kernel, at least for query-only 
applications.

- tim

Carl Ollivier-Gooch wrote:
> Mark Shephard wrote:
>> Carl,
>>
>> Although I would like to put some focus on improving mesh adapt (from 
>> multiple levels) and FMDB (low level performance and memory), I do not 
>> think it is going to happen in the near future since the SCOREC group 
>> needs to keep focused on parallel and meeting the needs of 
>> applications groups we are working with. (By the way your figure 6 
>> showing where the time is spent is quite interesting and gives great 
>> information on where things need improvement - Ting and others, please 
>> note that figure and table XVI.)
> 
> I've also got a callgrind profile that I'd be happy to send along now or 
> in the future.  It's entirely possible that there are some places where 
> a small change could make a huge difference in performance, if one 
> looked in the right place.
> 
>> Therefore I am not comfortable including the memory and cpu 
>> comparisons. In addition to known inefficiencies, we may be comparing 
>> apples and oranges in some aspects. The mesh adapt procedures tend to 
>> include substantial logic checks and decision processes not used in 
>> lots of codes. My guess is that the only fair comparison is the the 
>> Native and GRUMMP comparison.
> 
> I was leaning towards taking this out, but left it in primarily out of 
> inertia.  I'm happy to pull the performance comparisons.
> 
> That said, we shouldn't abandon the notion of doing more complete 
> performance comparisons at some point in the future.  Someone (Martin 
> maybe?) floated the notion of having a set of performance kernels to 
> complement the compliance test suite.  I think that's a good idea, for 
> two reasons: first, it'll help all of us tune up our implementations, 
> and second, it'll give a realistic (?) assessment of the tradeoffs that 
> come with the different design decisions that have gone into the 
> different mesh databases.  Once we have the data internally, we can then 
> decide what to do about releasing it.
> 
> Carl
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706