I will try to look into the computation of available memory in Windows. This is a part well delimited in dynare++ (about 30 lines)
However, it will take me some time as I won't have access to a Windows comptuer next week
Best
Michel
Johannes Pfeifer writes:
I don't feel strongly about Dynare++ and would prefer to see it replaced by Dynare rather sooner than later (ticket 217 stands in the way). The reason I am interested in this issue are its consequences for higher order perturbation in Dynare. The k_order_pert.mex routine that is based on the codes in Dynare++ shows sometimes shows weird behavior on Windows. The last time we tried to investigate it, we did not find an answer. I was hoping that this model provides additional clues.
On a broader perspective, I agree that the model is most probably simply too large for order=6. What bothers me is the difference in algorithms one encounters in Linux vs. other OS. The algorithm Windows turns to comes with a large loss in performance that may make particle filtering and SMM at higher order too time-consuming.
-----Ursprüngliche Nachricht----- Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Donnerstag, 13. August 2015 13:18 An: List for Dynare developers Betreff: Re: [DynareDev] Dynare++ Memory
I don't have yet the answer from valgrind on this example. I'm still convinced that the problem has to do with size but not in the way I was thinking initially. If it was a problem of available memory, in Linux at least, we should get a "bad_alloc" error message, unless memory is allocated in a non standard manner. Now, I'm suspecting more an index or an offset that is too large for the type it is stored in. This will be much more difficult to debug. The problem could also be in a library called by dynare++. I wonder how much time should we spend on this problem
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev