Ben Kloosterman wrote: >> Yes, there should be a guide to compile-time performance tuning of 0MQ. > >The question is what percentage of users has enough theoretical > >background, experience, available HW resources and funding to perform > >relevant benchmarking and tuning. > > I dislike any form of "compile time" tuning ... it is one of those things > that has turned building Unix apps into a dogs breakfast with incredibly > painful make / configuration systemss, it used to be so simple.
Agreed, but there's no way to set the MAX_VSM_SIZE at runtime. Compiler has to be aware of it. >> Existing compile time constants are carefully chosen to perform best on > >common modern hardware. Playing with them is likely to cause more harm > >than good. > > Agree , considering how fast it is in most cases it would be premature > optimization..Once you have your app finished tune by all means. Doing some > testing last few days and quite a few surprises. My point was that doing perf tests and optimisation without understanding how it should be done can be pretty much misleading. For example, when measuring throughput, using [msgs/sec] unit is extremely misleading. It blows small fluctuations or chip/memory implementation details completely out of proportion. 10M msgs/sec is twice as good as 5M msgs/sec, right? When you think of it, 10M msgs/sec means each message is processed 100 nanoseconds. 5M msgs/sec means each message is processed 200 nanoseconds. Real improvement is 100 nanoseconds per message. Which can result from couple of additional CPU instructions, a small measurement imprecision or maybe even from minor manufacturing flaws of your CPU / memory. In short, when doing throughput tests, use "time to process one message" metric rather than "messages per second". It'll give you more sane picture of what the actual performance impact is. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
