Thanks Marco, the Monfispol paper look perfect.
trunk/matlab/thread contains code written by Stephane for multithreaded Kronecker product DLL
I imagine that your code is relying on starting multiple instances of Matlab a very different approach and use from above. So I wouldn't put your code in the same directory. For now, put it in trunk/matlab and we will move it later when we have a better view of common functions that would be logical to regroup.
Best
Michel
Marco Ratto wrote:
Dear Michel,
we have drafted two documents for the state-of-the-art report. We kept them rather short, with the idea to just place MONFISPOL in the literature, avoiding a full dissertation on the topics which would make the report extremely long. Please have a look if they look OK to you.
We also have coded a generic MATLAB engine for parallelizing MATLAB loops. I would like to begin committing it in official dynare. I would like to know if you agree in committing those routines and where should I commit them: in trunk\matlab? in trunk\matlab\threads.
Concerning the new trunk\matlab\threads folder, I have a question: in our generic engine we have to code checks (error traps) for the number of processors actually present in the computer and so on. Do you have already coded them or we proceed autonomously on that?
Please let us know, All the best Marco
OK, many thanks. Concerning the parallel tools, we would have the random_walk_metropolis_hastings adapted and ready: shall we add a new version of it with something like a "P" flag, or do we overwrite the existing? We could start parallelizing other parts of dynare, like check plots, Gelman diagnostics, posterior smoother, IRF's, numerical Hessian computation? what do yo think would be best to start with? best wishes Marco, Ivano
Thanks Marco, the Monfispol paper look perfect.
trunk/matlab/thread contains code written by Stephane for multithreaded Kronecker product DLL
I imagine that your code is relying on starting multiple instances of Matlab a very different approach and use from above. So I wouldn't put your code in the same directory. For now, put it in trunk/matlab and we will move it later when we have a better view of common functions that would be logical to regroup.
Best
Michel
Marco Ratto wrote:
Dear Michel,
we have drafted two documents for the state-of-the-art report. We kept them rather short, with the idea to just place MONFISPOL in the literature, avoiding a full dissertation on the topics which would make the report extremely long. Please have a look if they look OK to you.
We also have coded a generic MATLAB engine for parallelizing MATLAB loops. I would like to begin committing it in official dynare. I would like to know if you agree in committing those routines and where should I commit them: in trunk\matlab? in trunk\matlab\threads.
Concerning the new trunk\matlab\threads folder, I have a question: in our generic engine we have to code checks (error traps) for the number of processors actually present in the computer and so on. Do you have already coded them or we proceed autonomously on that?
Please let us know, All the best Marco
Hi Marco,
Concerning the parallel tools, we would have the random_walk_metropolis_hastings adapted and ready: shall we add a new version of it with something like a "P" flag, or do we overwrite the existing?
Is there any good reason to keep the old version, knowing that we can get it back with SVN?
We could start parallelizing other parts of dynare, like check plots, Gelman diagnostics, posterior smoother, IRF's, numerical Hessian computation? what do yo think would be best to start with?
I would start with posterior distributions of various statistics
I just saw the following reference that seems very similar to what you are doing:
www.ia.pw.edu.pl/~karbowsk/jpar/jpar-para08-abstract.pdf
I also found a free parallel toolbox for Matlab. Maybe it is old and doesn't work anymore on recent Matlab version. Could somebody check?
http://www.ll.mit.edu/mission/isr/pmatlab/pmatlab.html
Best
Michel
best wishes Marco, Ivano
Thanks Marco, the Monfispol paper look perfect.
trunk/matlab/thread contains code written by Stephane for multithreaded Kronecker product DLL
I imagine that your code is relying on starting multiple instances of Matlab a very different approach and use from above. So I wouldn't put your code in the same directory. For now, put it in trunk/matlab and we will move it later when we have a better view of common functions that would be logical to regroup.
Best
Michel
Marco Ratto wrote:
Dear Michel,
we have drafted two documents for the state-of-the-art report. We kept them rather short, with the idea to just place MONFISPOL in the literature, avoiding a full dissertation on the topics which would make the report extremely long. Please have a look if they look OK to you.
We also have coded a generic MATLAB engine for parallelizing MATLAB loops. I would like to begin committing it in official dynare. I would like to know if you agree in committing those routines and where should I commit them: in trunk\matlab? in trunk\matlab\threads.
Concerning the new trunk\matlab\threads folder, I have a question: in our generic engine we have to code checks (error traps) for the number of processors actually present in the computer and so on. Do you have already coded them or we proceed autonomously on that?
Please let us know, All the best Marco
OK to overwrite the old version. Many thanks for the references. We will look at them Marco
Hi Marco,
Concerning the parallel tools, we would have the random_walk_metropolis_hastings adapted and ready: shall we add a new version of it with something like a "P" flag, or do we overwrite the existing?
Is there any good reason to keep the old version, knowing that we can get it back with SVN?
We could start parallelizing other parts of dynare, like check plots, Gelman diagnostics, posterior smoother, IRF's, numerical Hessian computation? what do yo think would be best to start with?
I would start with posterior distributions of various statistics
I just saw the following reference that seems very similar to what you are doing:
www.ia.pw.edu.pl/~karbowsk/jpar/jpar-para08-abstract.pdf
I also found a free parallel toolbox for Matlab. Maybe it is old and doesn't work anymore on recent Matlab version. Could somebody check?
http://www.ll.mit.edu/mission/isr/pmatlab/pmatlab.html
Best
Michel
best wishes Marco, Ivano
Thanks Marco, the Monfispol paper look perfect.
trunk/matlab/thread contains code written by Stephane for multithreaded Kronecker product DLL
I imagine that your code is relying on starting multiple instances of Matlab a very different approach and use from above. So I wouldn't put your code in the same directory. For now, put it in trunk/matlab and we will move it later when we have a better view of common functions that would be logical to regroup.
Best
Michel
Marco Ratto wrote:
Dear Michel,
we have drafted two documents for the state-of-the-art report. We kept them rather short, with the idea to just place MONFISPOL in the literature, avoiding a full dissertation on the topics which would make the report extremely long. Please have a look if they look OK to you.
We also have coded a generic MATLAB engine for parallelizing MATLAB loops. I would like to begin committing it in official dynare. I would like to know if you agree in committing those routines and where should I commit them: in trunk\matlab? in trunk\matlab\threads.
Concerning the new trunk\matlab\threads folder, I have a question: in our generic engine we have to code checks (error traps) for the number of processors actually present in the computer and so on. Do you have already coded them or we proceed autonomously on that?
Please let us know, All the best Marco
Hi All,
concerning the references provided by Michel on MATLAB parallel toolbox, we actually studied and tested them when we started the project on parallel a couple of years ago. Such a toolbox works well and looked to us (specially Ivano, our IT expert) the best available free toolbox for MATLAB.
This is really something like an openMP in MATLAB, and it is specially suited for clusters and parallel threads that need a quite large level of communication and message passing.
In the cases we are dealing now, however, the parallel jobs are totally independent and such a Toolbox adds a layer which makes the computational performance suboptimal (i.e. the speed-up was smaller than what we obtain with the routines developed here).
So, we decided to build something different (and simpler) here, which works optimally (in terms of speed-up) in all tests done for such jobs that can be `trivially' parallelized (parallel markov chains, simple Monte Carlo iterations like posterior IRF's smoother etc ... ), i.e. they go their own without any need to communicate between each other.
Of course, this other Toolbox would be of great help should be need to parallelize something more sophisticated, with need of message passing between threads.
Finally, I just read the e-mail from Sebastien: you're right to carefully consider the issue of multiplatform: we'll have a look at SSH windows.
all the best
Marco
Hi All,
since I will arrive in Paris airport on Wednesday at noon, I was wandering if I could meed some of you (let's say 2 pm onwards) and sit down looking into the parallel routines we developed here and how to proceed with the multi-platform. what do you think? please let me know.
all the best Marco
Hi All,
concerning the references provided by Michel on MATLAB parallel toolbox, we actually studied and tested them when we started the project on parallel a couple of years ago. Such a toolbox works well and looked to us (specially Ivano, our IT expert) the best available free toolbox for MATLAB.
This is really something like an openMP in MATLAB, and it is specially suited for clusters and parallel threads that need a quite large level of communication and message passing.
In the cases we are dealing now, however, the parallel jobs are totally independent and such a Toolbox adds a layer which makes the computational performance suboptimal (i.e. the speed-up was smaller than what we obtain with the routines developed here).
So, we decided to build something different (and simpler) here, which works optimally (in terms of speed-up) in all tests done for such jobs that can be `trivially' parallelized (parallel markov chains, simple Monte Carlo iterations like posterior IRF's smoother etc ... ), i.e. they go their own without any need to communicate between each other.
Of course, this other Toolbox would be of great help should be need to parallelize something more sophisticated, with need of message passing between threads.
Finally, I just read the e-mail from Sebastien: you're right to carefully consider the issue of multiplatform: we'll have a look at SSH windows.
all the best
Marco
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dear Marco,
I'm busy until 5pm, but I could meet with you around 5:30. Sebastien, do you want to spend some time with them before that at Chevaleret?
Best
Michel
Marco Ratto wrote:
Hi All,
since I will arrive in Paris airport on Wednesday at noon, I was wandering if I could meed some of you (let's say 2 pm onwards) and sit down looking into the parallel routines we developed here and how to proceed with the multi-platform. what do you think? please let me know.
all the best Marco
Hi All,
concerning the references provided by Michel on MATLAB parallel toolbox, we actually studied and tested them when we started the project on parallel a couple of years ago. Such a toolbox works well and looked to us (specially Ivano, our IT expert) the best available free toolbox for MATLAB.
This is really something like an openMP in MATLAB, and it is specially suited for clusters and parallel threads that need a quite large level of communication and message passing.
In the cases we are dealing now, however, the parallel jobs are totally independent and such a Toolbox adds a layer which makes the computational performance suboptimal (i.e. the speed-up was smaller than what we obtain with the routines developed here).
So, we decided to build something different (and simpler) here, which works optimally (in terms of speed-up) in all tests done for such jobs that can be `trivially' parallelized (parallel markov chains, simple Monte Carlo iterations like posterior IRF's smoother etc ... ), i.e. they go their own without any need to communicate between each other.
Of course, this other Toolbox would be of great help should be need to parallelize something more sophisticated, with need of message passing between threads.
Finally, I just read the e-mail from Sebastien: you're right to carefully consider the issue of multiplatform: we'll have a look at SSH windows.
all the best
Marco
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Hi all,
Michel Juillard michel.juillard@ens.fr a écrit :
I'm busy until 5pm, but I could meet with you around 5:30. Sebastien, do you want to spend some time with them before that at Chevaleret?
I will be at Chevaleret all the day, so 2pm is ok for me. I would be glad to discuss these issues, especially making parallel code multi-platform.
Best,
Ok, that's agreed then. See you on Wednesday! best Marco
Hi all,
Michel Juillard michel.juillard@ens.fr a écrit :
I'm busy until 5pm, but I could meet with you around 5:30. Sebastien, do you want to spend some time with them before that at Chevaleret?
I will be at Chevaleret all the day, so 2pm is ok for me. I would be glad to discuss these issues, especially making parallel code multi-platform.
Best,
Perfect, I will meet you there around 5:30pm
Best
Michel
Marco Ratto wrote:
Ok, that's agreed then. See you on Wednesday! best Marco
Hi all,
Michel Juillard michel.juillard@ens.fr a écrit :
I'm busy until 5pm, but I could meet with you around 5:30. Sebastien, do you want to spend some time with them before that at Chevaleret?
I will be at Chevaleret all the day, so 2pm is ok for me. I would be glad to discuss these issues, especially making parallel code multi-platform.
Best,
Hi all,
Marco Ratto wrote:
We also have coded a generic MATLAB engine for parallelizing MATLAB loops. I would like to begin committing it in official dynare. I would like to know if you agree in committing those routines and where should I commit them: in trunk\matlab? in trunk\matlab\threads.
If I remember well what you have presented, your parallel code only runs on Windows at the current time (using a special package for remotely running processes).
Maybe we should first discuss how to make this multi-platform, before incorporating it into main Dynare.
One solution would be to use SSH as the protocol for remotely running processes and for transferring files. SSH is the de facto standard for such things. It is shipped by default with Linux and MacOS, and there exists an easy to install SSH client/server for Windows: http://sshwindows.sourceforge.net/
Best,