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
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
On Sat, 21 Jul 2007, Miller Puckette wrote:
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
Before any talk on whether it's better to fork from your 0.40 or your 0.41... and regardless of inclusion of any devel_0_39 features into your 0.41... my only question is whether another devel_0_* is going to happen at all, or is it just called Vibrez nowadays.
Have you tried Vibrez yet?
I got the installer, but then it fails near the end, saying: Unable to execute file: c:\windows\system32\cmd.exe - CreateProcess failed; code 2. File not found.
There are fully THREE pathways proposed for introducing changes into Pd; the third is Pd_extended in which,
Sorry. One is devel_0_39, one is Pd_extended and... do you count yourself as being the other one or not?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Before any talk on whether it's better to fork from your 0.40 or your 0.41... and regardless of inclusion of any devel_0_39 features into your 0.41... my only question is whether another devel_0_* is going to happen at all, or is it just called Vibrez nowadays.
Have you tried Vibrez yet?
... don't know about it yet.
Sorry. One is devel_0_39, one is Pd_extended and... do you count yourself as being the other one or not?
The many proposed patches against 0.41, which I last scanned about 2 months ago, but which I believe now has more wstuff for me to try out :)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada
On Sat, 2007-07-21 at 16:09 -0700, Miller Puckette wrote:
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!
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
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Life is really simple, but we insist on making it complicated. Confucius
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
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Life is really simple, but we insist on making it complicated. Confucius
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 ...
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.
well, one should still tweak the sse unit by setting the daz/ftz flags ... see the code that is enabled by the preprocessor symbol DAZ in s_main.c of devel_0_39 ...
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Your mind will answer most questions if you learn to relax and wait for the answer. William S. Burroughs
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...
cheers M
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
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
I had nothing to offer anybody except my own confusion Jack Kerouac
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
Am 22.07.2007 um 01:09 schrieb Miller Puckette:
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
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
-
Mathieu Bouchard -
Miller Puckette -
Thomas Grill -
Tim Blechmann