Re: itaps-parallel [Fwd: **** iMesh.h and iBase.h changes ****]
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 -- ------------------------------------------------------------------------ Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854 Associate Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: [email protected] University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/ ------------------------------------------------------------------------
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
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 ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
participants (3)
-
Carl Ollivier-Gooch -
Mark Shephard -
Tim Tautges