Hi, there was a thread some time ago concerning compilation of PD for OSX with Codewarrior. With some efforts i managed to do it (the key is to enable "Enums always int" !) and i did some profiling with it. Surprisingly, the cpu load was practically identical between the gcc 3.1 and the CW8 build for all the patches of the pd doc that i tried out... so, since ProjectBuilder is free, it seems that there is no apparent reason to engage in the somehow tiresome compilation with CW. (there is also the additional issue that in order to build externals with CW, pd has to be split up into a dylib part and a main app part) Independently from that I also measured that a noticeable amount of cpu percentage is eaten up by the sys_getrealtime calls in the scheduler loop. Maybe there's a way to spare some of these calls? The other thing is that all the plus/minus/times dsp functions that are dominant for most patches could be easily accelerated using SIMD instructions (AltiVec on the PPC or SSE for Intel) since memory speed doesn't seem to be fully exploited here (signal vectors are in the cache). When i've got the time i'll transfer some of the flext SIMD code to the devel_0_37 branch.
best greetings, Thomas
I have been having trouble with compiling pd externs for Windows using Codewarrior. Do you know if the same things apply for Windows as you have written below for OSX? I've had good success compiling externs in gcc in Linux, but I had a lot of trouble trying to use gcc in Windows. I think mainly due to issuees related to file storage location and writing makefiles (which I know very little about). But I'm not sure what the cause really was.
Any ideas or advice?
On Wed, 6 Aug 2003, Thomas Grill wrote:
Hi, there was a thread some time ago concerning compilation of PD for OSX with Codewarrior. With some efforts i managed to do it (the key is to enable "Enums always int" !) and i did some profiling with it. Surprisingly, the cpu load was practically identical between the gcc 3.1 and the CW8 build for all the patches of the pd doc that i tried out... so, since ProjectBuilder is free, it seems that there is no apparent reason to engage in the somehow tiresome compilation with CW. (there is also the additional issue that in order to build externals with CW, pd has to be split up into a dylib part and a main app part) Independently from that I also measured that a noticeable amount of cpu percentage is eaten up by the sys_getrealtime calls in the scheduler loop. Maybe there's a way to spare some of these calls? The other thing is that all the plus/minus/times dsp functions that are dominant for most patches could be easily accelerated using SIMD instructions (AltiVec on the PPC or SSE for Intel) since memory speed doesn't seem to be fully exploited here (signal vectors are in the cache). When i've got the time i'll transfer some of the flext SIMD code to the devel_0_37 branch.
best greetings, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hi Becky,
I have been having trouble with compiling pd externs for Windows using Codewarrior. Do you know if the same things apply for Windows as you have written below for OSX? I've had good success compiling externs in gcc in Linux, but I had a lot of trouble trying to use gcc in Windows. I think mainly due to issuees related to file storage location and writing makefiles (which I know very little about). But I'm not sure what the cause really was.
What exactly are the problems you are writing about? (compiler errors, linker errors, etc...) I have no access to CW for Windows but i think that generally it should work. The fundamental problem of the OSX CW version that can't link to the monolithic pd application is no issue for Windows where pd is split into two parts anyway. I also found it quite straightforward to use cygwin gcc under Windows. You might want to have a look at the project files of some of my externals in case you are not confused by the fact that these are all using flext. (e.g. flext tutorials, http://www.parasitaere-kapazitaeten.net/ext/flext)
best greetings, Thomas
-
Becky Currano -
Thomas Grill