|Mathieu Bouchard||Feb 25, 2009 8:43 am||.pd|
|Hans-Christoph Steiner||Feb 25, 2009 9:15 am|
|Enrique Erne||Feb 25, 2009 10:24 am|
|Enrique Erne||Feb 25, 2009 10:54 am|
|Mathieu Bouchard||Feb 25, 2009 11:04 am|
|Frank Barknecht||Feb 25, 2009 11:04 am|
|Mathieu Bouchard||Feb 25, 2009 12:10 pm|
|Mathieu Bouchard||Feb 25, 2009 12:17 pm|
|Frank Barknecht||Feb 25, 2009 12:37 pm||.pd|
|Mathieu Bouchard||Feb 25, 2009 3:21 pm|
|Martin Schied||Feb 25, 2009 4:33 pm||.pd|
|Mathieu Bouchard||Feb 25, 2009 9:06 pm|
|Mathieu Bouchard||Feb 25, 2009 9:15 pm||.pd|
|Frank Barknecht||Feb 26, 2009 6:55 am|
|Mathieu Bouchard||Feb 26, 2009 7:45 am|
|Frank Barknecht||Feb 26, 2009 8:03 am|
|Subject:||Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)|
|From:||Mathieu Bouchard (mat...@artengine.ca)|
|Date:||Feb 25, 2009 11:04:18 am|
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