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

Hi

I still owe you this:

The following SINGLE command line illustration COMPILES AND LINKS fs2000a_dynamic.c in Windows DOS command console window using MingW gcc (and threads):

gcc -DMATLAB_MEX_FILE -mthreads -DPOSIX_THREADS -shared

-I"c:/Program Files"/MATLAB_SV71/extern/include -ofs2000a_dynamic.dll fs2000a_dynamic.c

< any other &&&.c or local ????.a files and then other lib params...>

-Wl,-L"c:/Program iles"/MATLAB_SV71/extern/lib/win32/microsoft/ -Wl,-llibmex -Wl,-llibmx

-Wl,-L"f:/CygWin/usr/local/atlas/lib" -Wl,-llapack -Wl,-lcblas -Wl,-lf77bla s

-Wl,-latlas -lg2c -lmingw32 -lstdc++ -Wl,-L"f:/Pthreads/Pre-built.2/lib" -W l,-lpthreadGC2

Of ocurse, this has much more (unused) libraries than needed for fs2000a_dynamic.c but they are there for illustration (and it also works too)

The above command links to the "NATIVE" lapack and cblas libraries but similarly, MATLAB mwlapack may be placed there instead as:

-Wl,-llibmwlapack -Wl,-llibdflapack

MinGW ld by default exports all symbols so that both mxFunction() can be called by MATLAB and the Dynamic() function should be callable directly by other C/C++ applications or another DLL (but that bit I have not managed to test yet).

As mentioned, the output <*>.dll may be renamed to <*>.mexw32 (or similar) and it works too.

Best regards

George

----- Original Message ----- From: "Michel Juillard" michel.juillard@ens.fr To: "List for Dynare developers" dev@dynare.org Sent: Friday, September 12, 2008 5:00 PM Subject: 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

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