Re: [DynareDev] Dynare++ k-order-perturbation design

Hi George,

I think that you are on the right track

1. Calling <model>_dynamic:

there is a mex function mexCallMATLAB() which can call either internal MATLAB functions, .m files and/or, as well, other MEX files, whatever it finds appropriate. Thus, we may be able to call <model>_dynamic mex/dll as currently created by Dynare preporcessor directly from the new mex/dll file This option allows calls to <mod>_dynamic irrespective whether it is, or is not compiled as a mex function.

Although we should be able to improve performance, cut out the MATLAB intermediary overhead and use native .dll (.so) - thought that not tested yet - I suggest the mexCallMATLAB become implemented as a backup alternative used when if mex/dll is not compiled.

SURE

2. "mex" compilation (i.e. "to mex or not to mex?"):

On my Windows platform and with Matlab v.7.1., compiling & linking <a>.C files (containing mexFunction and linking the mex libs) as DLLs with either MSVC or minGW directly creates a DLL which can be called either with extension .DLL, or simply renamed as <a>.mexXX (e.g. changing extension from .DLL to .mexw32 on Win 32bit platform).

Thus, it seems that this direct approach does not require use of mex command (or the mexopts.bat),and, I wander if anyone tested if this approach works on Linux too(?). For time being I intend to use it at least for the prototyping in Windows (i.e. considering that n-order is not expected to be re-compiled on-the-go for the start at least).

Should be even easier in Linux. Please, tell us exactly which steps (and compiler/linker switches) you use to create a DLL( mexxxx) directly.

3. Re. MATLAB LAPACK:

Thanks for the suggestion to use it too but now I need to resolve some other issues. I.e., Due to MATLAB lapack idiosyncrasies:

a) MathWorks' mwlapack.lib in earlier versions was containing both

lapack and blas, but it has later been split into two libraries: mwlapack.lib - without blas - and the blas.lib - this creating some though small, linking problems,

This is the main reason why we have to maintain to separate sets of DLLss for older and for newer versions of Matlab

b) lapack functions in windows not having "_" suffix but having it on

the Linux platforms!?(%$£"@*), - i.e., this creating some more linking problems and poss some additional changes to the code to allow for the conditional compilation (i.e. some is already present in dynare++ and the current Dynare sylv mex source)

I think that there is no escape to testing for an environment variable saying if you are in Windows or not and having a macro setting the necessary completion of the function name depending on the environment.

c) apparently, according to MathWorks documentation, on windows, their

mwlapack is supported only for MSVC (and I could not get it to link properly with minGW but poss. due to different reasons) !? (ditto.).

Again, as we may not be recompiling n-order on the fly, for a time being it seems that it may be simpler to use minGW and the "native" lapack and atlas libraries for generating n-order .DLL rather than Matlab's LAPACK- again, at least for prototyping and poss. its first release?!.

Mathworks doesn't support gcc in the Windows envrionment, but I was able to link gcc compiled code with their libraries for MSVC.

4. Regarding mxMalloc -

Michel was right - it is recommended for all malloc calls within mex files so that Matlab can ensure freeing memory when mex call is finished, but it is not obligatory and, probably not necessary when if the C/C++ code carefully deletes all allocated memory itself (which seems to be the case with both Dynare++ k-order-perturbation and the Markov Switching code but should be checked but I will double check it.)

OK, if there is memory problem, Matlab most likely aborts abruptly.

All the best,

Michel

Please do let me know your thoughts.

Best regards

George

---

Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev