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
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
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
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
Hi Michel and Sebastien
For a start of the further discussion, can we get some more information on the alternative directions you have been discussing so far?
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 5:54 PM Subject: Re: [DynareDev] C++ DsgeLikelihood and estimation issues
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
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
-
G. Perendia -
Michel Juillard -
Michel Juillard