A fascinating look under the hood -- many thanks. o The profiler plots are especially cool. Were these produced by the products Dr. Guyer mentioned?
http://packages.python.org/line_profiler/ http://www.vrplumber.com/programming/runsnakerun/ Looks like a lot more fun than piecing together cProfile results! And how could you go wrong with something called "runsnakerun"? o A quick clarification: were the plots, especially those showing exec time vs grid cells, done *after* the mods were in place? On Wed, Jun 2, 2010 at 12:38 PM, O'Beirne, James Frederick < [email protected]> wrote: > > - > For benchmarking purposes, we disabled the use of > any preconditioners and matched Trilinos' residual > norm to PySparse's choice, the ``b'' norm. We did > so by making the following changes: > ... > Once we made these changes, iteration numbers and > residuals were in agreement for the two solvers. o Good point about setting the 2 solvers on an equal footing for benchmarking purposes. You note that the moded versions compared well with each other -- how do they compare with their pre-moded selves? I will make your suggested changes and compare the pre- and post-modification solutions to see what I get, but I'm wondering about your opinion as to these changes in general: are they appropriate for the production code? > The case of differing results when considering > parallel vs. serial operation is still an open > question. There could be artifacts inherent > in the use of MPI, or perhaps the hardware over which > computation is distributed differs in such a way as > to impact the results slightly. o This is likely more a curiosity than a problem, still... The other day I tried an "experiment" to eliminate the hardware. I started 4 of the anisotropy demos simultaneously, each using 1 processor, guaranteeing that each of our system's 4 processors and FPUs would be used at some point. The solutions produced by all 4 were identical, and identical to the solutions for that solver's single-CPU trials over the past week. This lack of variability would also seem to rule out "noise" or similar kinds of explanations. This makes me think that there is some interaction, at least on our machine, with MPI. Do you (or anyone else) see similar behavior? Not knowing the source of the difference means you can't really be sure that the effect is always small. > -- Why does Trilinos seem to be slower than PySparse? > ... > The good news is that the relative sluggishness of > Trilinos abates as the complexity of the problem > increases.... o Will make your suggested mods and try them on the demos and then our model. Thanks very much, James, for the insight into FiPy's innards. Regards, +jtg+
