Strip will have only a minor impact on speed, and only because there will be less swapping since the binaries will be smaller. Strip has no effect on the compiled machine code, only on debugging information and symbol tables.

The difference between -02 and -03 is relatively small. Building with debugging on plus -O2, then stripping for release is almost standard practice on Linux and Unix. This is what I recommend. You could also build for -03 with debugging on, I think, but it might be harder to debug and some -03 features might not work.

Regards,
Mike

-----Original Message-----
From: Steven Yi 
Sent: Jul 27, 2005 2:33 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Build Types

Hi Michael, 

Thanks for the information regarding strip.  If I understand correctly
though, using strip will improve speed but not as much as recompilning
with debugOff and optimizations set to O3?

steven

On 7/27/05, Michael Gogins  wrote:
> On Linux or Unix:
> 
> strip csound
> strip CsoundVST
> strip [name your utility]
> strip *.so
> 
> On MinGW/MSys/Windows it's easier since all files have suffixes:
> 
> strip *.exe
> strip *.dll
> 
> I had forgotten that not all utilities work compiled as doubles. That is a problem. So they should all be got to work with doubles...
> 
> Best,
> Mike
> 
> -----Original Message-----
> From: Steven Yi 
> Sent: Jul 27, 2005 2:47 AM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Build Types
> 
> Well, for me, I occassionally like to have a debug build around for
> profiling and when I do that now, I have to run a clean and whole new
> build.  Either that, or maintain a second CVS checkout directory that
> only has debug builds, which is tedious I think.
> 
> As for the float/double issue, there's more to it than just quality of
> sound.  Having access to both 32 and 64 makes the most sense to me so
> that you can run 32 while working for speed and 64 for final work.
> Also, as far I remember, not all the utilities work for 64, and you
> definitely can't mix and match analysis files between 32 and 64.  If
> user's don't have access to the source for their analysis but still
> want to use the analysis file, not much to do but use the version they
> originally used.  I'd really like to be able to compile all four
> versions (Debug and Release for 32 and 64) and have them available
> without having to maintain 4 cvs checkout directories locally.
> 
> As for stripping the debug builds, how is that done?
> 
> steven
> 
> 
> On 7/26/05, Michael Gogins  wrote:
> > I have mixed feelings about your proposal.
> >
> > One the one hand, I see no need for a float build, or for a release build. I've proved with double-blind tests that the double versions sounds different from the float version, and since double is more precise, that means double is musically superior to float. This is not an opinion, it is a fact.
> >
> > And I've had no problem simply stripping the existing optimized debug build for release.
> >
> > So, monkeying with the build system seems like a waste of time compared to contributing something new or improving the code.
> >
> > On the other hand, I know other people feel differently, that some people want the extra speed of float, and I also think that the existing SConstruct is a maze that could be much improved. It would be nice if it were a lot simpler.
> >
> > So go ahead, have fun, but if there are lots of changes and CsoundVST and other targets I have added don't build any more, I'll be very strongly tempted to roll back the changes.
> >
> > Best regards,
> > Mike
> >
> > -----Original Message-----
> > From: Steven Yi 
> > Sent: Jul 26, 2005 5:00 PM
> > To: csound-devel@lists.sourceforge.net
> > Subject: [Cs-dev] Build Types
> >
> > Hi All,
> >
> > I was thinking today that the SConstruct file should be redone to
> > allow for targets to build csound single or double as well as debug
> > and release targets, so four targets total.  I would like to have them
> > set to be built in different directories so that their object files
> > don't mix and you could build any or all four without having to clean
> > any of them.  Does this sound fine?
> >
> > steven
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The gcc3opt flag also turns on -fomit-frame-pointer, -ffast-math, and -march with
the specified CPU type, in addition to -O3. -fomit-frame-pointer, while results
in some speed-up, makes debugging impossible.
On the other hand, for reliable debugging, I found that something like -g -gstabs
-O0 (that is, disabling optimizations completely) works best. gdb often behaves
in strange ways when debugging optimized binaries.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net