On Fri, 2014-07-25 at 16:47 +0100, Fraser Adams wrote: > > On 25/07/14 15:30, Alan Conway wrote: > > On Thu, 2014-07-24 at 17:31 +0100, Fraser Adams wrote: > >> On 24/07/14 13:59, Alan Conway wrote: > >>> Very important point I forgot to mention: are you doing a release > >>> build? > >>> > >>> cmake -DCMAKE_BUILD_TYPE=Release > >>> > >>> That makes a big difference. It enables optimization flags for the C++ > >>> compiler. The default is not optimized. > >>> > >> Alan, > >> I've mentioned this before, but I remain unconvinced that the default > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> should be for an unoptimised build. I totally realise that seems to be > >> "the CMake way", but it always used to be the case under automake that > >> the default was something reasonably optimised. > >> > >> If it turns out that your suggestion is indeed the cause of the > >> discrepancy I think that would back up the view that *at the very least* > >> the documentation for doing the build should mention this and if there > >> is still a general view to default to the unoptimised I actually think > >> that the CMake for qpid and proton should display a warning to remind > >> users that they are using an unoptimised build. > > I agree (not sure why I didn't before, probably not paying attention.) > > The default actually isn't any of the advertised build types (Debug, > > Release etc.) it's a "just ignore opt/debug flags" build which is not > > especially useful for anything. I never use it. > > > > So I vote for making the default build type Release. Someone who finds > > performance sucks is more likely to leave without asking questions than > > someone who has trouble with their debugger (and since the default > > doesn't set -g anyway that doesn't appear to be a problem.) > > > > Any counter opinions? (as always, I assume silence is consent :) > > > > Cheers, > > Alan. > > > > > Thanks for this discussion Alan! > > My vote would be to default to the most optimised/operational-quality > build possible. My reasoning being that I suspect that *most* people (if > not all) coming in fresh would have a not unreasonable expectation that > qpid would "just work" and moreover would "just work" at its best. Your > "leave without asking questions" point is something that as a community > I believe that we must have high on our list of things to avoid! > > If the RelWithDebInfo is exactly as fast then that's probably OK, but if > I'm honest I believe that the default should really be to build > something that a user might want to ship in an operational > mission-critical system and I'm not personally keen on the idea of > shipping with debug symbols or anything else that could potentially > increase an attack vector. > > I'm more than happy that we supply documentation that tells users how to > enable debugging etc. but all of that is really developer focussed IMHO > and I think that the default should be first and foremost user focussed.
I'm inclined to agree that the default should be user focused rather than developer focused. On the gcc/intel/RHEL6 system I benchmarked Release is slightly better but not much. However I can't say if that's the case for other compiler/OS/hardware combinations. Assuming its implemented correctly one would assume that Release is going to be the most release-worthy in general if there is a tradeoff to be made. Any further thoughts from the RelWithDebInfo fans? Cheers, Alan. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
