So me as user is slower i presume? How much slower? Can anyone comment please
On Mon Sep 15 09:54:09 EDT 2003, Hans-Christoph Steiner hans@eds.org wrote:
Not if you make the pd executable setuid root. To do so, run this (assuming your pd is installed in /usr/local/bin/pd):
sudo chown root /usr/local/bin/pd sudo chmod u+s /usr/local/bin/pd
Then pd will always run as root regardless of who started it.
This is a modest security risk though, setting any app setuid root is..hc
On Monday, Sep 15, 2003, at 07:25 America/New_York, Amos Elmaliah wrote:
hi i just starting to use pd, on a osx machine.
- i compiled it myself. my question: is it necessary to sudo pd
to get real time in osx?
amos.
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Its not necessarily slower, since it doesn't change the CPU. This just allows you to use the -realtime flag, which gives Pd elevated execution priority on the CPU. This means that it is harder to interrupt Pd and it will be allowed to use more of the CPU time. IMHO, I think this mostly affects dropouts and glitches, since Pd won't be interrupted as often by other processes (Aqua being a likely culprit since it uses a lot of CPU and runs at an elevated priority). But its possible that it could speed things up a little bit.
.hc
On Monday, Sep 15, 2003, at 10:35 America/New_York, PAGANO,PATRICK RALPH wrote:
So me as user is slower i presume? How much slower? Can anyone comment please
On Mon Sep 15 09:54:09 EDT 2003, Hans-Christoph Steiner hans@eds.org wrote:
Not if you make the pd executable setuid root. To do so, run this (assuming your pd is installed in /usr/local/bin/pd): sudo chown root /usr/local/bin/pd sudo chmod u+s /usr/local/bin/pd Then pd will always run as root regardless of who started it. This is a modest security risk though, setting any app setuid root is. .hc On Monday, Sep 15, 2003, at 07:25 America/New_York, Amos Elmaliah wrote:
hi i just starting to use pd, on a osx machine.
- i compiled it myself. my question: is it necessary to sudo pd to
get real time in osx? amos. _______________________________________________ PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Quoting Hans-Christoph Steiner hans@eds.org:
Its not necessarily slower, since it doesn't change the CPU. This just
allows you to use the -realtime flag, which gives Pd elevated execution
priority on the CPU. This means that it is harder to interrupt Pd and
it will be allowed to use more of the CPU time. IMHO, I think this mostly affects dropouts and glitches, since Pd won't be interrupted as
often by other processes (Aqua being a likely culprit since it uses a lot of CPU and runs at an elevated priority). But its possible that it
could speed things up a little bit.
OSX schedules time slices by thread not task, which is where the problems come in to play with pd. elevating the task priority of pd won't help at bit if the gui functions still take to long to execute in the pd task and don't leave time for the audio. the best (and probably final) solution to the problem is to put the audio and gui in separate threads so they can be scheduled separately. this is the _only_ way to schedule time slicing with reasonable results on OSX. again, every major piece of audio software already does this which is why Logic, Pro Tools, SuperCollider, etc are not effected by GUI actions like pd.
cgc
On Mon, 15 Sep 2003 cgc@humboldtblvd.com wrote:
OSX schedules time slices by thread not task,
if you want to say with this that tasks are not scheduled, then I think I disagree. PD has a separate GUI and Audio task, therefor setting higher priority on the audio task improves the realtime behaviour.
The problem that it does'nt always work as we would like lies in the "communication overhead".
Guenter
which is where the problems come in to play with pd. elevating the task priority of pd won't help at bit if the gui functions still take to long to execute in the pd task and don't leave time for the audio. the best (and probably final) solution to the problem is to put the audio and gui in separate threads so they can be scheduled separately. this is the _only_ way to schedule time slicing with reasonable results on OSX. again, every major piece of audio software already does this which is why Logic, Pro Tools, SuperCollider, etc are not effected by GUI actions like pd.
cgc
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi list, more OSX question; on what mostly does the performance level of pd rely? tk / compiler / actual code ? amos.
On Monday, September 15, 2003, at 02:20 PM, Amos Elmaliah wrote:
hi list, more OSX question; on what mostly does the performance level of pd rely? tk / compiler / actual code ? amos.
hi amos,
...by what do you mean performance? It is very easy to create an unusable patch by incorporating lots of number output boxes, or other visual feedback, and this is a cross-platform problem of using Tcl/Tk...however, as I mentioned previously, the specific implementation of Tk on OSX is based on quickdraw calls, which incur a huge penalty due to conversion of xrgb to argb pixels when redrawing parts of the screen; simple examples using only two number output boxes have been posted, showing that the "wish shell" hungrily takes up ~80% cpu, of which ~30-40% come from the pixel conversion (and that is using an altivec algorithm, to boot!)...
...I don't know of anyone successfully compiling pd or GEM on OSX using a compiler other than gcc, but it seems to be pretty well known that we could expect "faster" code; how much faster would be a total guess...
...as a last thought, it seems that alot of people new to pd, GEM, or
any other program are concerned with making it as fast as possible;
but this just reminds me of the old addage about "premature
optimization is the hobgoblin of programming"...meaning it's better to
get something working, then worry about performance improvements, if
necessary...I've found that some pretty amazing stuff can be
accomplished with pd/GEM, even with the current caveats ;-)
l8r, jamie
Quoting "PAGANO,PATRICK RALPH" bigswift@ufl.edu:
So me as user is slower i presume? How much slower? Can anyone comment please
about 0.0%
Running at root on OSX won't give you 'real-time' anything. OSX does however have full real-time thread support which pd doesn't take advantage of right now. By putting the audio in a real-time thread, the thread would never be pre-empted as long as the audio process completed in a negotiated amount of time. For example, the app tells the task manager that the thread needs x amount of time to complete and the task manager will always allot that time slice every second for the thread provided it doesn't exceed the allotment. iTunes is an example of real-time threads for audio on osx.
here's a brief overview of this: http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming...
-
Amos Elmaliah -
cgc＠humboldtblvd.com -
guenter geiger -
Hans-Christoph Steiner -
PAGANO,PATRICK RALPH -
tigital