Hi George,
we need to discuss first how to tackle the problem. We have been discussing with Sebastien and it is not sure that an object oriented approach is the most appropriate. At least, matrices should not be objects that are repeatedly instantiated. Maybe, we can consider basic algorithms as classes, but we need to refine our intuition.
Let's talk about it in the coming days and then we will decide of a course of action.
All the best,
Michel
G. Perendia wrote:
Thanks Michel
I am aware that I need to tackle the leaks in the k_order_perturbation - shall I then also work on reducing its repetitive instantiations at the same time, both as a high priority too?
Best regards George ----- Original Message ----- From: "Michel Juillard" Michel.Juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Tuesday, December 01, 2009 4:08 PM Subject: Re: [DynareDev] C++ DsgeLikelihood and estimation issues
Dear George,
this is excellent news. Please wait before re-working on GeneralMatrix
copy() as
we have to avoid repetitive object instantiation in k_order_perturbation
itself
and deal with memory leaks.
All the best,
Michel
Quoting "G. Perendia" george@perendia.orangehome.co.uk:
Hi Sebastien
I now have a pretty stable working prototype of C++ DsgeLikelihood
suitable
for initial indicative performance tests.
Unfortunately, during the lengthy debugging process, I realised I had to take out some performance improvers built as overloads for the
GeneralMatrix
copy() method, originally for improving the Kalman Filter performance,
since
they were breaking (now integrated) K-order-perturbation and hence I
will
need to devise and develop some alternative performance booster methods.
However, some very rough performance comparison tests with fs2000 model
even
with such degraded KF indicate to be pretty promising and worth of the further effort: whilst 1000 loop calling Matlab DsgeLikelihood.m (all
with
same parameters) takes randomly somewhere between 40 and 50 sec, calling
the
equivalent CalcLikelihood method from within parent C++ mexFunction (together with constructing its parent class once as it would be done by
the
C++ estimation) takes approx. 10 sec (thus, less than 1/4th of time).
This
was run on an old and slower machine but the relative advantage is
pretty
portable. That, (together with some additional performance boosting) may result in a rather substantial time saving for whole MLE/MCMC
estimation!
Best regards
George
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
--
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev