hi all,
these are transfer rates for the connection from pd.38 to pd-gui, measured on an 800MHz PC (the only box I have with windows):
windows xp, Miller's pdtcl.dll 430Kb/s linux 2.4, Miller's pd-gui 24Mb/s
linux performs over 50 times faster... and I think it scales (2.66MHz linux PC transfers 80Mb/s, no windows there to confirm, though).
Perhaps, I should ask windows expert users out there: do not you think this should be improved?
What I did was repeatedly sending tcl comments (1Kb long each) via a tot, and storing "clock clicks -milliseconds" readings made after various amounts of transferred data.
Then I tried reducing the polling interval in window's pd.tk (originally 20ms) and got
10ms polling 810Kb/s 5ms polling 1.6Mb/s
Reducing it further was a bad idea: 1ms interval forced wish84.exe to consume over 90% of cpu by doing nothing else but polling an empty socket.
Then I tried to replace polling with setting a "fileevent" callback on a tcl socket channel. Loaded a modified pd.tk directly via wish first, then run "pd.exe -guiport", and got
fileevent-callback 3.5Mb/s
so, unfortunately, tcl channel adds too much overhead...
Have not tried with ws2_32.dll yet. I am tired, this is not my platform.
Any clue?
Krzysztof
hiya,
On Mar 10, 2005, at 2:11 PM, Krzysztof Czaja wrote:
these are transfer rates for the connection from pd.38 to pd-gui, measured on an 800MHz PC (the only box I have with windows):
windows xp, Miller's pdtcl.dll 430Kb/s linux 2.4, Miller's pd-gui 24Mb/s
...
What I did was repeatedly sending tcl comments (1Kb long each) via a tot, and storing "clock clicks -milliseconds" readings made after various amounts of transferred data.
...would it be possible to make available this test patch? It would be good for all to have a standard set of benchmarks (and I'd be happy to try it out on OSX ;-) )...
thanx, james
On Mar 10, 2005, at 4:44 PM, james tittle wrote:
On Mar 10, 2005, at 2:11 PM, Krzysztof Czaja wrote:
these are transfer rates for the connection from pd.38 to pd-gui, measured on an 800MHz PC (the only box I have with windows):
windows xp, Miller's pdtcl.dll 430Kb/s linux 2.4, Miller's pd-gui 24Mb/s
...thanx for putting this in cvs: in my first runs (but running inside gdb for other reasons) using 0.38-4, I'm getting anywhere from 8 to 11 Mb/s with OSX...17Mb/s for the 50000, 18 Mb/s on 80000...
...btw, I've been using (and would like to publicize) this patch for pd on OSX:
http://sourceforge.net/tracker/index.php? func=detail&aid=1083495&group_id=55736&atid=478072
...the upside is that it allows me to use pdp2gem on osx...the downside is that I had to compile the miXed externals without using "-flat_namespace" (by default, osx builds two level namespace)...
thanx! james
how do these throughput measuments really reflect on actual performance characterisitics? ie, is the windows tk gui getting bottlenecked by this?
Krzysztof Czaja wrote:
hi all,
these are transfer rates for the connection from pd.38 to pd-gui, measured on an 800MHz PC (the only box I have with windows):
windows xp, Miller's pdtcl.dll 430Kb/s linux 2.4, Miller's pd-gui 24Mb/s
linux performs over 50 times faster... and I think it scales (2.66MHz linux PC transfers 80Mb/s, no windows there to confirm, though).
Perhaps, I should ask windows expert users out there: do not you think this should be improved?
What I did was repeatedly sending tcl comments (1Kb long each) via a tot, and storing "clock clicks -milliseconds" readings made after various amounts of transferred data.
Then I tried reducing the polling interval in window's pd.tk (originally 20ms) and got
10ms polling 810Kb/s 5ms polling 1.6Mb/s
Reducing it further was a bad idea: 1ms interval forced wish84.exe to consume over 90% of cpu by doing nothing else but polling an empty socket.
Then I tried to replace polling with setting a "fileevent" callback on a tcl socket channel. Loaded a modified pd.tk directly via wish first, then run "pd.exe -guiport", and got
fileevent-callback 3.5Mb/s
so, unfortunately, tcl channel adds too much overhead...
Have not tried with ws2_32.dll yet. I am tired, this is not my platform.
Any clue?
Krzysztof
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
how do these throughput measuments really reflect on actual performance characterisitics?
his throughput measurements are awefully polite ...see below.
ie, is the windows tk gui getting bottlenecked by this?
it may begin by numboxes or sliders failing to update and progress until you have to just wait it out or kill the app..
these are transfer rates for the connection from pd.38 to pd-gui, measured on an 800MHz PC (the only box I have with windows):
this 'real-world' test uses 256 element lists-of-floats.. after trickling over it's appended to a BLT::Vector..the gui-msg are also sent to a textfile object to find actual size....
samples sizeK ms speedK/s
windows (win32-xp-sp2): 11751 116 332 349.3975 51795 513 1573 326.1284 222743 2229 7072 315.1867 1404800 13722 51536 266.2605 2302720 (pd still at 100% after a couple mins)
linux (2.6.11-gentoo-r1 x86_64) well, i tried to run the test patch, but pd keeps crashing with this: *** glibc detected *** free(): invalid next size (fast): 0x000000000372aad0 ***
we have a winner...Windows!!
windows xp, Miller's pdtcl.dll 430Kb/s linux 2.4, Miller's pd-gui 24Mb/s
linux performs over 50 times faster... and I think it scales (2.66MHz linux PC transfers 80Mb/s, no windows there to confirm, though).
Perhaps, I should ask windows expert users out there: do not you think this should be improved?
windows (win32-xp-sp2): 11751 116 332 349.3975 51795 513 1573 326.1284 222743 2229 7072 315.1867 1404800 13722 51536 266.2605 2302720 (pd still at 100% after a couple mins)
linux (2.6.11-gentoo-r1 x86_64)
samples sizeK timeMS speedK/s
330685 3530 415 8506.02 2583240 25560 3370 7584.57
more like it; except pd_watchdog keeps brutally killing the session:
watchdog: signaling pd... X connection to :0.0 broken (explicit kill or server shutdown). recv: Connection reset by peer (104)
any easy way to put watchdog back in the doghouse?
we have a winner...Windows!!
On Fri, 11 Mar 2005 ix@replic.net wrote:
any easy way to put watchdog back in the doghouse?
You can start pd with the -nrt flag, which should avoid the problem with the watchdog. Anyhow, if you could give more information about your setup and how/when the watchdog kills pd, it might be possible to fix the problem. The watchdog should not kill pd but just slow it down a bit, in order to give the OS some time to do its tasks.
Guenter
we have a winner...Windows!!
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
ix@replic.net wrote: ...
this 'real-world' test uses 256 element lists-of-floats.. after trickling over it's appended to a BLT::Vector..the gui-msg are also sent to a textfile object to find actual size....
this seems like a lot of work for tcl, apart from reading a socket?
Krzysztof
this seems like a lot of work for tcl, apart from reading a socket?
couldnt really think of an easier way to integrate a Wavesurfer widget without shuttling the wav data over the gui connection (or using temp files). clearly some accel could be developed using VASP or a custom external to just send over the edits, but i'll leave MVC cleanliness for those who have a disdain for quick hacks :)
anyways, its no issue on linux..the delay only becomes noticeable with gigantic files..for those id rather use Samplitude anyways..
Krzysztof
Josh Steiner wrote:
how do these throughput measuments really reflect on actual performance characterisitics? ie, is the windows tk gui getting bottlenecked by this?
seems like it is, although I am not sure to what extent. Pd-gui is unresponsive and unstable on windows, which hurts toxy badly.
I do not now yet, how much of a bottleneck is the socket, compared to other factors, like internal performance problems of tcl/tk implementation on windows (memory mngmt in particular).
First impression, from looking at the fileevent-driven pd-gui: it performs better. Besides, it is much easier to do, than reimplementing tcl/tk...
Krzysztof
(sorry Josh for a "sender only" duplicate)
How did you do these tests? I'd very much like to get some OSX comparision, considering how much tcl/tk had to be improved (by James Tittle II) to make pd usable on OSX.
B>
Krzysztof Czaja wrote:
hi all,
these are transfer rates for the connection from pd.38 to pd-gui, measured on an 800MHz PC (the only box I have with windows):
windows xp, Miller's pdtcl.dll 430Kb/s linux 2.4, Miller's pd-gui 24Mb/s
linux performs over 50 times faster... and I think it scales (2.66MHz linux PC transfers 80Mb/s, no windows there to confirm, though).
Perhaps, I should ask windows expert users out there: do not you think this should be improved?
What I did was repeatedly sending tcl comments (1Kb long each) via a tot, and storing "clock clicks -milliseconds" readings made after various amounts of transferred data.
Then I tried reducing the polling interval in window's pd.tk (originally 20ms) and got
10ms polling 810Kb/s 5ms polling 1.6Mb/s
Reducing it further was a bad idea: 1ms interval forced wish84.exe to consume over 90% of cpu by doing nothing else but polling an empty socket.
Then I tried to replace polling with setting a "fileevent" callback on a tcl socket channel. Loaded a modified pd.tk directly via wish first, then run "pd.exe -guiport", and got
fileevent-callback 3.5Mb/s
so, unfortunately, tcl channel adds too much overhead...
Have not tried with ws2_32.dll yet. I am tired, this is not my platform.
Any clue?
Krzysztof
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
hi Ben,
B. Bogart wrote:
How did you do these tests? I'd very much like to get some OSX comparision, considering how much tcl/tk had to be improved (by James Tittle II) to make pd usable on OSX.
there is no socket problem on osx (James would agree, I guess).
Although I did use linux for comparison, the purpose of that test was actually only specific to pd-gui's implementation on windows. Since it is clear, that it performs very poorly, I am trying to answer two questions:
1. Is it due to the fact, that windows version polls the socket, unlike linux and osx versions, which are callback-based?
2. Could this be improved by replacing polling with high-level callback set with "fileevent ... readable" Tcl command or Tcl_CreateChannelHandler() call (low-level callbacks are not available on windows)?
Improving gui performance means making it responsive, stable, and visually smooth. Its impact on audio is quite another matter.
I am now pretty sure, that greedy guis, like toxy widgets, are crippled mostly by polling. Arrays also suffer, even more badly (visually), since their updates are queued, and the queue is served in small chunks triggered by pd getting an ack from the gui.
Krzysztof
-
B. Bogart -
g�nter geiger -
ix＠replic.net -
james tittle -
Josh Steiner -
Krzysztof Czaja