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

[Mark Shephard]

Carl,

Please send along any performance information you have.

I agree we want to work on performance (and in our case memory usage - 
we seam to be paying more for the flexibility part that I would like to 
see). It is just we want to get this paper complete and at the moment we 
are saturated with other ITAPS things so only little effort can go into 
this at the moment.

Hopefully, we will be able to spend more time on it in the not to 
distant future.

Mark



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
>