I was trying to include pragma comments of OpenMp in a PD external, but it does not seem to work for some reason. I tryed to look a bit on the web about Pd and parallel code but couldn't find any thing specific about OpenMP
- does the current architecture of Pd allow parallelization with OpenMP
directives?
I included a simple directive, it compiled with -fopenmp with no error nor warnings but in creation time (inside PD):
undefined symbol: GOMP_parallel_start dtw ... couldn't create
I found this [1] and also some references to Miller's conference about the topic in Brasil but couldn't figure out exactly if OpenMP is allowed in pd external code.
best regards, Pedro Lopes
[1] http://www.eecs.berkeley.edu/~demmel/cs267_Spr10/Lectures/Wessel_Final_ICMC2...http://www.eecs.berkeley.edu/%7Edemmel/cs267_Spr10/Lectures/Wessel_Final_ICMC2010.pdf
Hi,
I don't know if pd works with openmp.
For your undefined reference problem, you can try adding "-lgomp" to your compilation/linking command line. If that doesn't work, you may also have to point to the exact path of libgomp.so on your system.
E.g. on my system I would add this: -L/usr/lib/gcc/x86_64-linux-gnu/4.3 -lgomp
hope that helps,
- Vasilis
On Thu, May 20, 2010 at 4:46 PM, Pedro Lopes pedro.lopes@ist.utl.pt wrote:
I was trying to include pragma comments of OpenMp in a PD external, but it does not seem to work for some reason. I tryed to look a bit on the web about Pd and parallel code but couldn't find any thing specific about OpenMP
- does the current architecture of Pd allow parallelization with OpenMP
directives?
I included a simple directive, it compiled with -fopenmp with no error nor warnings but in creation time (inside PD):
undefined symbol: GOMP_parallel_start dtw ... couldn't create
I found this [1] and also some references to Miller's conference about the topic in Brasil but couldn't figure out exactly if OpenMP is allowed in pd external code.
best regards, Pedro Lopes
[1] http://www.eecs.berkeley.edu/~demmel/cs267_Spr10/Lectures/Wessel_Final_ICMC2...
-- Pedro Lopes contacto: jazz@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I can try, but it is weird because compiling a simple example of open mp on a .c file requires nothing else than -fopenmp flag.
I'll give feedback in a second.
On Thu, May 20, 2010 at 11:58 PM, Vasilis Liaskovitis vliaskov@gmail.comwrote:
Hi,
I don't know if pd works with openmp.
For your undefined reference problem, you can try adding "-lgomp" to your compilation/linking command line. If that doesn't work, you may also have to point to the exact path of libgomp.so on your system.
E.g. on my system I would add this: -L/usr/lib/gcc/x86_64-linux-gnu/4.3 -lgomp
hope that helps,
- Vasilis
On Thu, May 20, 2010 at 4:46 PM, Pedro Lopes pedro.lopes@ist.utl.pt wrote:
I was trying to include pragma comments of OpenMp in a PD external, but
it
does not seem to work for some reason. I tryed to look a bit on the web about Pd and parallel code but couldn't find any thing specific about
OpenMP
- does the current architecture of Pd allow parallelization with OpenMP
directives?
I included a simple directive, it compiled with -fopenmp with no error
nor
warnings but in creation time (inside PD):
undefined symbol: GOMP_parallel_start dtw ... couldn't create
I found this [1] and also some references to Miller's conference about
the
topic in Brasil but couldn't figure out exactly if OpenMP is allowed in
pd
external code.
best regards, Pedro Lopes
[1]
http://www.eecs.berkeley.edu/~demmel/cs267_Spr10/Lectures/Wessel_Final_ICMC2...http://www.eecs.berkeley.edu/%7Edemmel/cs267_Spr10/Lectures/Wessel_Final_ICMC2010.pdf
-- Pedro Lopes contacto: jazz@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
tryed both, still complains with the same error in pd output window. Seems that some OpenMP + PD issue is missing me (I'm still learning...).
best regards, Pedro
On Fri, May 21, 2010 at 12:16 AM, Pedro Lopes pedro.lopes@ist.utl.ptwrote:
I can try, but it is weird because compiling a simple example of open mp on a .c file requires nothing else than -fopenmp flag.
I'll give feedback in a second.
On Thu, May 20, 2010 at 11:58 PM, Vasilis Liaskovitis vliaskov@gmail.comwrote:
Hi,
I don't know if pd works with openmp.
For your undefined reference problem, you can try adding "-lgomp" to your compilation/linking command line. If that doesn't work, you may also have to point to the exact path of libgomp.so on your system.
E.g. on my system I would add this: -L/usr/lib/gcc/x86_64-linux-gnu/4.3 -lgomp
hope that helps,
- Vasilis
On Thu, May 20, 2010 at 4:46 PM, Pedro Lopes pedro.lopes@ist.utl.pt wrote:
I was trying to include pragma comments of OpenMp in a PD external, but
it
does not seem to work for some reason. I tryed to look a bit on the web about Pd and parallel code but couldn't find any thing specific about
OpenMP
- does the current architecture of Pd allow parallelization with OpenMP
directives?
I included a simple directive, it compiled with -fopenmp with no error
nor
warnings but in creation time (inside PD):
undefined symbol: GOMP_parallel_start dtw ... couldn't create
I found this [1] and also some references to Miller's conference about
the
topic in Brasil but couldn't figure out exactly if OpenMP is allowed in
pd
external code.
best regards, Pedro Lopes
[1]
http://www.eecs.berkeley.edu/~demmel/cs267_Spr10/Lectures/Wessel_Final_ICMC2...http://www.eecs.berkeley.edu/%7Edemmel/cs267_Spr10/Lectures/Wessel_Final_ICMC2010.pdf
-- Pedro Lopes contacto: jazz@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Pedro Lopes contacto: jazz@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes
Hi Pedro,
Somehow I thought this was a new message, but the date tells me it's from quite some time ago. Replying anyway as it may be interesting to you and all:
On Thu, May 20, 2010 at 4:46 PM, Pedro Lopespedro.lopes@ist.utl.pt wrote something roughly along the lines of:
I was trying to include pragma comments of OpenMp in a PD external, but it does not seem to work for some reason. undefined symbol: GOMP_parallel_start
OpenMP has a run time system that is linked into the executable when you compile with -fopenmp - if you compile a shared object (like a Pd external) with -fopenmp it hopes that the executable that loads it will have the OpenMP run time system inside it. So the fix is simple: just compile Pd itself with -fopenmp, then compile your external with -fopenmp too, and it should Just Work (TM). Attached patch against pd-0.42-5 allowed me to load a slightly modified version of gridflow and see Pd using more than one core:
http://claudiusmaximus.goto10.org/g/tech/pd-gridflow-openmp.png
(After applying the patch, run "autoreconf" to regenerate "./configure")
NB: while it does use more than one core, I just compared with the single core version of gridflow without openmp and it uses only 25% of my cpu (on one core) while the openmp version uses 145% of my cpu (spread over two cores). So, it's no magic bullet...
Claude
Thanks for the complete answer.
o, it's no magic bullet...
true. It is not. But when applied/tested into some specific situations it can truly help, my "external wanting openMP" does maxtrix work as hell, it could definitely need some multi-core help and split the matrix work over various core-loads.
I should have though about compiling pd :) Thanks, going for it.
best regards, Pedro
On Mon, Dec 6, 2010 at 10:34 AM, Claude Heiland-Allen < claudiusmaximus@goto10.org> wrote:
o, it's no magic bullet...
On Mon, 6 Dec 2010, Claude Heiland-Allen wrote:
NB: while it does use more than one core, I just compared with the single core version of gridflow without openmp and it uses only 25% of my cpu (on one core) while the openmp version uses 145% of my cpu (spread over two cores). So, it's no magic bullet...
I don't know how OpenMP works, but is there a way to apply it selectively to only part of a project ? I'm just guessing that it could make a big difference, e.g. if you don't apply it to numop*.cxx but you do apply it to much of the rest (perhaps also exclude gridflow.cxx itself because it contains the BitPacking class).
I just had this idea because of what you told me on the #dataflow chat.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Yep, the idea behind openMP is related to what you normally call directives or pragmas[1]. OpenMP offers a set of such directives so you can choose ways to parallelize *chunks* of your code accordingly to the best option you want. List of pragmas here [2].
The very basic example is a parallel for:
int main(int argc, char *argv[]) { const int N = 100000; int i, a[N];
#pragma omp parallel for
for (i = 0; i < N; i++)
a[i] = 2 * i;
return 0;}
And yes, you only type "#pragma omp parallel for" before the "for" statement. Nothing more. You can test within your systems for the results.
Now just a final, very important notice: I am no openMP expert, just looking for interesting ways of speeding things up, there are other as mentioned in this list, several other times.
[1] http://books.google.pt/books?id=MeFLQSKmaJYC&printsec=frontcover&dq=...
[2] http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=/co...
On Mon, Dec 6, 2010 at 3:09 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 6 Dec 2010, Claude Heiland-Allen wrote:
NB: while it does use more than one core, I just compared with the single
core version of gridflow without openmp and it uses only 25% of my cpu (on one core) while the openmp version uses 145% of my cpu (spread over two cores). So, it's no magic bullet...
I don't know how OpenMP works, but is there a way to apply it selectively to only part of a project ? I'm just guessing that it could make a big difference, e.g. if you don't apply it to numop*.cxx but you do apply it to much of the rest (perhaps also exclude gridflow.cxx itself because it contains the BitPacking class).
I just had this idea because of what you told me on the #dataflow chat.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, 6 Dec 2010, Pedro Lopes wrote:
Yep, the idea behind openMP is related to what you normally call directives or pragmas[1]. OpenMP offers a set of such directives so you can choose ways to parallelize *chunks* of your code accordingly to the best option you want. List of pragmas here [2]. The very basic example is a parallel for:
Ok, well, I think that it's going to be hard to parallelise GridFlow like that, because almost all loops are medium-sized (more than enough for SIMD, but far from making sense for multithreading) and/or it makes too many calls to other functions in other objects that will have to be waiting for data to come in, due to GridFlow's packet-oriented nature (packets more like TCP/IP, not like PDP, but still based on function-calls).
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
to GridFlow's packet-oriented nature (packets more like TCP/IP, not like
PDP, but still based on function->calls) Yep, that's a consideration that will ultimately yield in a lot of dead times if its parallel. I can try to talk to some openMP heads and figure out if that's out of the equation or not.
Best regards, Pedro
On Mon, Dec 6, 2010 at 7:21 PM, Mathieu Bouchard matju@artengine.ca wrote:
e to GridFlow's packet-oriented nature (packets more like TCP/IP, not like PDP, but still based on function-calls)
On Mon, 6 Dec 2010, Pedro Lopes wrote:
to GridFlow's packet-oriented nature (packets more like TCP/IP, not like PDP, but still based on function->calls)
Yep, that's a consideration that will ultimately yield in a lot of dead times if its parallel. I can try to talk to some openMP heads and figure out if that's out of the equation or not.
can you do something like have a thread per object, such that :
[#for] | [#store] | [#convolve]
... runs in three threads ?
a GridOut struct is a transmission connector, and that's what's being passed in grid-messages. After the sending of the grid-message returns, each call to the .flow method «sends» a packet from one object to another. But you can't parallelise that all over because, quite often, the buffer used for that is reused immediately because it's assumed that the data is already consumed. However, in many other cases, the data being «sent» is just a piece of a grid that will stay constant (for at least until the transmission is over).
Frankly, I'm open to a lot of changes in grid.cxx's API, because I believe that it's not efficient enough (even from my totally single-threaded perspective), and I've been hesitating for too long about this. Perhaps that the ways to make it more efficient as a single thread will also be related to the ways to make it more threadable.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Claude Heiland-Allen -
Mathieu Bouchard -
Pedro Lopes -
Vasilis Liaskovitis