Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Tue, Oct 4, 2011 at 11:38 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: the proper way is to use CPPFLAGS=-DPD_FLOAT_PRECISION=64, But now you undo the CPPFLAGS as defined in the makefile. I didn't know how to add to the CFLAGS from the command line, but found a solution here: http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_66.html#SEC65 It requires a small adaptation to the makefile. Instead of: CFLAGS = comes: override CFLAGS += . Now you can add to CFLAGS from the command line, like so: make CFLAGS=-DPD_FLOAT_PRECISION=64 Note that the CFLAGS in the makefile now have precedence and you can only add to it from the command line, not override it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 5, 2011, at 6:40 AM, katja wrote: On Tue, Oct 4, 2011 at 11:38 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: the proper way is to use CPPFLAGS=-DPD_FLOAT_PRECISION=64, But now you undo the CPPFLAGS as defined in the makefile. I didn't know how to add to the CFLAGS from the command line, but found a solution here: http://theory.uwinnipeg.ca/localfiles/infofiles/make/ make_66.html#SEC65 It requires a small adaptation to the makefile. Instead of: CFLAGS = comes: override CFLAGS += . Now you can add to CFLAGS from the command line, like so: make CFLAGS=-DPD_FLOAT_PRECISION=64 Note that the CFLAGS in the makefile now have precedence and you can only add to it from the command line, not override it. For the sake of this dev branch, I think we can have it automatically detect 32-bit vs. 64-bit platforms, and set accordingly. Does that work for people? .hc If you are not part of the solution, you are part of the problem. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 5, 2011, at 5:08 AM, katja wrote: On Wed, Oct 5, 2011 at 6:11 AM, Hans-Christoph Steiner h...@at.or.at wrote: So you are saying that the stuff in pd-double is not building using 64-bit floats? I downloaded Pd-0.43.1-double-20111003-macosx106-x86_64.dmg from the auto-build and this one was single precision. Don't know about the other builds. Maybe it's better, for the moment at least, to set logpost level 2 for the precision message at startup so you see it immediately. I used log level 3 in accordance with your intention to start Pd with a clean window, but in the testing phase this makes no sense indeed. Ok, makes sense. Let's get a github repo going so we can work on this stuff. Unless you want to, I'll happily set one up at: https://github.com/pd-projects/pd-double Yes please if you want to, go ahead. I'm slow with these things, by lack of experience. I even still have to learn git, and was comparing features of github vs gitorious. Both seem fine. Sorry, I'm excited and impatient to get this rolling :) As for learning git, it can be daunting at first, but it is really worth spending time learning it. I can recommend Pro Git, I read it on the subway. Its free online, or you can buy a copy: http://progit.org/book/ Here is the github repo and a wiki section for dev work. Just send me your github account name and I'll add it. https://github.com/pd-projects/pd-double http://puredata.info/dev/pd-double/ In the meantime I'll work on a clean up of rewritten code then, and based on pure-data.git instead of 0.43-0. I already applied the fixes, so its up to date in the git. If you want to try it for learning, I recommend trying to checkout version 0.43.0 in git, make a branch to work in, then apply your patches, then 'git rebase master' in your branch, and it'll do a lot of work for you. But that's not necessary now, just a good case for learning that feature of git. A much easier place to start would be to clone the above git repo, then change the loglevel to 2, then commit it, then 'git push origin master' to push your commits to the github. Thanks for the very supportive cooperation. Thanks for all this work, its the least we can do. I like to think that this is a supportive and cooperative group working on Pd, though we can be grumpy sometimes ;) so I am glad to hear you say that. .hc ¡El pueblo unido jamás será vencido! ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/2011 12:40 PM, katja wrote: On Tue, Oct 4, 2011 at 11:38 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: the proper way is to use CPPFLAGS=-DPD_FLOAT_PRECISION=64, But now you undo the CPPFLAGS as defined in the makefile. I didn't know how to add to the CFLAGS from the command line, but found a solution here: http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_66.html#SEC65 It requires a small adaptation to the makefile. Instead of: CFLAGS = comes: override CFLAGS += . Now you can add to CFLAGS from the command line, like so: make CFLAGS=-DPD_FLOAT_PRECISION=64 Note that the CFLAGS in the makefile now have precedence and you can only add to it from the command line, not override it. i don't get the point here, since CPPFLAGS is not set in the Pd Makefiles, so setting them to outside should have no weird sideeffects, whereas CFLAGS does. ah, on closer inspection it seems like you are building Pd with the old autoconf system (pd/src/configure.ac generates pd/src/makefile), whereas i am using (and talking about) the newer autotools based build system (pd/configure.ac generates pd/src/Makefile) afaik, this is the build-system used in the nightly builds (apart from w32) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MshUACgkQkX2Xpv6ydvQkHwCg5ld9exXjKmAsIHbbINmPJZkp kxIAn1bEYE/kKTVCsXM3D0zKLMqXr+So =UNU0 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Wed, 2011-10-05 at 21:37 +0200, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/2011 12:40 PM, katja wrote: On Tue, Oct 4, 2011 at 11:38 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: the proper way is to use CPPFLAGS=-DPD_FLOAT_PRECISION=64, But now you undo the CPPFLAGS as defined in the makefile. I didn't know how to add to the CFLAGS from the command line, but found a solution here: http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_66.html#SEC65 It requires a small adaptation to the makefile. Instead of: CFLAGS = comes: override CFLAGS += . Now you can add to CFLAGS from the command line, like so: make CFLAGS=-DPD_FLOAT_PRECISION=64 Note that the CFLAGS in the makefile now have precedence and you can only add to it from the command line, not override it. i don't get the point here, since CPPFLAGS is not set in the Pd Makefiles, so setting them to outside should have no weird sideeffects, whereas CFLAGS does. ah, on closer inspection it seems like you are building Pd with the old autoconf system (pd/src/configure.ac generates pd/src/makefile), whereas i am using (and talking about) the newer autotools based build system (pd/configure.ac generates pd/src/Makefile) afaik, this is the build-system used in the nightly builds (apart from w32) Yeah, the nightly builds look for pd/autogen.sh and if its found, use that. Windows/MinGW can build using that build system, but its not entirely working yet, so the nightly builds still use pd/src/makefile.mingw. I removed the old build system from pd-double.git and pushed the change. Hopefully that'll reduce confusion. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
2011/10/5 Hans-Christoph Steiner h...@at.or.at: I removed the old build system from pd-double.git and pushed the change. Hopefully that'll reduce confusion. Yeah I was using the old build system all the time because it was so easy to produce local builds by doing make without install. Never mind. Katja. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Tue, Oct 4, 2011 at 1:33 AM, Hans-Christoph Steiner h...@at.or.at wrote: And we have our first Pd-double build! http://autobuild.puredata.info/auto-build/2011-10-03/Pd-0.43.1-double-20111003 macosx106-x86_64.dmg Cool Hans! Can't wait to check it out (though I'll have to wait till I get home tonight). Yesterday I forgot to mention why it should definitely not be built with -O0 (unless for debug purposes): PD_BIGORSMALL is defined an inline function (like it was already suggested by IOhannes a while ago), but at -O0 nothing will be inlined. A benchmark howto would be useful indeed. By the way for my coreduo 1.83 GHZ I could compile for Debian with SSE by setting -march=prescott, this was the last 32bit adress space SSE enabled CPU. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Tue, Oct 4, 2011 at 9:06 AM, katja katjavet...@gmail.com wrote: By the way for my coreduo 1.83 GHZ I could compile for Debian with SSE by setting -march=prescott, this was the last 32bit adress space SSE enabled CPU. Sorry, correction again: of course coreduo is also 32bit address space but it is not in the list of possible arch definitions for gcc. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 4, 2011, at 5:38 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-04 09:06, katja wrote: Yesterday I forgot to mention why it should definitely not be built with -O0 (unless for debug purposes): PD_BIGORSMALL is defined an ah yes, this was indeed my fault. since i don't feel comfortable with editing m_pd.h to get a different build, i used CFLAGS=-DPD_FLOAT_PRECISION=64, which undid any optimization flags (which by default are -O6, which i find a bit overdone; and -g is not set at all...) the proper way is to use CPPFLAGS=-DPD_FLOAT_PRECISION=64, which results in: osc-delay-perftest with 400 instances: debian : 31% original : 29% single : 22% single(O0) : 64% single(O2) : 25% single(O2+loop) : 22% single(pentium3) : 24% single(pentium4) : 22% single(prescott) : 22% single(core2): 22% single(core2+sse): 22% double : 25% double(O0) : 86% double(O2) : 27% double(O2+loop) : 26% double(pentium3) : 25% double(pentium4) : 24% double(prescott) : 24% double(core2): 24% double(core2+sse): 25% osc-delay-perftest with 1200 instances: debian : 94% original : 81% single : 65% single(O2) : 72% single(O0) : ++% single(O2+loop) : 66% single(pentium3) : 70% single(pentium4) : 66% single(prescott) : 65% single(core2): 59% single(core2+sse): 64% double : 77% double(O0) : ++% double(O2) : 82% double(O2+loop) : 77% double(pentium3) : 79% double(pentium4) : 75% double(prescott) : 75% double(core2): 71% double(core2+sse): 75% which is more inline with katja's measurements. this is (again) on an i5 650 @ 3.2GHz running in 32bit mode optimization flags (as far as they can be reconstructed :-)) debian: -g -O2 (this is what is dictated by debian policy) original: -O6 -funroll-loops -fomit-frame-pointer (seems to be the default) single/double: -original (O0): -O0 (O2): -g -O2 (O2+loop): -g -O2 -funroll-loops -fomit-frame-pointer (prescott): -original + -march=prescott (core2): -original + -march=core2 (core2+sse): -original + -march=core2 -mfpmath=sse -msse2 so it seems like the biggest performance boost is given (on the tested platform), by compiling with -g -O2 -funroll-loops - -fomit-frame-pointer (which is cool because i think this can even make it into debian, the way it is) inline function (like it was already suggested by IOhannes a while ago), but at -O0 nothing will be inlined. A benchmark howto would be useful indeed. well, i usually just cram lots of the same object into a subpatch (until i get approximately 80% in the slowest environment, in order to not max out the CUP and get unknown side-effects), and measure it with the built-in load-meter (for loads 100% it behaves quite the same as top) nothing very dramatic. Nice tests, thanks for that. I would be interested to see the effects of auto-vectorization on these numbers. Have you tried that? If the test patch doesn't include objects that have loops vectorized, it won't make a difference. .hc If you are not part of the solution, you are part of the problem. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Mon, Oct 3, 2011 at 18:26, Hans-Christoph Steiner h...@at.or.at wrote: On Oct 3, 2011, at 12:04 PM, katja wrote: On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it. Yes definitely, we should let everyone who wants to be get involved. I am just saying with need a development platform to start with. Once that's nailed down, we can deal with more issues, like porting to libpd, dealing with externals that could be either 32-bit or 64-bit, etc. I setup a nightly build on the macosx106-x86_64 and called it pd-double. Andras and r33p, if you are listening, could you run this build on your 64-bit boxes also? All you need to do is: ~pd/auto-build cp -a pd-extended pd-double Listening now. I did: $ cd ~pd/auto-build $ sudo cp -a pd-extended pd-double What's next? Shall I try patching or rather pull IOhannes's sources? Andras ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 4, 2011, at 10:19 AM, András Murányi wrote: On Mon, Oct 3, 2011 at 18:26, Hans-Christoph Steiner h...@at.or.at wrote: On Oct 3, 2011, at 12:04 PM, katja wrote: On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it. Yes definitely, we should let everyone who wants to be get involved. I am just saying with need a development platform to start with. Once that's nailed down, we can deal with more issues, like porting to libpd, dealing with externals that could be either 32-bit or 64-bit, etc. I setup a nightly build on the macosx106-x86_64 and called it pd- double. Andras and r33p, if you are listening, could you run this build on your 64-bit boxes also? All you need to do is: ~pd/auto-build cp -a pd-extended pd-double Listening now. I did: $ cd ~pd/auto-build $ sudo cp -a pd-extended pd-double What's next? Shall I try patching or rather pull IOhannes's sources? If you have the run-automated-builder script in a cron job, that is all you have to do. .hc ¡El pueblo unido jamás será vencido! ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
2011/10/4 Hans-Christoph Steiner h...@at.or.at On Oct 4, 2011, at 10:19 AM, András Murányi wrote: On Mon, Oct 3, 2011 at 18:26, Hans-Christoph Steiner h...@at.or.atwrote: On Oct 3, 2011, at 12:04 PM, katja wrote: On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it. Yes definitely, we should let everyone who wants to be get involved. I am just saying with need a development platform to start with. Once that's nailed down, we can deal with more issues, like porting to libpd, dealing with externals that could be either 32-bit or 64-bit, etc. I setup a nightly build on the macosx106-x86_64 and called it pd-double. Andras and r33p, if you are listening, could you run this build on your 64-bit boxes also? All you need to do is: ~pd/auto-build cp -a pd-extended pd-double Listening now. I did: $ cd ~pd/auto-build $ sudo cp -a pd-extended pd-double What's next? Shall I try patching or rather pull IOhannes's sources? If you have the run-automated-builder script in a cron job, that is all you have to do. .hc Ah, so tomorrow a single and double precision build will automatically be made? Cool. Also, as I was busy with my life (buying a flat) these days, and I couldn't follow the list as precisely as I wished, could you advise me what's the current best way to roll my own double precision pd? Because I would like to benchmark a fully optimised one. Thanks, Andras ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 4, 2011, at 10:54 AM, András Murányi wrote: 2011/10/4 Hans-Christoph Steiner h...@at.or.at On Oct 4, 2011, at 10:19 AM, András Murányi wrote: On Mon, Oct 3, 2011 at 18:26, Hans-Christoph Steiner h...@at.or.at wrote: On Oct 3, 2011, at 12:04 PM, katja wrote: On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it. Yes definitely, we should let everyone who wants to be get involved. I am just saying with need a development platform to start with. Once that's nailed down, we can deal with more issues, like porting to libpd, dealing with externals that could be either 32-bit or 64-bit, etc. I setup a nightly build on the macosx106-x86_64 and called it pd- double. Andras and r33p, if you are listening, could you run this build on your 64-bit boxes also? All you need to do is: ~pd/auto-build cp -a pd-extended pd-double Listening now. I did: $ cd ~pd/auto-build $ sudo cp -a pd-extended pd-double What's next? Shall I try patching or rather pull IOhannes's sources? If you have the run-automated-builder script in a cron job, that is all you have to do. .hc Ah, so tomorrow a single and double precision build will automatically be made? Cool. Also, as I was busy with my life (buying a flat) these days, and I couldn't follow the list as precisely as I wished, could you advise me what's the current best way to roll my own double precision pd? Because I would like to benchmark a fully optimised one. That would great to have those numbers. I just committed some changes to set lots of optimization flags, since all of the build servers are using gcc 4.x now. So looking at this commit will show you the place to set the optimization flags: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=15495 'make clean' in the various packages/* folders should work, but I haven't throughly tested it, and use the rsync in the script to be sure. .hc Access to computers should be unlimited and total. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Hello, Happy to see so many test results from IOhannes. The 'perfotest' patches were initially created for function profiling, to check if there are particularly time consuming instructions. To mention a funny example: I was happy to see that fabs() was translated to a single instruction ANDPS / ANDPD for xmm registers. But for the FPU it is a call. The same for isnan(). That's why PD_BIGORSMALL must still do a bitpattern check on aliased floats. For benchmarking original and double-ready Pd as a whole, I used two (fairly cool and elaborate) patches which were written in pure vanilla: - Chaosmonster1 from www.martin-brinkmann.de (10 instances or so) - Cave of Creation by Hamster, http://puredata.hurleur.com/sujet-5080-2.html Both works feature enough of the rewritten code to make them representative overall benchmarks. If double-ready Pd performs as well as original Pd with usual compiler settings, on all possible platforms, I would be satisfied. After all, the purpose of the whole thing was to get some more decimal places in our numbers, not to make Pd run faster. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Forgot to mention this: at start up there's a logpost (level 3) 'PD_FLOATPRECISION=32 bits' for single and 'PD_FLOATPRECISION=64 bits' for double build. Ah, so tomorrow a single and double precision build will automatically be made? Cool. It's confusing. At the moment there is vanilla Pd patched to work in double precision. But for Pd-extended it is: a single precision Pd-extended with double-ready core code. Not a double precision Pd-extended, not even double-ready Pd-extended. Let's better call it something like Pd-0.43.1-single-20111004-macosx106-x86_64.dmg etc., Hans? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 4, 2011, at 7:06 PM, katja wrote: Forgot to mention this: at start up there's a logpost (level 3) 'PD_FLOATPRECISION=32 bits' for single and 'PD_FLOATPRECISION=64 bits' for double build. Ah, so tomorrow a single and double precision build will automatically be made? Cool. It's confusing. At the moment there is vanilla Pd patched to work in double precision. But for Pd-extended it is: a single precision Pd-extended with double-ready core code. Not a double precision Pd-extended, not even double-ready Pd-extended. Let's better call it something like Pd-0.43.1-single-20111004-macosx106-x86_64.dmg etc., Hans? Its a dev branch to test the double stuff, so its going to be messy, unless someone wants to clean up the scripts. Pd-extended is still using 32-bit floats for t_float and t_symbol. The pd-double build will have some vestiges of the 'extended' name in it, because the build scripts are crufty and kludgey and should be replaced. But they work. So you are saying that the stuff in pd-double is not building using 64- bit floats? Let's get a github repo going so we can work on this stuff. Unless you want to, I'll happily set one up at: https://github.com/pd-projects/pd-double And add people who are interested in working on it. Or do you want to maintain your own git repo that we submit patches to? .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 3, 2011, at 8:28 AM, katja wrote: On Sun, Oct 2, 2011 at 11:36 PM, Hans-Christoph Steiner h...@at.or.at wrote: I think it makes sense to work off of pure-data.git rather than pd-extended.git since this is a patch targetted at getting into Miller's repo. Right. Even then, we could add some external libs to work on, starting with zexy and cyclone for example. The question is how to load appropriate executables into local single and double precision test builds of vanilla Pd. A single preference file is shared by all vanilla Pd installations, therefore setting searchpaths via preferences is no option. Each Pd should only load from it's own 'extra' directory. With the extra's included in vanilla Pd, this works fine as far as I have seen. I tested bonk~ in single and double precision Pd simultaneously without symbol collision. I think we can pretty rapidly get a double-precision Pd-extended nightly build working, its just that a lot of external objects will be crashy since they use float rather than t_float. I just checked a couple, and they look good in terms of using t_float appropriately. As for arch issues, I think Intel and ARM are the big ones to test these days. But PPC is fine too. Expressed in number of 'users', ARM is probably the most popular target hardware for Pd at the moment. It should be easy to patch libpd with the same .patch files, or not? Some modified files are inexistent in libpd (s_audio_pa.c, vexpr.c etc). It's important to at least benchmark-test rewritten code on this hardware indeed, if we want to make a unified doube-precision-ready Pd happen. In terms of development, let's stick with one codebase. I'll make our jobs easier. Its also easy to compile pure-data.git for ARM, and indeed the 'puredata' package is included in Debian/ARM. Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. .hc Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 16:31, Hans-Christoph Steiner wrote: These all sound like good ideas to try. My only concern is that we might let the deployment issues distract from the issues at hand about getting it actually working first. i'm definitely with you here. what is still missing in terms of getting it actually working first? afaict, katja's patches do make pd itself double-precision ready (the patches might have to be reviewed as far as coding-style is concerned though) otoh, i wouldn't start porting externals before we have a deployment strategy. one important thing missing right now, is how to compile Pd in a given precision without having to edit m_pd.h technically i think that the define stuff and the like should go into a separate file types.h (probably m_types.h) which is generated from m_types.h.in during configure time, and which is included by m_pd.h (which should remain non-generated) the question is, what miller would think of such a thing. In terms of packaging, I can see having 64-bit distros run double-precision Pd for all packages, and 32-bit distros run single precision. That should cover the bulk of situations, the other situations can be covered by custom builds. Having all the 64-bit packages use double-precision Pd is of course going to happen after a while, once we have the bugs worked out. Here I can see an advantage of the monolithic Pd-extended package: its an easy, self-contained test bed. definitely, the traditional Pd-extended will have an easier time here. nevertheless, the advent of ~/pd-externals for the user has made things significantly more complicated in terms of just works. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6J0n4ACgkQkX2Xpv6ydvQMzgCgkdnTzhJhn9XC+7zXP5VZBjss QEQAoPEt0kvhxm9LPW+biXH1gXSd1+mX =sWcN -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Thanks IOhannes for all your comments and suggestions. I just realized that there are several ways in which identical symbols for different function definitions could cause a problem and I did not distinguish them. 1. Pd looks for a setup symbol when trying to load an external binary. 2. A loaded external calls an exported function in Pd. 3. Pd calls an exported function in Pd Case 2. and 3. can only lead to symbol collision when a single precision and double precision Pd are running simultaneously. So far, I have not seen symbol collision happen though I've often ran them simultaneously. I understand that theoretically it's not guaranteed that it won't happen, that's also the reason why it is generally recommended to only export truly global symbols. However I think it is not really a concern, as there is normally no reason to run single and double precision Pd together, apart from testing purposes. For case 1., protection is needed indeed. As IOhannes' list of possible approaches indicates, it's not a trivial intervention. I've also been thinking of a mechanism where Pd 'probes' a class at load time in order to find it's float type before instantiating any object. Rather it creates a private test instance for that purpose and tries to solicit output and check the size. To program this is not trivial either, if possible at all, but the advantage would be that it does not have consequence for class code. Actually I think we have time to find and implement a solution because during the double precision development and test period we do not depend on it. If only we find a good way to point different Pd installations to subdirs in their own 'extra' for loading externals. What I meant to say in my previous mail is, that external executables like bonk~ are found from the proper location because Pd apparently knows they are in it's own extra dir, wherever the installation may be located. I do not know where this path is set but we need an option to add more dirs to that local path without using preferences. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 17:44, katja wrote: Thanks IOhannes for all your comments and suggestions. I just realized that there are several ways in which identical symbols for different function definitions could cause a problem and I did not distinguish them. 1. Pd looks for a setup symbol when trying to load an external binary. 2. A loaded external calls an exported function in Pd. 3. Pd calls an exported function in Pd Case 2. and 3. can only lead to symbol collision when a single precision and double precision Pd are running simultaneously. So far, how is that going to happen? by running simultaneously, do you mean something like this? $ pd32 $ pd64 i think all modern OSs will protect the memory (including loaded libraries) of an application from other applications. e.g. if i happen to have a library with an exported symbol sqrt which viciously returns the (x+1) rather than sqrt(x), and i start an application that links to this library (thus making use of the bad sqrt()), this will not magically make Excel forget it's math. the problem might obivously appear, if Pd would actually create a libpd.so providing all the exported functions, and pd32 / pd64 would make heavy use of those. in which case, pd32 might get a double-precision libpd.so, and thus be not single precision any more. but this is really not a problem of running the single and double precision on the same machine, but installing them on the same machine. For case 1., protection is needed indeed. As IOhannes' list of possible approaches indicates, it's not a trivial intervention. I've also been thinking of a mechanism where Pd 'probes' a class at load time in order to find it's float type before instantiating any object. Rather it creates a private test instance for that purpose and tries to solicit output and check the size. To program this is not trivial either, if possible at all, but the advantage would be that it does not have consequence for class code. i cannot really think of a way to do that. if we only consider signals, we could do some tests (as the object has a well defined interface to acquire and output numbers), though i fail to see how we could validate these tests, without knowing what the object is actually supposed to do. if we consider message objects as well, i don't even know how to properly send a message that might reveal something useful. knows they are in it's own extra dir, wherever the installation may be located. I do not know where this path is set but we need an option to add more dirs to that local path without using preferences. i don't see how this would help. whether those paths can be modified via preferences or only via startup flags, doesn't really matter. if we want them to not be editable at all, i don't see the point in adding them. people do use the preferences to add paths to find their libraries. if those paths contain libraries expecting the wrong precision we have a problem. fmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6J3RQACgkQkX2Xpv6ydvSxlgCfSWr1xxFrd/VQ/13lgARF88EL Qk0An22WlbXva6O/Q3YWasMn/57M+XK6 =OVlg -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 18:00, Charles Henry wrote: Would you prefer to set the types at configure time through a file--or for example by adding a -DDOUBLE compiler flag? The affected locations of code defining the types could just use #ifdef DOUBLE no, not at all. In either case, the configure option seems necessary. It still seems an open question how best to offer the double-precision types to externals developers. yes, of course this is the point. if the external includes (the correct) m_pd.h, it should get the correct precision for free. right now, the default is to use 32bit. if you set the PD_FLOAT_PRECISION macro to 64 (e.g. by adding -DPD_FLOAT_PRECISION=64 to the preprocessor-flags or by modifying m_pd.h), you will get a double precision build. if you set CPPFLAGS, no external will be able to track the current precision. if you modify m_pd.h, then you are modifying upstream sources, which makes it complicated for distribution. In some cases, the setup() function allocates memory, which needs to be aware of the data type size. well, just use t_float or t-sample (as appropriate) with the correctly defined PD_FLOAT_PRECISION. i'm really only talking about how to make sure that PD_FLOAT_PRECISION is defined to the right value. Adding additional methods seems unnecessary--unless specific performance problems can be avoided. it's only about guaranteeing consistency between the host (pd) and the client (the external). i don't see so many alternatives, but probably you know some clever trick. I don't anticipate any problems with running 64-bit Pd on a 32-bit i'd suggest to use double precision Pd (i know it's longer to type) if you refer to 64bit data types, and 64bit Pd if you refer to address size. system, in principle, just as long as the correct data types are set for pointers (same size as t_int) and signals (size of t_sample) differently. that's the problem i'm trying to solve. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6J32oACgkQkX2Xpv6ydvR0UQCg9+ZNB6M3uLNucL2DfQ0B3RoU qN8AoLRJj7sfglMBwsyXDAXnln/x937X =/L5s -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
I think for now, we'll just have Pd-extended-like monolithic builds which will be easy to use on their own and will include enough libraries to be useful. They can be run standalone, and if need be, we can disable things like ~/pd-externals quite easily. These kinds of deployment issues really need a lot of real world data to be correctly solved, so I think its not worth going to deep into it until we get some builds out there for people to use. .hc On Oct 3, 2011, at 11:44 AM, katja wrote: Thanks IOhannes for all your comments and suggestions. I just realized that there are several ways in which identical symbols for different function definitions could cause a problem and I did not distinguish them. 1. Pd looks for a setup symbol when trying to load an external binary. 2. A loaded external calls an exported function in Pd. 3. Pd calls an exported function in Pd Case 2. and 3. can only lead to symbol collision when a single precision and double precision Pd are running simultaneously. So far, I have not seen symbol collision happen though I've often ran them simultaneously. I understand that theoretically it's not guaranteed that it won't happen, that's also the reason why it is generally recommended to only export truly global symbols. However I think it is not really a concern, as there is normally no reason to run single and double precision Pd together, apart from testing purposes. For case 1., protection is needed indeed. As IOhannes' list of possible approaches indicates, it's not a trivial intervention. I've also been thinking of a mechanism where Pd 'probes' a class at load time in order to find it's float type before instantiating any object. Rather it creates a private test instance for that purpose and tries to solicit output and check the size. To program this is not trivial either, if possible at all, but the advantage would be that it does not have consequence for class code. Actually I think we have time to find and implement a solution because during the double precision development and test period we do not depend on it. If only we find a good way to point different Pd installations to subdirs in their own 'extra' for loading externals. What I meant to say in my previous mail is, that external executables like bonk~ are found from the proper location because Pd apparently knows they are in it's own extra dir, wherever the installation may be located. I do not know where this path is set but we need an option to add more dirs to that local path without using preferences. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev kill your television ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 3, 2011, at 12:00 PM, Charles Henry wrote: On Mon, Oct 3, 2011 at 10:19 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 16:31, Hans-Christoph Steiner wrote: These all sound like good ideas to try. My only concern is that we might let the deployment issues distract from the issues at hand about getting it actually working first. i'm definitely with you here. what is still missing in terms of getting it actually working first? afaict, katja's patches do make pd itself double-precision ready (the patches might have to be reviewed as far as coding-style is concerned though) otoh, i wouldn't start porting externals before we have a deployment strategy. one important thing missing right now, is how to compile Pd in a given precision without having to edit m_pd.h technically i think that the define stuff and the like should go into a separate file types.h (probably m_types.h) which is generated from m_types.h.in during configure time, and which is included by m_pd.h (which should remain non-generated) the question is, what miller would think of such a thing. Would you prefer to set the types at configure time through a file--or for example by adding a -DDOUBLE compiler flag? The affected locations of code defining the types could just use #ifdef DOUBLE In either case, the configure option seems necessary. It still seems an open question how best to offer the double-precision types to externals developers. In some cases, the setup() function allocates memory, which needs to be aware of the data type size. Otherwise, memory for signals is allocated through Pd's DSP graph generation routines, so that only changes to externals is to compile perform routines with the given data type. Adding additional methods seems unnecessary--unless specific performance problems can be avoided. Wouldn't setting t_sample, t_float, and t_int to 64-bit or 32-bit in m_pd.h combined with sizeof() be enough for this? .hc In terms of packaging, I can see having 64-bit distros run double-precision Pd for all packages, and 32-bit distros run single precision. That should cover the bulk of situations, the other situations can be covered by custom builds. Having all the 64-bit packages use double-precision Pd is of course going to happen after a while, once we have the bugs worked out. Here I can see an advantage of the monolithic Pd-extended package: its an easy, self-contained test bed. definitely, the traditional Pd-extended will have an easier time here. nevertheless, the advent of ~/pd-externals for the user has made things significantly more complicated in terms of just works. fgmasdr IOhannes I don't anticipate any problems with running 64-bit Pd on a 32-bit system, in principle, just as long as the correct data types are set for pointers (same size as t_int) and signals (size of t_sample) differently. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev A cellphone to me is just an opportunity to be irritated wherever you are. - Linus Torvalds ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 18:04, katja wrote: On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. apropos performance: on my i5 650 @ 3.2GHz, running debian and trying to osc-delay-perfotest.pd (with only 400 osc-delay abstractions, as 500 would max out the CPU in new double mode) i get: original : 28% debian: 31% new single: 64% new double: 86% the new versions are Pd-0.43.1-test4 with only the PD_FLOAT_PRECISION set to 32 resp. 64. the original version is a 0.43.1-test2, where i cannot recall any special optimization flags. the debian version is a 0.43.0 with most optimization turned OFF (as is debian policy) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6J4SQACgkQkX2Xpv6ydvR+hgCgwWuetmj86YFr7iXsHkIZolVc b5YAoPA4DJnkKb6Gtu5YnbMheDSkUvwy =js8N -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Oct 3, 2011, at 12:04 PM, katja wrote: On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it. Yes definitely, we should let everyone who wants to be get involved. I am just saying with need a development platform to start with. Once that's nailed down, we can deal with more issues, like porting to libpd, dealing with externals that could be either 32-bit or 64-bit, etc. I setup a nightly build on the macosx106-x86_64 and called it pd- double. Andras and r33p, if you are listening, could you run this build on your 64-bit boxes also? All you need to do is: ~pd/auto-build cp -a pd-extended pd-double .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
More on actually trying the patch. I tried to apply it to the HEAD of pure-data.git, and one section failed: pd@debian-lenny-i386 src $ patch -p1 ../../pd_doubleready/ make_Pd_core_0430_double_ready.patch patching file d_array.c patching file d_math.c patching file d_misc.c Hunk #2 FAILED at 37. 1 out of 2 hunks FAILED -- saving rejects to file d_misc.c.rej The patch to 'extra' succeeded. .hc On Oct 3, 2011, at 11:44 AM, katja wrote: Thanks IOhannes for all your comments and suggestions. I just realized that there are several ways in which identical symbols for different function definitions could cause a problem and I did not distinguish them. 1. Pd looks for a setup symbol when trying to load an external binary. 2. A loaded external calls an exported function in Pd. 3. Pd calls an exported function in Pd Case 2. and 3. can only lead to symbol collision when a single precision and double precision Pd are running simultaneously. So far, I have not seen symbol collision happen though I've often ran them simultaneously. I understand that theoretically it's not guaranteed that it won't happen, that's also the reason why it is generally recommended to only export truly global symbols. However I think it is not really a concern, as there is normally no reason to run single and double precision Pd together, apart from testing purposes. For case 1., protection is needed indeed. As IOhannes' list of possible approaches indicates, it's not a trivial intervention. I've also been thinking of a mechanism where Pd 'probes' a class at load time in order to find it's float type before instantiating any object. Rather it creates a private test instance for that purpose and tries to solicit output and check the size. To program this is not trivial either, if possible at all, but the advantage would be that it does not have consequence for class code. Actually I think we have time to find and implement a solution because during the double precision development and test period we do not depend on it. If only we find a good way to point different Pd installations to subdirs in their own 'extra' for loading externals. What I meant to say in my previous mail is, that external executables like bonk~ are found from the proper location because Pd apparently knows they are in it's own extra dir, wherever the installation may be located. I do not know where this path is set but we need an option to add more dirs to that local path without using preferences. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 18:32, Hans-Christoph Steiner wrote: More on actually trying the patch. I tried to apply it to the HEAD of pure-data.git, and one section failed: pd@debian-lenny-i386 src $ patch -p1 ../../pd_doubleready/make_Pd_core_0430_double_ready.patch patching file d_array.c patching file d_math.c patching file d_misc.c Hunk #2 FAILED at 37. 1 out of 2 hunks FAILED -- saving rejects to file d_misc.c.rej this one is quite easy to fix if you inspect the patch manually. anyhow, i patched the sources and pushed them to my github repository, into the double branch. https://github.com/umlaeute/pd-vanilla/tree/double fgmsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6J5LcACgkQkX2Xpv6ydvSTwACgrCNNwp00bIw+yDtTGnfTwEn7 kq4AoJkqTYQYtrDnMokeqhCOylexjLgV =MMS0 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Mon, Oct 3, 2011 at 6:21 PM, IOhannes m zmoelnig zmoel...@iem.at wrote: apropos performance: on my i5 650 @ 3.2GHz, running debian and trying to osc-delay-perfotest.pd (with only 400 osc-delay abstractions, as 500 would max out the CPU in new double mode) i get: original : 28% debian : 31% new single: 64% new double: 86% Did you build new single / new double without any optimization? Makefile.am/in for Pd-0.43.1-test4 do not specify optimization. I compared using -O2 for all builds, like it is set for Pd-0.43-0. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Mon, Oct 3, 2011 at 7:08 PM, katja katjavet...@gmail.com wrote: On Mon, Oct 3, 2011 at 6:21 PM, IOhannes m zmoelnig zmoel...@iem.at wrote: apropos performance: on my i5 650 @ 3.2GHz, running debian and trying to osc-delay-perfotest.pd (with only 400 osc-delay abstractions, as 500 would max out the CPU in new double mode) i get: original : 28% debian : 31% new single: 64% new double: 86% Did you build new single / new double without any optimization? Makefile.am/in for Pd-0.43.1-test4 do not specify optimization. I compared using -O2 for all builds, like it is set for Pd-0.43-0. Katja Update: The rewritten code is more sensitive to optimization than the original. On coreduo 1.83 GHz with Debian I could only run 200 osc-delay abstractions in osc-delay-perfotest.pd under worst conditions. Compare these values from command top: original: 69% with -O0, 47% with -O2 (no SSE) new-single: 83% with -O0, 48% with -O2 (no SSE) new-double: 97% with -O0, 59% with -O2 (no SSE) On MacBook core2duo 2GHz where I wrote and optimized most, 500 osc-delay abstractions can easily run in osc-delay-perfotest.pd, with these values from top: original: 60% with -O3 and SSE new-single: 50% with -O3 and SSE new-double: 54% with -O3 and SSE I knew on beforehand that the code would get tuned (performance-wise) to hardware, instruction set, OS, compiler, compiler options etc. used for development, but it never crossed my mind to check performance with optimization level -O0. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Hi Hans, Thanks for your detailed comments. I will go through the code once again, you're right it's not as clean as could be. Regarding your suggestion to set up a repo, it seems to be the most logical thing to do. This could be considered a temporary branch for the double precision thing, to be discontinued once all the code works fine for single and double precision alike and merged into Pd. I'll start that up one of these days (my first repo ever, hope to get it done...). A few words on the scope of tests done so far. Rewritten code was developed and tested on Intel core CPU's, where it seems to work smooth, both with SSE and FPU instructions. Regarding functionality and robustness, I have good confidence that it will work anywhere, as it's simple and depends only on standard libs. But considering performance, more checking is needed. The rewritten phase-wrapping classes have branches in the perform-loops. These are only executed in rare cases, therefore branch prediction mechanisms can do their good work. But on older architectures branching may be more expensive. That was also the reason for Miller's branchless design of these classes, of course. PPC in particular should be considered, as there are still quite a few users. Maybe the code needs some finetuning to PPC. Only after settling this aspect, I would consider submitting the double-precision-ready .patch file for Pd's core code. Otherwise I'd risk an endless series of amendements on a submitted patch. In the meantime, double precision ready code would be available from this git repo we're planning. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Sounds great. I'm happy to help setup a git repo if you want me too. github and gitorious are pretty straightforward to get the initial repo, then it would be a matter of pushing the pure-data.git to that repo, and starting work from there. I think it makes sense to work off of pure-data.git rather than pd-extended.git since this is a patch targetted at getting into Miller's repo. As for arch issues, I think Intel and ARM are the big ones to test these days. But PPC is fine too. .hc On Oct 2, 2011, at 5:24 PM, katja wrote: Hi Hans, Thanks for your detailed comments. I will go through the code once again, you're right it's not as clean as could be. Regarding your suggestion to set up a repo, it seems to be the most logical thing to do. This could be considered a temporary branch for the double precision thing, to be discontinued once all the code works fine for single and double precision alike and merged into Pd. I'll start that up one of these days (my first repo ever, hope to get it done...). A few words on the scope of tests done so far. Rewritten code was developed and tested on Intel core CPU's, where it seems to work smooth, both with SSE and FPU instructions. Regarding functionality and robustness, I have good confidence that it will work anywhere, as it's simple and depends only on standard libs. But considering performance, more checking is needed. The rewritten phase-wrapping classes have branches in the perform-loops. These are only executed in rare cases, therefore branch prediction mechanisms can do their good work. But on older architectures branching may be more expensive. That was also the reason for Miller's branchless design of these classes, of course. PPC in particular should be considered, as there are still quite a few users. Maybe the code needs some finetuning to PPC. Only after settling this aspect, I would consider submitting the double-precision-ready .patch file for Pd's core code. Otherwise I'd risk an endless series of amendements on a submitted patch. In the meantime, double precision ready code would be available from this git repo we're planning. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Hey Katja,
This is great, just starting to dig into it. Its a great write-up too.
I'd like to put together some Pd-extended nightly builds based on this,
and start working out a work flow for all the fixes that we will
inevitably need to do. To start with, I think you should request SVN
commit access so you can directly commit fixes to externals as we find
them. I know there will be loads of changing float to t_float and
things like that, and I imagine a few places that'll need more work.
https://puredata.info/docs/developer/SVNCommitAccess
Then next, I think it makes sense to start a git fork to work on this.
github.com is a pretty easy place to put it, or gitorious.org. Then I
can setup a nightly build based on that repo.
I just looking thru your patches, a couple of quick comments to make the
patches a lot more readable. Basically, before submitting, read the
output of 'git diff' and try to make it so that the only changes that
appear are ones that change the function of the code, not how the code
looks. That makes for a shorter and much more readable patch.
* keep the indentation the same, in a few places in the patch, it seems
that the only difference is the indentation. It should be all spaces,
no tabs, with 4 spaces as a single level of indentation.
* try to eliminate spacing changes like:
-
-#ifndef N32
+#ifndef N32
t_float qsqrt(t_float f) {return (q8_sqrt(f)); }
t_float qrsqrt(t_float f) {return (q8_rsqrt(f)); }
#endif
-
-
typedef struct sigrsqrt
* keep variable names the same, when it makes sense, for example:
-x-x_arrayname = s;
+x-arrayname = s;
-float x_f; /* scalar frequency */
+t_float f; // scalar frequency
* it seems you define this union a lot in d_math.c, why not just once at
the top?
+union
+{
+float f;
+int32_t l;
+}u;
* same with GOODINT, perhaps that should just be defined once in a
header?
* also, I think the %g printf pattern should handle the number of
decimals, so perhaps in print_float it should just be %g or %lg.
.hc
On Sat, 2011-10-01 at 03:12 +0200, katja wrote:
Hello,
Finally my double-precision-Pd efforts resulted in code decent enough
to be useful in practice. It's all documented on:
http://www.katjaas.nl/doubleprecision/doubleprecision.html
From there you can download a .zip with two .patch files to make
vanilla Pd 0.43-0 double precision ready. In fact what you have is
'arbitrary-precision' code which can be built for single or double
precision with the setting of a single definition in the API header
m_pd.h. Test patches are included.
So far, I have tested on OSX and Linux. Remarkably, double precision
Pd performance is comparable to current Pd on the Intel CPU's. The
only drawback that I can think of is, it eats memory. This would be a
bummer for Pd users doing Ableton style stuff with lots of soundfiles
to be loaded into RAM. Krzysztof Czaja already warned me for this at
Pd Con, but at the time I forgot a bit about the problems with loading
soundfiles during a live session.
For me, as a precision freak, it is a delight to work with double
precision Pd. Some examples are illustrated on mentioned webpage.
Unfortunately, my music stuff needs Pd extended. I would be happy to
continue the project.
Katja
___
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
