Hi Charles, I have a few partitioning methods. I used to do profiling when you first load the plugin, to determine the optimal partitioning, but found that on intel/amd cpus with sse3, it didn't vary much, and just hardcoded a simple rule set for when to use each partitioning style. In the more cross-platform context of pd, I think that profiling code might make sense again, I'll see if I can resurrect it.
-Seth On Tue, Apr 5, 2011 at 5:04 PM, Charles Henry <[email protected]> wrote: > > > On Tue, Apr 5, 2011 at 2:33 PM, Seth Nickell <[email protected]> wrote: >> >> Hi Mathieu, >> >> Thanks, I assumed (without checking :-P) that the dsp call happened >> every time, didn't realize it was a setup/patching call that registers >> my "_perform" function with a call graph. Exactly what I need. >> >> I think the difference in approach comes from the needs of the >> external. fiddle~ probably needs much larger blocks than typical to >> discriminate between low frequencies. In my case, I can run at 64 >> sample sizes, but I'll take your whole CPU to do it. It might be smart >> to default to some internal buffering (say 512), and let people order >> the external to do really really low latency if they need it and are >> willing to pay in CPU. > > Here's where your users' choice of block sizes comes in--if your user puts a > partitioned convolution external into a canvas with block size 64, it means > to be low-latency. If the user puts it in with [block~ 1024], then the > buffering is defined. > > Pd means to be ~user~programmable and modular. The more you try to monolith > your externals, the worse they work (I've done this). I know I'm not > expressing it well, but I hope the point comes through. > >> >> That said, Peter reminded me of an optimization that I hadn't >> implemented yet. AudioUnits are rarely asked to run below 128 sample >> block sizes, so it didn't make sense for the AU, and I forgot that it >> was on the TODO list from 2 years ago. ;-) By convolving very small >> blocks in the time domain, and switching to frequency domain for >> larger blocks, I think we can get excellent CPU usage at very small >> block sizes too. > > It sounds like you'd have a bit of a problem without first profiling the > system or having known profiles for different hardware. Can you tell me > more about your partitioning method (just the math)? > >> >> -Seth >> >> On Tue, Apr 5, 2011 at 8:49 AM, Mathieu Bouchard <[email protected]> >> wrote: >> > On Mon, 4 Apr 2011, Seth Nickell wrote: >> > >> >> Are the DSP calls liable to vary t_signal->s_n (block size) without >> >> notification? 64 samples, apparently the default on pd-extended, is >> >> doable without buffering for partitioned convolution on a modern >> >> computer, but it exacts a pretty high CPU toll, and if I have to >> >> handle random blocksize changes, it gets more expensive. >> >> >> >> Also, since convolution is much more efficient around block sizes of >> >> 256 >> >> or 512, perhaps I should default to one of these, buffer a little, and >> >> have >> >> a "runatpdblocksize" message or somesuch? >> > >> > There's always a notification. Any change of s_n will result in a new >> > call >> > to the dsp-function. >> > >> > Note that it's best to make sure that the dsp-function is fairly fast >> > most >> > of the times, because any patching may retrigger the dsp-function in >> > order >> > to recompile the graph. >> > >> > dsp objects working with some kind of blocks don't have to be using s_n >> > as a >> > setting. I mean that you can accumulate several dsp-blocks in order to >> > make >> > your own kind of bigger block. This is what [fiddle~] and [env~] do, for >> > example. >> > >> > But some other object classes use s_n as a setting. For example, [fft~] >> > does. I don't know why this is not consistent across all of pd. (I'm not >> > saying either approach is better than the other.) >> > >> > _______________________________________________________________________ >> > | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
