First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] Opinions wanted: Should CCGS performance improvements go into the 1.0 CellML API branch?


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] Opinions wanted: Should CCGS performance improvements go into the 1.0 CellML API branch?
  • Date: Tue, 07 Nov 2006 13:07:33 +1300
Andrew Miller wrote:
> David Nickerson wrote:
>
>> Initial thoughts on 0.1rc1:
>>
>> Much improved integration performance, but have no time to fully test it
>> ;-)
>>
>> It is painfully and prohibitively slow to load a model or to swap
>> between models. Similarly for cloning a model. This seems true for both
>> simple models with very few variables (i.e. 1952 Hodgkin & Huxley) and
>> more complex models with many variables.
>>
>>
> A big chunk of the problem was due to the time taken for the code
> generation (the remaining issue is the time taken to fetch and translate
> the data into the RDF used at the Mozilla-side to describe the tree
> control contents). For the Zhang SAN model from Alan Garny (which was
> one of the slower models for code generation), callgrind reported that
> code generation took 1,947,794,509 CPU operations to generate the code
> prior to revision 585. With only the revision 585 memoisation patch,
> that is down to 1,376,183,895 ops. With the revision 586 patch (which
> finds source variables for all variables at the beginning, using a
> disjoint sets data-structure, instead of individually finding source
> variables using the CellML API), the time was further reduced to
> 890,363,772 ops.
>
Actually, the final performance is even better (I have been running them
three times, but I forgot to divide the final figure by 3)...

Pre 585: 1,947,794,509
585 only: 1,376,183,895
585 + 586: 296,787,924


i.e. a 656% speedup from revisions 585 and 586 (for that particular
model). That said, the CCGS is still only a small part of the CellML
API, so it is still not clear that this should go on the branch.

Best regards,
Andrew



Archive powered by MHonArc 2.6.18.

Top of page