[PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
Martin Schied
crinimal at gmx.net
Thu Feb 26 01:34:10 CET 2009
hey, I like that approach...
I often used message boxes for list splitting in my current project
because they were the fastest solution I could find using a benchmark of
[t b b b] and [realtime].
Is there some obvious disadvantage I'm missing? Are messages one of the
fastest "objects" in pd?
I implemented this into a test patch using list-drip-quick and a
derivate with messages wich seems to be faster than list-drip-quick for
list containing more than 10 elements. Dind't try bigger lists, but it
should be the same speed gain. Is there a more elegant looking way,
especially for those dummy-elements I'm using?
cheers,
Martin
Mathieu Bouchard schrieb:
> On Wed, 25 Feb 2009, Hans-Christoph Steiner wrote:
>
>> Sounds very cool. Just out of curiosty, how did you measure the
>> speed difference? That would be a useful technic to know about for
>> testing in general.
>
> I use [t b a b] with [realtime], similar to enrique's, but i pass a
> float around for deciding of how many elements in the list. I made it
> automatically try several consecutive powers of two. I generated a
> large list using [#for] and [#to_list], but I included the generation
> of the list in the measurements I made. since then, I moved that part
> to above the [t b a b] so that it doesn't get measured. But that extra
> time is almost neglectible and taking it out would only result in a
> more insane speed ratio.
>
> I also tried [usertime] but it is not really more accurate than
> [realtime] and its resolution is much worse. [usertime] and
> [systemtime] is in GridFlow and just uses the OS's corresponding
> functions, and in Linux, they sort of suck.
>
> Finally I have just tried [tsctime], also from GridFlow, and this uses
> the CPU's built-in clock. When it does work, it's much more consistent
> than [realtime], but it can be fooled by the power-saving of the CPU,
> and it doesn't stop when switching to different processes, just like
> [realtime]. OTOH, [usertime] and [systemtime] do stop when switching
> processes, but they accumulate a lot of error.
>
> Ideally, you'd put the equivalent of [tsctime] straight in the Linux
> kernel's scheduler, and it'd measure the time locally per process. If
> you also put it in the Linux kernel's system-call gate, you can also
> rewrite the usertime/systemtime system-call to use that and get a
> million times more precision than the existing functions.
>
> Else, if you want an accurate measurement, you have to do it
> statistically. On average, making a test four times will get you twice
> more precision, so if you repeated the test 10 times and now you
> repeat it 1000 times, you will get one more trustable decimal in the
> average time.
>
> _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: list-drip-quick-test.pd
Type: application/puredata
Size: 9070 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090226/76b85213/attachment.bin>
More information about the Pd-list
mailing list