See my comments below: On Wed, Aug 29, 2012 at 5:28 PM, Chuck Remes <li...@chuckremes.com> wrote:
> > On Aug 29, 2012, at 4:46 PM, Julie Anderson wrote: > > See my comments below: > > > And mine too. > > On Wed, Aug 29, 2012 at 4:06 PM, Robert G. Jakabosky < > bo...@sharedrealm.com> wrote: > >> On Wednesday 29, Julie Anderson wrote: >> > So questions remain: >> > >> > 1) What does ZeroMQ do under the rood that justifies so many extra clock >> > cycles? (I am really curious to know) >> >> ZeroMQ is using background IO threads to do the sending/receiving. So the >> extra latency is do to passing the messages between the application >> thread and >> the IO thread. >> >> > This kind of thread architecture sucks for latency sensitive applications. > That's why non-blocking I/O exists. That's my humble opinion and the > numbers support it. > > > What numbers? Only you have produced them so far. > > We have been quite patient with you. It appears you have some experience, > so I'm confused as to why you refuse to provide any code for the rest of us > to run to duplicate your results. If the roles were reversed I am certain > you would want to run it yourself. > > If you want our help, don't tell us to "google" some code to run. If it's > really that easy then provide a link and make sure that your numbers are > coming from the exact same code. Until someone else can independently > verify your numbers then everything you have written is just smoke. > I understand your frustration. I don't put the code here because I don't want to, but because I am legally unable to. If you have a boss or employer you can understand that. :) I will try to come up with a simple version to do the same thing. I should not be hard to do a ping-pong in Java. > > Also try comparing the latency of Java NIO using TCP/UDP against ZeroMQ >> using >> the inproc transport using two threads in the same JVM instance. >> > > What is the problem with inproc? Just use a method call in the same JVM or > shared memory for different JVMs. If you want inter-thread communication > there are blazing-fast solutions in Java for that too. For example, I would > be surprised if ZeroMQ can come close to Disruptor for inter-thread > communication. > > I would be surprised too. Zeromq doesn't solve the same problem as > Disruptor. > > Disruptor solves inter-thread communication without synchronization latency (light blocking using memory barriers). So if you have two threads and need them to talk to each other as fast as possible you would use disruptor. That's what I thought the colleague was addressing here: *"Also try comparing the latency of Java NIO using TCP/UDP against ZeroMQ using the inproc transport using two threads in the same JVM instance."* > Basically ZeroMQ has different use-case then a simple IO event loop. >> > > I thought ZeroMQ flagship customers were financial institutions. Then > maybe I was wrong. > > > Don't be insulting. It doesn't help you or inspire anyone here to look > into your claims. > Insulting? I really think I was not insulting anyone or anything, but if you got that impression please accept my sincere apologies. Nothing is perfect. I am just trying to understand ZeroMQ approach and its overhead on top of the raw network latency. Maybe a single-threaded ZeroMQ implementation for the future using non-blocking I/O? > > cr > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
