Hi Don, It seems that you have used the default settings for ProtoBuf. By default it optimizes for code size, when you add the following line "option optimize_for = SPEED;" to your .proto file, ProtoBuf will show a significant performance increase.
Cheers, Nicholas On Jun 24, 2010, at 7:16 PM, Don Busch wrote: > Hi, > > Martin Sustrik <sustrik <at> 250bpm.com> writes: > >> >> Michael, >> >>> I've never seen this kind of latency for 1KB messages, but then again I've >>> only used 0MQ on Linux. I don't have access to a system with a real-time >>> kernel, but I'd be willing to try to duplicate the raw buffer comparison >>> tests on Linux w/ Ethernet and 20Gb Infiniband. It will be a couple of >>> weeks before I can get around to it though. >> >> That would be great. Thanks! >> >> Martin >> > > I wrote the paper. If you'd like to run the tests on a faster box with an RT > kernel, that would be great. That's why the source code is attached, and the > paper encouraged users to build the code and run the tests themselves. > > The laptop I ran them on is really old and slow, and the paper stated as > such, > so the raw numbers aren't worth much. It's the relative numbers that are more > interesting. I needed a Windows box for the .NET comparisons. > > The point of the paper is that the decision to use ZeroMQ or OpenDDS depends > a lot on what you're using it for. If all you're doing is sending raw > buffers > over the wire, and your collection of participating processes doesn't change > throughout the execution of the system, then ZeroMQ will be faster than > OpenDDS. But if you are sending something like C++ structs, then you have to > build that capability on top of ZeroMQ one way or another and that will kill > any performance advantage that ZeroMQ has. Also, if your system consists of > processes that intermittently come and go, then OpenDDS can handle that right > out of the box whereas you'd have to build it on top of ZeroMQ. OpenDDS also > has a load of QoS capabilities that the article doesn't really talk much > about, capabilities that you'd have to build on top of ZeroMQ if you > want them. > > So to summarize, I guess, we'd encourage users to look at their full > end-to-end > use cases to figure out what they really need. If they find themselves > wanting > to build things on top of ZeroMQ that are already in OpenDDS, then they most > likely eliminate the performance advantage of ZeroMQ while also creating a > lot > of extra work for themselves. > > But, yes, I certainly encourage people to take the code and build and run it > themselves. ZeroMQ looks like an interesting product. > > Best Regards, > > Don Busch > Principal Software Engineer > Object Computing, Inc. > > > > > > > > > > > > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
