> 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: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
