[PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)

[Martin Schied]

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>