Hi George,
I thought of yet another thing concerning the 1st order DLL. We need to implement the same type of weighted penalty as in resol.m for models for which we can't find the steady state and for models that violate Blanchard and Kahn conditions.
Best
Michel
Hi
1) Do we have a working and tested Dynare++ build environment for both Linux and Windows binaries a) under Linux b) under MingW/cygwin Windows?
2) I have had a rather taxing (sometimes interesting) time trying to re-build dynare++ on my Windows machine.
In a false expectations that I am just minutes from compiling Dynare ++, and, after so spending days of installing the whole dynare dev environment as suggested at the Dynare++ page ( lapack, cygwin, pthreads and MingW for window ) and recompiling and rebuilding Atlas library (which itself took approx. a day), going all the time forensically, two steps forward and one backward, I hit a few new problems. E.g.:
If I try to compile Dynare++ using MinGW gcc as recommended at the Dynare++ site, it seems to ignore both, the include and library paths specified with either CPATH, LD_LIBRARY_PATH or with individual options -I or -L or -isystem and, e.g. can not find the pthread.h (or the libcatlas libraries) that cygwin gcc (or cc) successfully finds, compiles and links using specified -I and -L options respectively (even with MingW ld).
Does anyone know a solution to this? (Note: ignorance of -L paths was noticed when I tired to link files successfully compiled with cygwin cc using MinGW )
3) Also, with building Dynare++ itself: (using cygwin gcc), among other problems, to be able to compile all files, as a temporary fix, I had to rename one of its functions (gettimeofday() in journal.cpp, by adding prefix D_ ) as it conflicts with a function of the same name in MingW's sys/time.h and same number of parameters.
Best regards
George
Additional thoughts:
1) if it is acceptable for you, you should try to compile the whole of dynare++ only under Linux as it is simpler. 2) for the parts that you port to Dynare Matlab, you should link against the Matlab Lapack libraries, using a scheme similar to the one we have now in ./mex/source/build.m for the existing DLL in Dynare Matlab.
All the best,
Michel
G. Perendia wrote:
Hi
- Do we have a working and tested Dynare++ build environment for both Linux
and Windows binaries a) under Linux b) under MingW/cygwin Windows?
- I have had a rather taxing (sometimes interesting) time trying to
re-build dynare++ on my Windows machine.
In a false expectations that I am just minutes from compiling Dynare ++, and, after so spending days of installing the whole dynare dev environment as suggested at the Dynare++ page ( lapack, cygwin, pthreads and MingW for window ) and recompiling and rebuilding Atlas library (which itself took approx. a day), going all the time forensically, two steps forward and one backward, I hit a few new problems. E.g.:
If I try to compile Dynare++ using MinGW gcc as recommended at the Dynare++ site, it seems to ignore both, the include and library paths specified with either CPATH, LD_LIBRARY_PATH or with individual options -I or -L or -isystem and, e.g. can not find the pthread.h (or the libcatlas libraries) that cygwin gcc (or cc) successfully finds, compiles and links using specified -I and -L options respectively (even with MingW ld).
Does anyone know a solution to this? (Note: ignorance of -L paths was noticed when I tired to link files successfully compiled with cygwin cc using MinGW )
- Also, with building Dynare++ itself: (using cygwin gcc), among other
problems, to be able to compile all files, as a temporary fix, I had to rename one of its functions (gettimeofday() in journal.cpp, by adding prefix D_ ) as it conflicts with a function of the same name in MingW's sys/time.h and same number of parameters.
Best regards
George
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Hi George,
- Do we have a working and tested Dynare++ build environment for both Linux
and Windows binaries a) under Linux
not really, Ondra's makefile makes assumption about the location of LAPACK that needs to be changed by hand. I was able to recompile dynare++ on Linux a year ago.
b) under MingW/cygwin Windows?
same for Windows, plus maybe additional issues related to Windows. I haven't recompiled dynare++ for Windows in several years.
- I have had a rather taxing (sometimes interesting) time trying to
re-build dynare++ on my Windows machine.
In a false expectations that I am just minutes from compiling Dynare ++, and, after so spending days of installing the whole dynare dev environment as suggested at the Dynare++ page ( lapack, cygwin, pthreads and MingW for window ) and recompiling and rebuilding Atlas library (which itself took approx. a day), going all the time forensically, two steps forward and one backward, I hit a few new problems. E.g.:
If I try to compile Dynare++ using MinGW gcc as recommended at the Dynare++ site, it seems to ignore both, the include and library paths specified with either CPATH, LD_LIBRARY_PATH or with individual options -I or -L or -isystem and, e.g. can not find the pthread.h (or the libcatlas libraries) that cygwin gcc (or cc) successfully finds, compiles and links using specified -I and -L options respectively (even with MingW ld).
Does anyone know a solution to this? (Note: ignorance of -L paths was noticed when I tired to link files successfully compiled with cygwin cc using MinGW )
I don't know if it is the issue, but the libraries must be compiled twice separately for cygwin and MingW
- Also, with building Dynare++ itself: (using cygwin gcc), among other
problems, to be able to compile all files, as a temporary fix, I had to rename one of its functions (gettimeofday() in journal.cpp, by adding prefix D_ ) as it conflicts with a function of the same name in MingW's sys/time.h and same number of parameters.
I think that there is comments from Ondra about that, but I don't remember where.
Best,
Michel
Best regards
George
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Hi
I have some technical design issues (and temporary work-arounds) for n-order perturbation integration into Dynare:
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.
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).
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,
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)
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?!.
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.)
Please do let me know your thoughts.
Best regards
George
Hi George,
I think that you are on the right track
- 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
- "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.
- 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 bothlapack 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 onthe 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, theirmwlapack 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.
- 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
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
- 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
- "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.
- 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 bothlapack 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 onthe 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, theirmwlapack 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.
- 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
PS:
Be aware, it seems that email manager has "eaten" some character such as "F" in -Wl,-L"c:/Program iles" - should be -Wl,-L"c:/Program Files"
Best regards
George ----- Original Message ----- From: "G. Perendia" george@perendia.orangehome.co.uk To: "List for Dynare developers" dev@dynare.org Sent: Thursday, September 18, 2008 11:54 AM Subject: 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
- 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
- "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.
- 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 bothlapack 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 onthe 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, theirmwlapack 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.
- 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
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Thanks George, If we want to automatize, we need to recuperate somehow the Matlab root directory In Linux, we can search with "which", but under Windows, this is not necessarily in an environment variable.
Best
Michel
G. Perendia wrote:
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
- 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
- "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.
- 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 bothlapack 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 onthe 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, theirmwlapack 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.
- 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
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
-
G. Perendia -
Michel Juillard