Re: [PD-dev] devel_0_39 ? devel_0_40 ?
On Tue, 2007-07-24 at 11:08 -0700, Miller Puckette wrote: On Mon, Jul 23, 2007 at 12:20:33PM +0200, Tim Blechmann wrote: Now for the hard part: in Pd, 32-bit floating point tables are stored as 64-but 'atoms' for a 50% hit in memory efficiency. Something Must Be Done; but what? split audio buffers and array-of-atoms? maybe this could include rewriting the whole audio buffers with an asynchronous interface ... imo, data structures and audio buffer have completely different real-time and performance constraints, so i see no real benefit in combining both concepts ... Well, I only just combined table~ with 'data structures' in 0.39 (I think), because there were hundreds of lines of essentially duplicate GUI code for the two types of arrays. The other complication is that I'm trying to design a new system of buffers suitable for images, perhaps with 8- 16- and 32- bit cells. It would be desirable for tabread4~ and all that to be able to talk to images too. Big design problem... the problem of generic design is, that you might have an implementation, that does everything more or less, but does nothing completely right ... like ... do you want/need 128bit alignment? do you want/need power-of-two sizes? what are your real-time constraints (1.3 ms or 40 ms deadlines)? can you affort to waste memory? generic design is great, if you don't have to sacrifice too much performance / usability ... i'm not sure about combining ds, audio buffers and video buffers (and maybe multi-dimensional matrices), though ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org I had nothing to offer anybody except my own confusion Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel_0_39 ? devel_0_40 ?
This explains a lot! Now for the hard part: in Pd, 32-bit floating point tables are stored as 64-but 'atoms' for a 50% hit in memory efficiency. Something Must Be Done; but what? OTOH, I'm falling out of my chair for joy that there's finally a way to write C code that doesn't choke on denormals. Life is indeed really simple, but I remain baffled :) M when compiling for x86_64, floating-point opertations are generated for the sse unit instead of the fpu ... seeing the increased number of xmm registers, less memory operations need to be used ... e.g. second order systems (biquad) can be computed in registers only ... another nice side-effect is the more robust handling of denormal numbers on the sse unit ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Life is really simple, but we insist on making it complicated. Confucius ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel_0_39 ? devel_0_40 ?
Cool... I'm especially excited about midi/audio patches, speaking only for myself :) On Sun, Jul 22, 2007 at 10:48:40PM +0200, Thomas Grill wrote: Hi all, i hate to be a spoiler, but the features that sleep in the devel branch are the topic of my talk at the pdconf. I'll commit a bit more stuff in the next couple of days... i hope to be able to use idle time at the convention to make patches against HEAD for the most important improvements that are in the devel branch (with decreasing priority: SIMD, portaudio, portmidi, multi threading stuff, idle callbacks). Apart from that i'm all for completely adandoning the devel branch in favor of patches to the patch tracker, which will also be one conclusion of my paper. all the best, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] devel_0_39 ? devel_0_40 ?
Is devel_0_40 still planned? It's getting closer to one year since the last changes to devel_0_39 were applied, apart from mine. So, what happened exactly? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel_0_39 ? devel_0_40 ?
As it happens I'm just having a look at devel_0_39, trying to compile it to see if I can get any latency wins from the callback scheduling and/or settable blocksizes. I think there are other enhancements in there (we heard recently about SYSEX MIDI on OSX) that warrant putting into 0.41. If these are available as patches to 0.41 itself, they're much easier for me to apply, but certain changes are so non-local (like the SSE speedups) that the only way to proceed is looking at any version that has the enhancement in question and deciding how to fit it nicely into 0.41. The devel branch seems to have filled two purposes simultaneously. I think a few people actually were using devel_0_39 in productions, but it also served as a testbed for things to merge into the head. There are fully THREE pathways proposed for introducing changes into Pd; the third is Pd_extended in which, if I understand it correctly, some patches are applied to Pd in order to resolve various compatibility problems with external libraries (e.g., scoping of symbols in dynamic linking?) which might, or might not, also be reflected in devel_0_39. Finally, 0.40 still isn't 64-bit safe; for that you'll need 0.41. This is a serious problem in some distributions of linux in which many libraries aren't available in 32-bit form in the 64-bit version of the OS. Just as a teaser, I tried running the same patch as 32-bit and 64-bit programs on my 64-bit machine, hoping to find the 32-bit version so much faster that I could just forget optimizing the 64 bit version entirely. But I found the 64-bit one 33% faster than the 32-bit one for the particular patch I tried. So 64-bit compatibility has to be taken seriously! cheers Miller On Sat, Jul 21, 2007 at 01:21:28PM -0400, Mathieu Bouchard wrote: Is devel_0_40 still planned? It's getting closer to one year since the last changes to devel_0_39 were applied, apart from mine. So, what happened exactly? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel_0_39 ? devel_0_40 ?
On 7/21/07, chris clepper [EMAIL PROTECTED] wrote: On 7/21/07, Miller Puckette [EMAIL PROTECTED] wrote: Just as a teaser, I tried running the same patch as 32-bit and 64-bit programs on my 64-bit machine, hoping to find the 32-bit version so much faster that I could just forget optimizing the 64 bit version entirely. But I found the 64-bit one 33% faster than the 32-bit one for the particular patch I tried. So 64-bit compatibility has to be taken seriously! If I had to hazard a guess that speedup is due to the compiler. The 64 bit CPUs are all quite recent and the assumptions about what the fast paths are a much smaller and generally much more efficient set than the 32 bit options. No doubt some of that comes from the gamesmanship involved in rigging and hyping scores on the baleful SPEC test suite. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
