Chronological Thread 

< Chronological >      < Thread >

---

> The major performance bottleneck is the the evaluation of the Jacobian
> function (I use the standard O(n^2) method for generating a dense
> Jacobian in an array, and most of the time is spent evaluating the
> variables). Although COR is closed source and so I cannot see exactly
> what it is doing. Given that COR apparently isn't doing any optimisation
> here, it must be taking a comparable amount of time per Jacobian
> computation, so the difference must be in the number of calls to compute
> the Jacobian.
>> Seems it would be good to address this question now, because if using
>> something like CVODE still results in the same poor performance then I
>> think some serious thinking needs to be done about the underlying
>> technology before an official release of pcenv should be made.
> I understand that you already have CVODE working with CCGS, so perhaps
> you can give some indication of how well CCGS generated code works with
> CVODE?

Sorry, I should have mentioned that in my code which uses CCGS with
CVODES the performance is significantly better than pcenv. And from the
little I have played with COR I'm getting better performance than COR,
although I am generating a HDF5 data file rather than drawing graphs, so
not sure how much that helps performance. The way I am currently using
CVODES should be making it behave identically to CVODE.

In my code, I use CCGS to generate the RHS function that gets used by
CVODES in the integration and presumably in its own internal
approximation of the Jacobian - I am not dealing with the Jacobian at
all, its all internal to CVODES. The RHS function that I generate
contains a bit of wrapper code to get data out of the CVODES user data
and calls the methods I generate containing the output from the two methods:
cci->variableCodeFragment();
cci->rateCodeFragment();
and I am not yet doing any kind of optimisation on the code other than
using -O3 on my compile command :)

This is why I think it is essential to have CVODE(S) in pcenv, so we can
see if it really is just the numerical methods that are the true bottle
neck that currently makes pcenv slow to use. From my experience, using
CVODES with CCGS generated code is blazing fast - so hopefully that will
be true when the same process in used in pcenv.

And given there really is a serious performance issue at the moment, it
seems premature to be putting effort into making and supporting an
official release until this issue is addressed.

Andre.

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [cellml-discussion] pcenv development priorities, David Nickerson, 10/30/2006
  • [cellml-discussion] pcenv development priorities, Andrew Miller, 10/30/2006
    • [cellml-discussion] pcenv development priorities, David Nickerson, 10/30/2006
      • [cellml-discussion] pcenv development priorities, Alan Garny, 10/30/2006
    • [cellml-discussion] pcenv development priorities, Poul Nielsen, 10/30/2006
      • [cellml-discussion] pcenv development priorities, Andrew Miller, 10/30/2006
    • [cellml-discussion] pcenv development priorities, David Nickerson, 10/30/2006
      • [cellml-discussion] pcenv development priorities, Alan Garny, 10/30/2006
        • [cellml-discussion] pcenv development priorities, David Nickerson, 10/30/2006
          • [cellml-discussion] pcenv development priorities, Alan Garny, 10/31/2006
          • [cellml-discussion] pcenv development priorities, Andrew Miller, 10/31/2006
            • [cellml-discussion] pcenv development priorities, David Nickerson, 10/31/2006
              • [cellml-discussion] pcenv development priorities, Andrew Miller, 10/31/2006

---

Archive powered by MHonArc 2.6.18.