Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On Wed, 2014-07-30 at 18:13 +0100, Fraser Adams wrote: > On 30/07/14 09:59, Gordon Sim wrote: > > On 07/29/2014 09:00 PM, Alan Conway wrote: > >> Done > >> > >> > >> r1614472 | aconway | 2014-07-29 15:59:19 -0400 (Tue, 29 Jul 2014) | 2 > >> lines > >> > >> QPID-5941: Set sensible default build type: default is RelWithDebInfo. > >> > >> > > > > Thanks Alan! > > > > > +1 > And thanks for starting the debate, I think this will be a big > improvement to most users' first experiences of qpid and hopefully > minimise the risk of users assuming that it's not fast enough. > > Can I ask if this improvement has been carried through to Proton too? If > not I think that this is important too as clearly it is required for > AMQP 1.0 support, so a non-optimised Proton in an optimised > qpidd/qpid::messaging would be less than ideal and possibly lead to even > more confused users. > > Frase > Good point, dispatch too for consistency. Will do. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On 30/07/14 09:59, Gordon Sim wrote: On 07/29/2014 09:00 PM, Alan Conway wrote: Done r1614472 | aconway | 2014-07-29 15:59:19 -0400 (Tue, 29 Jul 2014) | 2 lines QPID-5941: Set sensible default build type: default is RelWithDebInfo. Thanks Alan! +1 And thanks for starting the debate, I think this will be a big improvement to most users' first experiences of qpid and hopefully minimise the risk of users assuming that it's not fast enough. Can I ask if this improvement has been carried through to Proton too? If not I think that this is important too as clearly it is required for AMQP 1.0 support, so a non-optimised Proton in an optimised qpidd/qpid::messaging would be less than ideal and possibly lead to even more confused users. Frase - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On 07/29/2014 09:00 PM, Alan Conway wrote: Done r1614472 | aconway | 2014-07-29 15:59:19 -0400 (Tue, 29 Jul 2014) | 2 lines QPID-5941: Set sensible default build type: default is RelWithDebInfo. Thanks Alan! - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On Mon, 2014-07-28 at 19:17 +0100, Fraser Adams wrote: > On 28/07/14 14:29, Alan Conway wrote: > > > > Based on discussion so far I am inclined to > > - make the default build type RelWithDebInfo > > - udpate cpp/INSTALL discussion of build types (it does mention > > Release/Debug already, I'll add mention of the other types. > > > > We don't have unanimity over Release vs. RelWithDebInfo as the preferred > > default, but RelWithDebInfo appears to have more support. Don't forget > > this is only the default, people can choose whatever they prefer (and > > the INSTALL will be updated so they'll know what the choices are) > > > I still don't really like symbols being included by default, but I > appear to be outnumbered. If that is going to be the default could I ask > that some comment/echo be added to the CMake to say what build type is > being used and to warn users that debug symbols are being included? Done r1614472 | aconway | 2014-07-29 15:59:19 -0400 (Tue, 29 Jul 2014) | 2 lines QPID-5941: Set sensible default build type: default is RelWithDebInfo. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On 28/07/14 14:29, Alan Conway wrote: Based on discussion so far I am inclined to - make the default build type RelWithDebInfo - udpate cpp/INSTALL discussion of build types (it does mention Release/Debug already, I'll add mention of the other types. We don't have unanimity over Release vs. RelWithDebInfo as the preferred default, but RelWithDebInfo appears to have more support. Don't forget this is only the default, people can choose whatever they prefer (and the INSTALL will be updated so they'll know what the choices are) I still don't really like symbols being included by default, but I appear to be outnumbered. If that is going to be the default could I ask that some comment/echo be added to the CMake to say what build type is being used and to warn users that debug symbols are being included? Frase - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On Sat, 2014-07-26 at 02:46 -0400, Pavel Moravec wrote: > > - Original Message - > > > >I think that RelWithDebInfo is more generally useful - it gives you > > > >nearly all the optimisation you want and debugging symbols for when you > > > >screw up! > > > > > > > > Works for me. Did some quick benchmarks and the perf differences between > > Release and RelWithDebInfo are not big. One test was 2% off on > > throughput, 10% off on latency, but other tests didn't show any > > significant difference. > > > > I'll change it on Tues if nobody else objects. > > I would vote for whatever of these options to be the default, but with > mentioning what the default is and describe its options. I.e. update > qpid/cpp/INSTALL, part "Note that there are 4 different predefined cmake > build types" (maybe worth mentioning it at the beginning of Paragraph 2) > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > Based on discussion so far I am inclined to - make the default build type RelWithDebInfo - udpate cpp/INSTALL discussion of build types (it does mention Release/Debug already, I'll add mention of the other types. We don't have unanimity over Release vs. RelWithDebInfo as the preferred default, but RelWithDebInfo appears to have more support. Don't forget this is only the default, people can choose whatever they prefer (and the INSTALL will be updated so they'll know what the choices are) - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
- Original Message - > > >I think that RelWithDebInfo is more generally useful - it gives you > > >nearly all the optimisation you want and debugging symbols for when you > > >screw up! > > > > > Works for me. Did some quick benchmarks and the perf differences between > Release and RelWithDebInfo are not big. One test was 2% off on > throughput, 10% off on latency, but other tests didn't show any > significant difference. > > I'll change it on Tues if nobody else objects. I would vote for whatever of these options to be the default, but with mentioning what the default is and describe its options. I.e. update qpid/cpp/INSTALL, part "Note that there are 4 different predefined cmake build types" (maybe worth mentioning it at the beginning of Paragraph 2) - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
- Original Message - > From: "Josh Carlson" > To: users@qpid.apache.org > Cc: "Fraser Adams" > Sent: Friday, July 25, 2014 1:38:04 PM > Subject: Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker > > > > > > The only way I'd feel happy defaulting to a build with debug symbols > > or otherwise unstripped is if the build informed the users that this > > was the case. I truly believe that the most common use case for an > > average user is to want to download, build and enjoy and they should > > have a reasonable expectation of a build that is shipable to a mission > > critical operational environment without having to work out some > > (likely undocumented) magic incantation. > > > > It's not just about the performance, accidentally shipping operational > > code with debug symbols is bad practice IMHO. > > Why not just provide two downloads, one for debug, the other for > production and/or perf testing? > > -Josh > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > Qpid doesn't provide any binary downloads, only sources. The primary question is about what you get with cmake; make; ./qpidd versus with cmake -DCMAKE_BUILD_TYPE=Release; make; ./qpidd Getting casual evaluators to issue the second command line is more work and possibly a barrier to entry. This is true especially when users like OP get low performance numbers. The secondary question is whether Release builds produce debug symbols or not. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
The only way I'd feel happy defaulting to a build with debug symbols or otherwise unstripped is if the build informed the users that this was the case. I truly believe that the most common use case for an average user is to want to download, build and enjoy and they should have a reasonable expectation of a build that is shipable to a mission critical operational environment without having to work out some (likely undocumented) magic incantation. It's not just about the performance, accidentally shipping operational code with debug symbols is bad practice IMHO. Why not just provide two downloads, one for debug, the other for production and/or perf testing? -Josh - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
Hey 郑勰, Qpid should definitely be able to achieve at least 200,000 per second, though it'll depend on the message size and hardware obviously. Check out the paper linked below: http://www.redhat.com/f/pdf/mrg/Reference_Architecture_MRG_Messaging_Throughput.pdf That paper has something like 380,000 x 256 octet messages per second on 2008 hardware. Hopefully the link helps you out setting up a representative test environment. Certainly don't dismiss qpid without sorting out the optimisation!! You say your boss is inclined not to use qpid, so what does he have in mind that offers higher throughput? In my own experience qpid::messaging/qpidd has been the fastest messaging setup and we generally wind up being network bound. To be fair you might well get better raw performance with something like ZeroMQ but you might want to think about more than *just* raw performance (though that's really important) one thing with qpid is that is supports AMQP 1.0 so if you are looking to integrate your system with another at any point it's likely important to consider an Open Standard wire protocol. HTH, Frase On 25/07/14 17:27, 郑勰 wrote: > We expect sent messages and received messages should be at least 200,000 per > second.However, I am really trying to convince myself to obtain this goal. > I want to know all of your performance result. > > Thanks! > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: REQEST FEEDBACK Re: How to test the performance quid c++ broker
> -Original Message- > From: Fraser Adams [mailto:fraser.ad...@blueyonder.co.uk] > Sent: Friday, July 25, 2014 1:22 PM > To: users@qpid.apache.org > Subject: Re: REQEST FEEDBACK Re: How to test the performance quid c++ > broker > > On 25/07/14 17:27, Steve Huston wrote: > > > > I believe that the person likely to be downloading qpid source is a > > developer. It is likely a developer that does not want to become > > intimately familiar with debugging Qpid - they just want it to work > > without asking questions. But it is a person who may need a sensible > > stack trace, line numbers, etc. to at least post back here if > > something goes amiss. They will, after all, need to be testing their > > own software that uses Qpid and may have occasion to ask things here. > > > > When things are all debugged and ready to deploy, the user may want to > > rebuild w/o debinfo, but if not, it will still perform very well in > > the field. > > > > -Steve > > > > > I don't agree with the assertion "the person likely to be downloading qpid > source is a developer " - well perhaps a developer of some persuasion, but I > certainly don't agree that they are necessarily a > *qpid* developer. I didn't say *qpid* developer - but qpid doesn't do anything on its own - someone has to write code to do something with qpid. > The only way I'd feel happy defaulting to a build with debug symbols or > otherwise unstripped is if the build informed the users that this was the > case. > I truly believe that the most common use case for an average user is to want > to download, build and enjoy and they should have a reasonable expectation > of a build that is shipable to a mission critical operational environment > without having to work out some (likely > undocumented) magic incantation. > > It's not just about the performance, accidentally shipping operational code > with debug symbols is bad practice IMHO. As Andrew said, the debug info is generally a separate file. After you've spent some night being called in on a problem and you have _nothing_ to go on but hex stack, you will fight to the death to get debug info in all future projects. Trust me :-) Back in the day, as they say, all we had was hex stack and a link map. And compile code generation listings. On green bar paper. I ain't goin back there. -Steve - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
+1 to Andrew's reasoning. The WinSDK ships Debug and RelWithDebInfo and calls them "Debug" and "Release". Without the symbols field support is much harder. -Chuck - Original Message - > From: "Andrew Stitcher" > To: users@qpid.apache.org > Sent: Friday, July 25, 2014 1:13:45 PM > Subject: Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker > > On Fri, 2014-07-25 at 12:13 -0400, Alan Conway wrote: > > On Fri, 2014-07-25 at 16:47 +0100, Fraser Adams wrote: > > > ... > > > My vote would be to default to the most optimised/operational-quality > > I agree with this, but I strongly believe that operational-quality > includes debugging symbols. > > Operational systems *will* have problems and without debug symbols > somewhere, core dumps are next to useless. > > I think it's important to note that systems vendors usually ship > debugging symbols - I know that Red Hat do, Microsoft do, and I'm pretty > sure that Sun used to too. > > Now these debugging symbols are usually not kept in the executables > themselves, but in separate files which are split apart in the product > build. For RHEL/Fedora there are -debuginfo packages that give you > source and symbols. > > > ... > > > If the RelWithDebInfo is exactly as fast then that's probably OK, but if > > To be honest I wouldn't have chosen the exact default flags for the > different builds that the CMake developers have chosen - these are (for > gcc) > > Debug: -g > Release: -O3 -DNDEBUG > RelWithDebInfo: -O2 -g -DNDEBUG > MinsizeRel: -Os -DNDEBUG > > I think it makes almost no sense to build without debugging info, so I'd > change Release to "-O3 -g -DNDEBUG". Although -O3 often makes > optimisations that confuse a debugger at least you'd get a stack trace. > > My personal favourite would be "-Os -g" - Often, paradoxically, (though > you need to benchmark) optimising for space speeds up your code more > than optimising for speed. Philosophically I don't think you should ever > turn assertions off either, so I'd not include -DNDEBUG. > > In any case, I think the difference between -O2 and -O3 is small. But I > strongly assert that debug symbols are an important end-user deployment > feature, for when things go wrong (and of course they will eventually). > > > > 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 fail to see how shipping symbols to code that is open source changes > the attack surface even if you subscribe to "security by obscurity". > > Andrew > > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On 25/07/14 17:27, Steve Huston wrote: I believe that the person likely to be downloading qpid source is a developer. It is likely a developer that does not want to become intimately familiar with debugging Qpid - they just want it to work without asking questions. But it is a person who may need a sensible stack trace, line numbers, etc. to at least post back here if something goes amiss. They will, after all, need to be testing their own software that uses Qpid and may have occasion to ask things here. When things are all debugged and ready to deploy, the user may want to rebuild w/o debinfo, but if not, it will still perform very well in the field. -Steve I don't agree with the assertion "the person likely to be downloading qpid source is a developer " - well perhaps a developer of some persuasion, but I certainly don't agree that they are necessarily a *qpid* developer. Packaging for various distros has improved recently, but as with most Open Source projects the default mindset is that users download cmake/configure enjoy It'd clearly be lovely if such users ultimately want to join the community, but I believe that the majority of people who download our software just want to *use* it and I believe that we should be making it as simple as possible for them to download/build/use The only way I'd feel happy defaulting to a build with debug symbols or otherwise unstripped is if the build informed the users that this was the case. I truly believe that the most common use case for an average user is to want to download, build and enjoy and they should have a reasonable expectation of a build that is shipable to a mission critical operational environment without having to work out some (likely undocumented) magic incantation. It's not just about the performance, accidentally shipping operational code with debug symbols is bad practice IMHO. Frase - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On Fri, 2014-07-25 at 12:13 -0400, Alan Conway wrote: > On Fri, 2014-07-25 at 16:47 +0100, Fraser Adams wrote: > > ... > > My vote would be to default to the most optimised/operational-quality I agree with this, but I strongly believe that operational-quality includes debugging symbols. Operational systems *will* have problems and without debug symbols somewhere, core dumps are next to useless. I think it's important to note that systems vendors usually ship debugging symbols - I know that Red Hat do, Microsoft do, and I'm pretty sure that Sun used to too. Now these debugging symbols are usually not kept in the executables themselves, but in separate files which are split apart in the product build. For RHEL/Fedora there are -debuginfo packages that give you source and symbols. > ... > > If the RelWithDebInfo is exactly as fast then that's probably OK, but if To be honest I wouldn't have chosen the exact default flags for the different builds that the CMake developers have chosen - these are (for gcc) Debug: -g Release: -O3 -DNDEBUG RelWithDebInfo: -O2 -g -DNDEBUG MinsizeRel: -Os -DNDEBUG I think it makes almost no sense to build without debugging info, so I'd change Release to "-O3 -g -DNDEBUG". Although -O3 often makes optimisations that confuse a debugger at least you'd get a stack trace. My personal favourite would be "-Os -g" - Often, paradoxically, (though you need to benchmark) optimising for space speeds up your code more than optimising for speed. Philosophically I don't think you should ever turn assertions off either, so I'd not include -DNDEBUG. In any case, I think the difference between -O2 and -O3 is small. But I strongly assert that debug symbols are an important end-user deployment feature, for when things go wrong (and of course they will eventually). > > 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 fail to see how shipping symbols to code that is open source changes the attack surface even if you subscribe to "security by obscurity". Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On Fri, 2014-07-25 at 14:48 +, Steve Huston wrote: > Exactly - I agree with Andrew. > > On 7/25/14, 10:46 AM, "Andrew Stitcher" wrote: > > >On Fri, 2014-07-25 at 10:30 -0400, Alan Conway wrote: > >> ... > >> 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 :) > > > >I think that RelWithDebInfo is more generally useful - it gives you > >nearly all the optimisation you want and debugging symbols for when you > >screw up! > > Works for me. Did some quick benchmarks and the perf differences between Release and RelWithDebInfo are not big. One test was 2% off on throughput, 10% off on latency, but other tests didn't show any significant difference. I'll change it on Tues if nobody else objects. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On 7/25/14, 12:13 PM, "Alan Conway" wrote: >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 fir
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
Wow, I didn’t expect a little question would raise a lively discussion. Truth be told, my boss is inclined not to use quid because of low throughout. We expect sent messages and received messages should be at least 200,000 per second.However, I am really trying to convince myself to obtain this goal. I want to know all of your performance result. Thanks! 在 2014年7月26日，上午12:13，Alan Conway 写道： > 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 operatio
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
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 de
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
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. Frase - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On 07/25/2014 03:46 PM, Andrew Stitcher wrote: On Fri, 2014-07-25 at 10:30 -0400, Alan Conway wrote: ... 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 :) I think that RelWithDebInfo is more generally useful - it gives you nearly all the optimisation you want and debugging symbols for when you screw up! I'm fine with that also. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
Exactly - I agree with Andrew. On 7/25/14, 10:46 AM, "Andrew Stitcher" wrote: >On Fri, 2014-07-25 at 10:30 -0400, Alan Conway wrote: >> ... >> 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 :) > >I think that RelWithDebInfo is more generally useful - it gives you >nearly all the optimisation you want and debugging symbols for when you >screw up! > >Andrew > > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On Fri, 2014-07-25 at 10:30 -0400, Alan Conway wrote: > ... > 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 :) I think that RelWithDebInfo is more generally useful - it gives you nearly all the optimisation you want and debugging symbols for when you screw up! Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
On 07/25/2014 03:30 PM, Alan Conway wrote: 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.) +1 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
REQEST FEEDBACK Re: How to test the performance quid c++ broker
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. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
