[zeromq-dev] Comparing OpenDDS and ZeroMQ Usage and Performance

Nicholas Piël nicholas at nichol.as
Thu Jun 24 20:32:05 CEST 2010


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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 




More information about the zeromq-dev mailing list