[nanomsg] Re: Few Questions and Comments

  • From: Doron Somech <somdoron@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sun, 20 Apr 2014 14:59:59 +0300

Thanks,

I have some more questions, from the code I read so far nanomsg isn't
sending messages in bulk, that means to support 2 millions messages 2
millions calls to socket send is going to happen, is it possible to achieve
millions of messages like that (I more focused on the windows code)?

You choose to not do multi-part messages, why is that? that will make it
hard for interoperability between zeromq and nanomsg.

On that note, why didn't you choose zmtp as the tcp transport? (I know it
should be easier to add more transports and probably ZMTP implementation
will be in the future), but implementing ZMTP will make it much easier to
move to nanomsg.

Regards,

Doron




On Sun, Apr 20, 2014 at 2:23 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Doron,
>
> > I'm going over the nanomsg code, so far I think it's much simpler
> > than ZeroMQ (I ported zeromq to .net and thinking about doing the
> > same for nanomsg).
>
> Nice!
>
> > However I do have some questions:
> >
> > * there is a critical section on the critical path of the library,
> > every time you send or receive a message there is a lock, zeromq
> > doesn't have any lock on the critical path, I understand this is in
> > order to have simple threading model, but isn't that expensive?
> > because it's usually very short waits, doesn't it be better to use
> > user space lock? like spin lock?
>
> The primary incentive to add the lock was to make sockets thread-safe.
> You may have seen how ZeroMQ sockets are not and how that confuses the
> hell out of the users.
>
> As for the performance impact, it's a trade-off. Spin-locks fare great
> if there's low contention, but fares not so well otherwise. So,
> basically, nanomsg doesn't try to make the optimal locking algorithm
> and assumes that the OS developers have already done their best to
> make mutexes as performant as possible.
>
> > * file descriptor is used for singaling when a message is ready or
> > socket is ready to send a message (same as zeromq), as I understand
> > the only reason FD is used instead of other signalling objects is
> > to be able to use it with a other file descriptor (not from
> > nanomsg), the question is, giving up this feature, will it be much
> > faster to use other singaling objects? maybe even lock-free user
> > space objects?
>
> The measurements we've made (on Linux) indicate that whatever
> signalling mechanism you use, the propagation delay between two CPU
> cores is always the same (~6us). This may, of course, not be true of
> other OSes (Windows). It's up to the people interested in this kind of
> thing to make the measurements.
>
> Martin
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTU64eAAoJENTpVjxCNN9Yx5kIAKbLizMqqcnGyzb4IKJ2h4I3
> 21L9RTxjXbh3ykuWSUDw9F2vNqTOz8i0oS9WocR1cl4wBgDRT6c2jBF0epKCQJis
> 2MeXXsmj4CnKQWtz4Nt//6KCv1LzpPuPTEG5T2vWGeV4jgHkSgHym7afsUAqNPCY
> IoATNbhfZExiD0uQAtrXJQgJXMT3+iqn6IPUXdYjctXDiJ49GEz8I0gjKaWWz8vt
> V5F2sNeiktM6bHiNpvkVGIDeZ1TgxJiJj+6SZwVur1sIY1UQzLcUUMNgKKW9uDJu
> XELdEr5mPUcifscMNo+Y6R8K7TFcKSx+vFe99fmEXFGsFKGuycv+He0vDjTvNxk=
> =vN63
> -----END PGP SIGNATURE-----
>
>

Other related posts: