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.
Post by Don BuschHi,
Post by Martin SustrikMichael,
Post by Michael SantyI'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
http://lists.zeromq.org/mailman/listinfo/zeromq-dev