hi all, especially miller, matju and winfried ...
just a few comments, since i had to leave very early ...
- i'd definitely prefer to use multiple threads instead of multiple processes, since it's easier to share data, since we don't have the socket connection ... on the other hand, it wouldn't be that easy to build a custom gui for pd ... (except when adding a send/recv h anyway, since the tcl/tk code is virtually everywhere in the pd core, it's already pretty impossible to build a custom gui ... still, i'd strongly vote for seperating g
- a short time ago, i was doing some low latency benchmarks ... it seems that the send / recv system calls should be avoided in a realtime thread ... having a gui _thread_ it would be possible to synchronize gui / kernel via the lock-free fifos, that are implemented in devel ...
basically, i'm not sure, if we should use an external scripting language for the gui at all ... of course, it's faster to write and easier to maintain, but it's usually much slower than plain c ...
cheers ... tim
Hallo!
Sorry dor the maybe stupid question, but is there a record of the meeting yesterday ? (because it sounds interesting ...:)
LG Georg
Hi Tim,
I'm curious... this send/recv bottleneck is on linux?
thanks Miller
On Sat, May 28, 2005 at 11:19:51AM +0200, Tim Blechmann wrote:
hi all, especially miller, matju and winfried ...
just a few comments, since i had to leave very early ...
- i'd definitely prefer to use multiple threads instead of multiple
processes, since it's easier to share data, since we don't have the socket connection ... on the other hand, it wouldn't be that easy to build a custom gui for pd ... (except when adding a send/recv h anyway, since the tcl/tk code is virtually everywhere in the pd core, it's already pretty impossible to build a custom gui ... still, i'd strongly vote for seperating g
- a short time ago, i was doing some low latency benchmarks ... it seems
that the send / recv system calls should be avoided in a realtime thread ... having a gui _thread_ it would be possible to synchronize gui / kernel via the lock-free fifos, that are implemented in devel ...
basically, i'm not sure, if we should use an external scripting language for the gui at all ... of course, it's faster to write and easier to maintain, but it's usually much slower than plain c ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
hi miller ...
I'm curious... this send/recv bottleneck is on linux?
i only did some timing tests on linux ... iirc the system calls take about 300 to 500 us ... since i'm using a callback based scheduling for lowest latencies and i have to synchronize with the main pd thread by using the sys_lock, the send/recv calls might block the realtime thread from being executed for this time ... so if a callback that is being called every 1.5 ms is blocked for 500us, it is pretty likely to experience a dropout ... not sure, what happens, if sys_vgui() is called several times between two dsp callbacks ...
cheers ... tim
Wow, that's disappointing. On the other hand, Pd shouldn't be calling send or recv unless it finds itself idle - so theoretically this should add only one send/recv call in latency. If it's in fact worse than that, it's probably a scheduler bug.
cheers Miller
On Mon, May 30, 2005 at 01:18:02AM +0200, Tim Blechmann wrote:
hi miller ...
I'm curious... this send/recv bottleneck is on linux?
i only did some timing tests on linux ... iirc the system calls take about 300 to 500 us ... since i'm using a callback based scheduling for lowest latencies and i have to synchronize with the main pd thread by using the sys_lock, the send/recv calls might block the realtime thread from being executed for this time ... so if a callback that is being called every 1.5 ms is blocked for 500us, it is pretty likely to experience a dropout ... not sure, what happens, if sys_vgui() is called several times between two dsp callbacks ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Wow, that's disappointing. On the other hand, Pd shouldn't be calling send or recv unless it finds itself idle - so theoretically this
well, i thought about opening the sys_lock during these calls ... but a threaded solution is way cleaner ...
should add only one send/recv call in latency. If it's in fact worse than that, it's probably a scheduler bug.
well, i had to rewrite the scheduler for callback based scheduling, which works a bit different ... i'm going to check it again ...
cheers .... tim
On May 28, 2005, at 5:19 AM, Tim Blechmann wrote:
hi all, especially miller, matju and winfried ...
just a few comments, since i had to leave very early ...
- i'd definitely prefer to use multiple threads instead of multiple
processes, since it's easier to share data, since we don't have the socket connection ... on the other hand, it wouldn't be that easy to build a custom gui for pd ... (except when adding a send/recv h anyway, since the tcl/tk code is virtually everywhere in the pd core, it's already pretty impossible to build a custom gui ... still, i'd strongly vote for seperating g
- a short time ago, i was doing some low latency benchmarks ... it
seems that the send / recv system calls should be avoided in a realtime thread ... having a gui _thread_ it would be possible to synchronize gui / kernel via the lock-free fifos, that are implemented in devel ...
basically, i'm not sure, if we should use an external scripting language for the gui at all ... of course, it's faster to write and easier to maintain, but it's usually much slower than plain c ...
For all of Tcl's warts, it is an essential element of what makes Pd so great. It is not an application but instead a flexible, open-ended platform, especially when you consider things like toxy. Writing the GUI in OS-native C would change that. I don't think some optimization is worth the loss of flexibility. CPUs are only getting cheaper.
.hc
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
-
Georg Holzmann -
Hans-Christoph Steiner -
Miller Puckette -
Tim Blechmann