Hi
1) A switch to Ferhat's solution sounds both exciting and the right way to go forward and I expect that the transition for perturbation.dll will be, as Michel already suggested, straight forward.
I still think that we should leave (and maintain) the use_dll option (e.g. renamed to "produce_cpp") because the produced .c/.cpp files can be used to provide for some additional forms of specialised hardware parallelisation such as that over graphics cards among the rest.
I also do expect that we will continue to provide the existing option of using more user-tractable static/dynamic.m Matlab functions (but not DLLs) , if for no other reason than as a backup option for debugging of either the user models or the new developments. (i.e. I think that without such option the new system may become rather more difficult to debug, especially from the user model point of view).
2) I realised that it is difficult to make linker export Dynamic() in a structured but generalised fashion. I found that one possible way for gcc /ld linker pair to export Dynamic is to specify no exports. I recently tried this too: in the mexopt.bat one can set:
set LINKER=echo EXPORTS > mex.def >> mex.def & gcc
instead the current similar line, but, without "& mexFunction" and that will, by default, export everything. However, I think that works for gcc/ld only and is also not the ideal solution if we are compiling complex .c/.cpp files with many functions of which only one should be seen.
Best regards
George ----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Wednesday, April 08, 2009 1:07 PM Subject: Re: [DynareDev] Sparse Hessian
Hi George,
it appears that it isn't simple to force mex to make Dynamic a public symbol exported by a mex DLL. Furthermore, we are a bit disappointed with the performance and compilation time for the dynaremic/static DLL On the other hand, Ferhat reports good performance for his strategy of storing the model tree produced by the preprocessor in a binary file and executing it in his simulate DLL. Our current proposal is to drop dynamic/static DLL and replace it with Ferhat procedure. This would also eliminate the need for users to provide a compiler. This shouldn't change anything about your code except the name of the DLL to be called. So, for the time being, you should keep compiling manually the dynamic dll for your examples/tests with public dynamic and we provide the alternative when we are ready at our end.
Tell me all what you think. I will aslo put a post on theforum about dropping the USE_DLL option
Best
Michel
G. Perendia wrote:
We currently call dynamic() function directly from k_order_perturbation dll. So, for this to work properly, would it be possible that, in future, the Dynamic() function is also exported/published by the DLL as well as (i.e.in addition to) the mexFunction()?
Best regards George ----- Original Message ----- From: "Michel Juillard" Michel.Juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Tuesday, April 07, 2009 2:29 PM Subject: Re: [DynareDev] Sparse Hessian
For the Matlab functions it is clearly superior to get a sparse Hessian
from
the DLL.
On the other hand, perturbation DLL doesn't use sparse code for the time being, so maybe the optimal solution is for the preprocessor to make a different DLL if perturbation.dll is called and avoid perturbation.dll and dynamic.dll
to
pass Matlab matrices (sparse or non sparse).
Sebastien, can you add an option to the preprocessor whether static and dynamic DLLs return full or sparse matrices?
Best
Michel
Quoting "G. Perendia" george@perendia.orangehome.co.uk:
I already committed the change but you may revoke it back once sparse hessian is coming back from the DLL.
However, I have to say, it would have been rather more difficult to read
a
sparse hessian from dynamic_DLL into the k-Order perturbation.dll. I.e.,
for
Dynare++ integration we already assume and use the plain 2D matrix
hessian -
I will then also need to make some changes once I know how it is going
to
be returned.
Best regards
George Perendia ----- Original Message ----- From: "Sébastien Villemot" sebastien.villemot@ens.fr To: dev@dynare.org Sent: Tuesday, April 07, 2009 1:50 PM Subject: Re: [DynareDev] Sparse Hessian
"G. Perendia" george@perendia.orangehome.co.uk a écrit :
PS: The below sparse Hessian issue occurs when one uses the use_dll option - i.e. the hessian from compiled <mod>_dynamic.dll is not
sparse
but
the one from the matlab version <mod>_dynamic.m is.
However, the solution I suggested below works in both cases
This is indeed an old issue that I need to fix in the preprocessor. I think it is better to fix it there rather than in the M-files. I will do the fix tonight or tomorrow.
Best
-- Sébastien Villemot
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