Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: > Well, what do you want to do without [list length]? I say kill all the old > versions of Pd. Well, I included list length, so it will break on old Pd. I don't follow Pd-extended and I don't remember when [list length] was introduced and when it got fixed to count meta messages as lists neither when settable sends were introduced and I didn't want to look it up so I just played it a tiny bit save - as save ay my educated guesses took me. Not safe. :) > Instead of always looking after Pd 0.39, Why not look after Pd 0.43 ? I > think that the explanation for why [list-drip-quick] is the way it is, > should serve as an example of things that could be changed in Vanilla or > added to Vanilla... as long as you consider Vanilla to be the reference. To me, Vanilla is the reference, but being a bit considerated of others didn't hurt here. > I use font size 10 and they don't overlap and never have. Okay, I took a closer look and here (vanilla, Linux, 0.41) the objects that are next to each other share their right-left borders exactly. So you're right, they don't overlap, but again, as the various GUI changes of Pd-extended and probably those, that Miller is working on, lead to varying box sizes across versions and platforms, I prefer to have a bit more cushion around them in all [list]-abs. > Well, in any case where the highest speed is appreciated and order is not > important, reverse dripping is faster than forward dripping, with today's > pd. Ah, good you remind me of that: I'll add a note to the help files. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
On Thu, 26 Feb 2009, Frank Barknecht wrote: I took the version without the message box optimization Well, I think that the switch from a O(n^2) abstraction to any of the O(n) abstractions is such a great improvement, that there is not so much need for more. But basically, all further optimisations replace the right-hand part of the patch by a special-case dripper that only work on small list sizes. for now to keep it a little bit compatible with older Pds that don't have settable sends - though I fear, a missing [list length] breaks it on older Pds anyway. I could have added [list-len] instead but that probably eats up all speed gains. Well, what do you want to do without [list length]? I say kill all the old versions of Pd. If you don't know what to do or if life seems too easy, support old versions of Pd, back to 0.35. But there's a limit to self-inflicted torture. Pd is already limited enough by what you can use in recursive patches... cold inlets unusable, so, have to use [list length] twice... can't reasonably pass a list and something else in the same message either, because it would requiring copying the said list. no nested lists of any kind. Instead of always looking after Pd 0.39, Why not look after Pd 0.43 ? I think that the explanation for why [list-drip-quick] is the way it is, should serve as an example of things that could be changed in Vanilla or added to Vanilla... as long as you consider Vanilla to be the reference. The message box version is in my 43 folders to be added sometime later. I added the EOL-outlet of the original list-drip and a bit more air around the objects so they don't overlap with font size 10. I use font size 10 and they don't overlap and never have. Additionally I added a [list-rdrip] for reverse serialization that uses the same approach, but with just one center-splitter. May come in handy sometimes. Well, in any case where the highest speed is appreciated and order is not important, reverse dripping is faster than forward dripping, with today's pd. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: > Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: > > > On Wed, 25 Feb 2009, Frank Barknecht wrote: > > > > >Anyway: Would it be okay to use it in [list]-abs which has Pd's BSD > > >license? > > > > Yes. > > Wonderful! I'll include it. Okay, it's in now. I took the version without the message box optimization for now to keep it a little bit compatible with older Pds that don't have settable sends - though I fear, a missing [list length] breaks it on older Pds anyway. I could have added [list-len] instead but that probably eats up all speed gains. The message box version is in my 43 folders to be added sometime later. I added the EOL-outlet of the original list-drip and a bit more air around the objects so they don't overlap with font size 10. Additionally I added a [list-rdrip] for reverse serialization that uses the same approach, but with just one center-splitter. May come in handy sometimes. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
On Thu, 26 Feb 2009, Martin Schied wrote: 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]. I just made an alternate version of [list-drip-quick] that is faster than [list-drip-quicker] without even using [repeat], and the difference is that it uses a pile of messageboxes for anything smaller than 9 elements. I use [s] with two inlets to dispatch the message because any solution involving [spigot] would be much slower and cumbersome, and anything using [demux] would be using an external. I made it after reading your mail but before looking at your patch, and it looks different from yours so I'm attaching it. So, the score is (for a 32768-element list): [list-drip] ~1 ms [list-drip-quick] ~28.5 ms [list-drip-quicker] ~10.0 ms [list-drip-quick2] ~7.2 ms [list-drip-schied] ~6.0 ms [list-drip-schied2]~5.1 ms [drip] ~1.1 ms The [list-drip-schied2] is done by replacing the split32 by a single messagebox with commas in it. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec#N canvas 545 187 595 440 10; #X obj 33 54 t a a; #X obj 33 111 spigot; #X obj 72 73 bang; #X obj 72 92 1; #X obj 151 73 bang; #X obj 151 92 0; #X obj 71 178 list split; #X obj 100 130 list length; #X obj 100 149 >> 1; #X obj 33 130 t a a a a; #X obj 33 266 list split; #X obj 52 202 list length; #X obj 52 221 >> 1; #X obj 33 19 inlet; #X text 75 19 Copyright 2009 by Mathieu Bouchard; #X obj 230 46 t a a; #X obj 223 371 outlet; #X obj 269 46 list length; #X obj 230 65 s; #X obj 312 94 r \$0-f1; #X obj 313 134 r \$0-f2; #X msg 313 153 \$1 \, \$2; #X obj 269 65 makefilename \$0-f%d; #X obj 313 172 r \$0-f3; #X msg 313 191 \$1 \, \$2 \, \$3; #X obj 313 212 r \$0-f4; #X msg 313 231 \$1 \, \$2 \, \$3 \, \$4; #X obj 313 252 r \$0-f5; #X msg 313 271 \$1 \, \$2 \, \$3 \, \$4 \, \$5; #X obj 313 292 r \$0-f6; #X msg 313 311 \$1 \, \$2 \, \$3 \, \$4 \, \$5 \, \$6; #X obj 313 332 r \$0-f7; #X msg 313 351 \$1 \, \$2 \, \$3 \, \$4 \, \$5 \, \$6 \, \$7; #X obj 313 372 r \$0-f8; #X msg 313 391 \$1 \, \$2 \, \$3 \, \$4 \, \$5 \, \$6 \, \$7 \, \$8 ; #X obj 72 54 list split 9; #X connect 0 0 1 0; #X connect 0 1 35 0; #X connect 1 0 9 0; #X connect 2 0 3 0; #X connect 3 0 1 1; #X connect 4 0 5 0; #X connect 5 0 1 1; #X connect 6 0 0 0; #X connect 7 0 8 0; #X connect 8 0 6 1; #X connect 9 0 10 0; #X connect 9 1 11 0; #X connect 9 2 6 0; #X connect 9 3 7 0; #X connect 10 1 0 0; #X connect 11 0 12 0; #X connect 12 0 10 1; #X connect 13 0 0 0; #X connect 15 0 18 0; #X connect 15 1 17 0; #X connect 17 0 22 0; #X connect 19 0 16 0; #X connect 20 0 21 0; #X connect 21 0 16 0; #X connect 22 0 18 1; #X connect 23 0 24 0; #X connect 24 0 16 0; #X connect 25 0 26 0; #X connect 26 0 16 0; #X connect 27 0 28 0; #X connect 28 0 16 0; #X connect 29 0 30 0; #X connect 30 0 16 0; #X connect 31 0 32 0; #X connect 32 0 16 0; #X connect 33 0 34 0; #X connect 34 0 16 0; #X connect 35 0 2 0; #X connect 35 2 4 0; #X connect 35 2 15 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
On Wed, 25 Feb 2009, Mathieu Bouchard wrote: I think that its biggest practical downside might be that's it slower on very small lists, but that's all. That's not true. It's actually faster. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list list-drip-quick-test.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
On Wed, 25 Feb 2009, Frank Barknecht wrote: Nothing really, but I still want to understand it. I added some comments in the attached version that describe how far I got with understanding. Am I completely off? Maybe. There is nothing that the code does on specifically the first two elements of the list. The [list split 2] just checks whether the list has more than one element, and if it has only one element, output it. There were several ways to do it, but they were about as complicated as each other. the [bang]s with the [spigot] are for making a conditional about lists longer than 1 element. after that, the splitting occurs recursively in equal halves just as in a merge-sort or binary-search on an array. Apart from that, I'd expect comments on an implementation to be at a higher level than the implementation. People can follow the wires and figure out what happens between two consecutive objects, but they most need to know what's the overall pattern of it and why things were done the way they were, because they couldn't learn that from anywhere else. My big mail to Enrique contains a lot of useful information about the patch. Other useful hints I could give are that the way the list is split, is like a balanced binary tree. It didn't have to be balanced, though, but that's sort of an ideal default, and it's really absolutely only to avoid stack overflow, though in other situations it does save a _lot_ of processing (merge-sort, binary-search...). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: > On Wed, 25 Feb 2009, Frank Barknecht wrote: > > >Anyway: Would it be okay to use it in [list]-abs which has Pd's BSD > >license? > > Yes. Wonderful! I'll include it. > >But now I'll have to digest the algorithm ... > > Well, you don't _have_ to... you could first swallow the algorithm, and > postpone the digestion to whenever you're ready. > > Because, if it has the right license, the right output, no stack > overflows, a higher speed and a lower memory usage, what's really wrong > with just using it? Nothing really, but I still want to understand it. I added some comments in the attached version that describe how far I got with understanding. Am I completely off? Ciao -- Frank #N canvas 218 94 758 591 10; #X obj 33 54 t a a; #X obj 33 211 spigot; #X obj 72 119 bang; #X obj 72 138 1; #X obj 193 119 route bang; #X obj 153 120 bang; #X obj 153 139 0; #X obj 72 84 list split 2; #X obj 202 349 list split; #X obj 269 298 list length; #X obj 269 320 >> 1; #X obj 33 230 t a a a a; #X obj 33 416 list split; #X obj 100 368 list length; #X obj 100 393 >> 1; #X obj 33 19 inlet; #X obj 260 145 outlet; #X text 75 19 Copyright 2009 by Mathieu Bouchard; #X text 289 347 Split list at center \, send first half back and repeat until there's only one element in the first half. This element is sent to the outlet and the spigot is closed. The previous list that has passed the open spigot consisted of the first two elements of the list. This is now handled by the next section.; #X text 399 307 Comments by Frank Barknecht:; #X text 38 448 Split list at center \, sent second half back. If second half has only one element \, this is sent to the outlet \, the spigot stays closed and this branch finishes. If the second half has more than one element \, the spigot gets opened again with the second half of the list. This now is sent through the [t a a a a] again \, where it meets the front splitter again which will reduce it to its first element again.; #X connect 0 0 1 0; #X connect 0 1 7 0; #X connect 1 0 11 0; #X connect 2 0 3 0; #X connect 3 0 1 1; #X connect 4 1 16 0; #X connect 5 0 6 0; #X connect 6 0 1 1; #X connect 7 0 2 0; #X connect 7 2 4 0; #X connect 7 2 5 0; #X connect 8 0 0 0; #X connect 9 0 10 0; #X connect 10 0 8 1; #X connect 11 0 12 0; #X connect 11 1 13 0; #X connect 11 2 8 0; #X connect 11 3 9 0; #X connect 12 1 0 0; #X connect 13 0 14 0; #X connect 14 0 12 1; #X connect 15 0 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
On Wed, 25 Feb 2009, Frank Barknecht wrote: Anyway: Would it be okay to use it in [list]-abs which has Pd's BSD license? Yes. But now I'll have to digest the algorithm ... Well, you don't _have_ to... you could first swallow the algorithm, and postpone the digestion to whenever you're ready. Because, if it has the right license, the right output, no stack overflows, a higher speed and a lower memory usage, what's really wrong with just using it? I think that its biggest practical downside might be that's it slower on very small lists, but that's all. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
On Wed, 25 Feb 2009, Enrique Erne wrote: ... and i thought my list-drip-custom would win :( could somebody explain how it exaclty works? well, first, the right-inlet of [list] makes a copy of your list, so this makes it take a lot more time when cutting lists into pieces. second, the left-inlet of [list] also makes a copy of your list, so this makes it take double the time that it just added, because [list] is a [list append], and it's appending a bang to a list, and a bang is an empty list, and it's not smart enough to skip the copy in that case. this makes a regular list-drip make n*n atom copies, whereas when you cut in chunks of 64, it makes n*n/64 atom copies, and then it makes 64*64*(n/64) = 64*n atom copies with the rest, almost. this also means that your recursion and [until] run at the same speed because they end up making the same copies, so you could achieve the same results with two levels of [until]. you can achieve more speed by adding extra levels of [until] and tuning the list chunk sizes for each level. then also if you use a pair of [list split]s and a counter to iterate through it, you have to use a [list] to hold it, and then it takes n*n steps because it's an append, and if you try to use [textfile] or a settable messagebox, it also copies because it's doing comma-expansion, so it's no better (note that [textfile] is very much like an invisible messagebox, there's no real parsing involved unless you load from a real file) so i figured out that I had to use [list split] with recursion without [list], so that it doesn't copy the sublists. but then, attempting to do it will output the elements in reverse order, so you have to use two [list split]s, which only copies n atoms (the absolute minimum). then, doing it with one or two [list split]s gets you a stack overflow very soon, so by recursing over half-lists you can use up only log(n)/log(2) levels of recursion. this only copies n atoms, so it's the minimum possible. when doing recursion, you have to be careful because pd's cold-inlets interfere with normal use of recursion... so, for example, I had to compute the half-list-size twice because I had two [list split]s. there are several ways in which pd falls just short of allowing a simple way. For example, just a simple [repeat] with a counter would be several times less objects, cords and tricks, and can be somewhat speedier than [list-drip-quick] because you can avoid a lot of the other things that [list-drip-quick] has to do besides copying n atoms. Actually, I just tried it with [repeat], and, the way I did it, it is consistently 2.9 times faster than [list-drip-quick]. But from the moment that you get it down to n atom copies, the speed differences don't tend to matter nearly as much, as the objects that receive the dripping will have to process n messages, and that is often taking more time than the splitting. So, a pure C external version of [list-drip] may be still several times faster than the [repeat] version, but only as long as you don't send its output to any object at all! In real-life situations, the speed difference is much thinner than the benchmarks, when the objects being benchmarks are both quite fast. Note that it's possible that adding to a messagebox cancels all speed improvements. Its running-time is either n copies or n*n/2 copies, because it's using a realloc, which may copy or not, depending on whether you're lucky. what license do you publish your code when you post code on the pd-list? same as puredata? yes, SIBSD license. well, it's on a case-by-case basis. there's no automatic license for anything, but let's say that [list-drip-quick] is SIBSD. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
Hallo Mathieu, wow, cool. But now I'll have to digest the algorithm ... Anyway: Would it be okay to use it in [list]-abs which has Pd's BSD license? Ciao -- Frank Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: > > seems like it would fit better on this mailing-list. > > -- Forwarded message -- > Date: Wed, 25 Feb 2009 11:38:27 -0500 (EST) > From: Mathieu Bouchard > To: Frank Barknecht > Cc: pd-...@iem.at > Subject: [PD-dev] extremely fast pure pd [list-drip] > > On Wed, 25 Feb 2009, Frank Barknecht wrote: > >> such a standard library would define an *interface* for standard >> objects. Where performance is an issue, the interface could alternatively >> implemented with externals. This also is exemplified in [list]-abs, >> where personally I use a version of [list-drip] that has zexy's [drip] >> inside for speed reasons. It behaves exactly like the abstraction >> version so it doesn't matter if people don't have zexy installed. > > i just made a pure-pd [list-drip] that is much much quicker for large > lists than your pure pd [list-drip]. > > For a list of size 32768, I find it to be at least 250 times faster. > > For a list of size 4096, it's at least 24 times faster. > > See attachment. > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec > #N canvas 0 0 450 300 10; > #X obj 33 54 t a a; > #X obj 33 111 spigot; > #X obj 72 73 bang; > #X obj 72 92 1; > #X obj 160 54 route bang; > #X obj 151 73 bang; > #X obj 151 92 0; > #X obj 72 54 list split 2; > #X obj 71 178 list split; > #X obj 100 130 list length; > #X obj 100 149 >> 1; > #X obj 33 130 t a a a a; > #X obj 33 266 list split; > #X obj 52 202 list length; > #X obj 52 221 >> 1; > #X obj 33 19 inlet; > #X obj 234 54 outlet; > #X text 75 19 Copyright 2009 by Mathieu Bouchard; > #X connect 0 0 1 0; > #X connect 0 1 7 0; > #X connect 1 0 11 0; > #X connect 2 0 3 0; > #X connect 3 0 1 1; > #X connect 4 1 16 0; > #X connect 5 0 6 0; > #X connect 6 0 1 1; > #X connect 7 0 2 0; > #X connect 7 2 4 0; > #X connect 7 2 5 0; > #X connect 8 0 0 0; > #X connect 9 0 10 0; > #X connect 10 0 8 1; > #X connect 11 0 12 0; > #X connect 11 1 13 0; > #X connect 11 2 8 0; > #X connect 11 3 9 0; > #X connect 12 1 0 0; > #X connect 13 0 14 0; > #X connect 14 0 12 1; > #X connect 15 0 0 0; > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
hi Mathieu nice abstraciton... ... and i thought my list-drip-custom would win :( could somebody explain how it exaclty works? what license do you publish your code when you post code on the pd-list? same as puredata? thanks eni Mathieu Bouchard wrote: seems like it would fit better on this mailing-list. -- Forwarded message -- Date: Wed, 25 Feb 2009 11:38:27 -0500 (EST) From: Mathieu Bouchard To: Frank Barknecht Cc: pd-...@iem.at Subject: [PD-dev] extremely fast pure pd [list-drip] On Wed, 25 Feb 2009, Frank Barknecht wrote: such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed. i just made a pure-pd [list-drip] that is much much quicker for large lists than your pure pd [list-drip]. For a list of size 32768, I find it to be at least 250 times faster. For a list of size 4096, it's at least 24 times faster. See attachment. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list #N canvas 0 22 880 375 10; #X obj 167 99 until; #X msg 183 193 add2 a; #N canvas 583 22 450 300 counter 0; #X floatatom 104 104 8 0 0 0 - - -; #X obj 222 106 inlet; #X obj 167 103 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 166 126 0; #X obj 263 198 + 1; #X obj 223 198 f 0; #X obj 223 144 b; #X connect 1 0 6 0; #X connect 2 0 3 0; #X connect 3 0 5 0; #X connect 4 0 5 1; #X connect 5 0 4 0; #X connect 5 0 0 0; #X connect 6 0 5 0; #X coords 0 -1 1 1 85 20 2 100 100; #X restore 183 127 pd counter; #N canvas 0 22 450 300 gettime 0; #X obj 214 122 realtime; #X floatatom 119 118 9 0 0 0 - - -; #X obj 211 61 t b b b; #X obj 302 128 outlet; #X obj 102 117 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 211 31 inlet; #X connect 0 0 1 0; #X connect 2 0 0 1; #X connect 2 1 3 0; #X connect 2 2 0 0; #X connect 4 0 2 0; #X connect 5 0 2 0; #X coords 0 -1 1 1 85 35 1 100 100; #X restore 72 197 pd gettime; #N canvas 0 22 450 300 gettime 0; #X obj 214 122 realtime; #X floatatom 119 118 9 0 0 0 - - -; #X obj 211 61 t b b b; #X obj 302 128 outlet; #X obj 102 117 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 211 31 inlet; #X connect 0 0 1 0; #X connect 2 0 0 1; #X connect 2 1 3 0; #X connect 2 2 0 0; #X connect 4 0 2 0; #X connect 5 0 2 0; #X coords 0 -1 1 1 85 35 1 100 100; #X restore 343 122 pd gettime; #X msg 204 72 100; #X msg 168 72 10; #X msg 250 71 1000; #N canvas 512 22 619 335 list-drip 0; #X obj 64 206 list split 1; #X obj 64 123 until; #X obj 64 181 list append; #X obj 194 206 bang; #X text 146 90 First store list \, then start the loop; #X text 163 118 "until" bangs its output until told to stop by a "bang" to its right inlet.; #X text 182 160 Store the remaining list.; #X text 239 205 third outlet of "split" tells us to stop.; #X obj 64 243 outlet; #X obj 64 57 inlet; #X text 237 44 From list-help.pd; #X obj 143 243 outlet; #X obj 64 86 t b a; #X connect 0 0 8 0; #X connect 0 1 2 1; #X connect 0 2 3 0; #X connect 0 2 11 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 3 0 1 1; #X connect 9 0 12 0; #X connect 12 0 1 0; #X connect 12 1 2 1; #X restore 379 169 pd list-drip; #N canvas 0 22 450 300 gettime 0; #X obj 214 122 realtime; #X floatatom 119 118 9 0 0 0 - - -; #X obj 211 61 t b b b; #X obj 302 128 outlet; #X obj 102 117 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 211 31 inlet; #X connect 0 0 1 0; #X connect 2 0 0 1; #X connect 2 1 3 0; #X connect 2 2 0 0; #X connect 4 0 2 0; #X connect 5 0 2 0; #X coords 0 -1 1 1 85 35 1 100 100; #X restore 496 97 pd gettime; #X obj 721 78 drip; #X msg 177 245; #X msg 342 225; #X msg 507 187; #X msg 255 185 set; #X msg 324 71 1; #X text 334 60 warning slow; #N canvas 0 22 431 325 list-drip-quick 0; #X obj 33 54 t a a; #X obj 33 111 spigot; #X obj 82 73 bang; #X obj 82 92 1; #X obj 180 54 route bang; #X obj 171 73 bang; #X obj 171 92 0; #X obj 82 54 list split 2; #X obj 101 188 list split; #X obj 130 130 list length; #X obj 130 149 >> 1; #X obj 33 130 t a a a a; #X obj 33 276 list split; #X obj 72 212 list length; #X obj 72 231 >> 1; #X obj 33 19 inlet; #X obj 274 54 outlet; #X text 75 19 Copyright 2009 by Mathieu Bouchard; #X connect 0 0 1 0; #X connect 0 1 7 0; #X connect 1 0 11 0; #X connect 2 0 3 0; #X connect 3 0 1 1; #X connect 4 1 16 0; #X connect 5 0 6 0; #X connect 6 0 1 1; #X connect 7 0 2 0; #X connect 7 2 4
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
hi hc i allway use a [t b b b] X [realtime] and connect the 2nd bang of the trigger to the operation that i want to measure. for measuring this operation multiple times you can add a [100( | [until] after the 2nd bang eni 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. > > .hc > > On Feb 25, 2009, at 11:43 AM, Mathieu Bouchard wrote: > >> seems like it would fit better on this mailing-list. >> >> -- Forwarded message -- >> Date: Wed, 25 Feb 2009 11:38:27 -0500 (EST) >> From: Mathieu Bouchard >> To: Frank Barknecht >> Cc: pd-...@iem.at >> Subject: [PD-dev] extremely fast pure pd [list-drip] >> >> On Wed, 25 Feb 2009, Frank Barknecht wrote: >> >>> such a standard library would define an *interface* for standard >>> objects. Where performance is an issue, the interface could >>> alternatively >>> implemented with externals. This also is exemplified in [list]-abs, >>> where personally I use a version of [list-drip] that has zexy's >>> [drip] >>> inside for speed reasons. It behaves exactly like the abstraction >>> version so it doesn't matter if people don't have zexy installed. >> i just made a pure-pd [list-drip] that is much much quicker for >> large lists than your pure pd [list-drip]. >> >> For a list of size 32768, I find it to be at least 250 times faster. >> >> For a list of size 4096, it's at least 24 times faster. >> >> See attachment. >> >> _ _ __ ___ _ _ _ ... >> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec> quick.pd>___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > > > > > > Programs should be written for people to read, and only incidentally > for machines to execute. > - from Structure and Interpretation of Computer Programs > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
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. .hc On Feb 25, 2009, at 11:43 AM, Mathieu Bouchard wrote: > > seems like it would fit better on this mailing-list. > > -- Forwarded message -- > Date: Wed, 25 Feb 2009 11:38:27 -0500 (EST) > From: Mathieu Bouchard > To: Frank Barknecht > Cc: pd-...@iem.at > Subject: [PD-dev] extremely fast pure pd [list-drip] > > On Wed, 25 Feb 2009, Frank Barknecht wrote: > >> such a standard library would define an *interface* for standard >> objects. Where performance is an issue, the interface could >> alternatively >> implemented with externals. This also is exemplified in [list]-abs, >> where personally I use a version of [list-drip] that has zexy's >> [drip] >> inside for speed reasons. It behaves exactly like the abstraction >> version so it doesn't matter if people don't have zexy installed. > > i just made a pure-pd [list-drip] that is much much quicker for > large lists than your pure pd [list-drip]. > > For a list of size 32768, I find it to be at least 250 times faster. > > For a list of size 4096, it's at least 24 times faster. > > See attachment. > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec quick.pd>___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [PD-dev] extremely fast pure pd [list-drip] (fwd)
seems like it would fit better on this mailing-list. -- Forwarded message -- Date: Wed, 25 Feb 2009 11:38:27 -0500 (EST) From: Mathieu Bouchard To: Frank Barknecht Cc: pd-...@iem.at Subject: [PD-dev] extremely fast pure pd [list-drip] On Wed, 25 Feb 2009, Frank Barknecht wrote: such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed. i just made a pure-pd [list-drip] that is much much quicker for large lists than your pure pd [list-drip]. For a list of size 32768, I find it to be at least 250 times faster. For a list of size 4096, it's at least 24 times faster. See attachment. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec#N canvas 0 0 450 300 10; #X obj 33 54 t a a; #X obj 33 111 spigot; #X obj 72 73 bang; #X obj 72 92 1; #X obj 160 54 route bang; #X obj 151 73 bang; #X obj 151 92 0; #X obj 72 54 list split 2; #X obj 71 178 list split; #X obj 100 130 list length; #X obj 100 149 >> 1; #X obj 33 130 t a a a a; #X obj 33 266 list split; #X obj 52 202 list length; #X obj 52 221 >> 1; #X obj 33 19 inlet; #X obj 234 54 outlet; #X text 75 19 Copyright 2009 by Mathieu Bouchard; #X connect 0 0 1 0; #X connect 0 1 7 0; #X connect 1 0 11 0; #X connect 2 0 3 0; #X connect 3 0 1 1; #X connect 4 1 16 0; #X connect 5 0 6 0; #X connect 6 0 1 1; #X connect 7 0 2 0; #X connect 7 2 4 0; #X connect 7 2 5 0; #X connect 8 0 0 0; #X connect 9 0 10 0; #X connect 10 0 8 1; #X connect 11 0 12 0; #X connect 11 1 13 0; #X connect 11 2 8 0; #X connect 11 3 9 0; #X connect 12 1 0 0; #X connect 13 0 14 0; #X connect 14 0 12 1; #X connect 15 0 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
