Hi Martin,
> Hi Kelly,
>
> > So, the on and off poking at IOCP integration into Zmq has basically
> >ended for the moment at least by me. I'm actually digging into something
> >which has done the whole abstraction already before I get back to the Zmq
>
> Yes. This is a problem with all Microsoft products. Porting 0MQ to to
> Win32 took approximately 50x more time than porting to any other
> platform. IOCP seems to be no different in this aspect.
Well, while I'm not a MS fanboy, I will give them the benefit that
IOCP "can" be more efficient and have lower latency than epoll or kevent
versions. On the other hand, is 5% reduced memory bandwidth and slightly
more linear scaling really worth all the extra work? I don't think so
personally, I'd rather just buy another server instead of wasting weeks of
time.. $2k-$3k for another server is cheaper in the bang for the buck
department compared to time optimizing for a minor gain.
> > Now given the above, Zmq is more of a high level framing and
> >organization item than it is a "network" layer. Yes, the low level
> >networking is important and critical to the functionality of Zmq. But,
> how
> >you handle sockets (tcp specifically) is minor in comparison to the rest
> >
> > Just an idea right now while I'm off playing with libevent release
> >candidate.
>
> 0MQ having as little dependencies (virtually none) is a deliberate
> decision. It allows porting it to anything from smallest embedded
> devices to the largest supercomputers. Using libevent would restrict the
> range just to the platforms supported by libevent. That said, I would
> reckon that rewriting 0MQ infrastructure to work well with libevent
> would take more or less same amount of effort as coding native IOCP
> support.
I totally agree with the lack of dependencies and was thinking more
along the lines of a dev branch where the abstractions are made against
libevent with the eventual intention of replacing libevent with a local
grown iocp. On the other hand, I don't agree that doing both IOCP and the
internal changes at the same time is similar in effort and time.
As you stated above, the porting efforts to Win32 are pretty huge
and I'd rather keep the efforts focused on one thing at a time. I.e. use an
existing IOCP instead of rolling our own for the moment so we can focus on
the internal changes without dealing with a brand new source of bugs. The
benefit being that we can use the libevent code for select/poll/epoll/kqueue
etc as we go and cross check the changes. Obviously libevent will have bugs
probably (it is only at release candidate 7) but it will still likely have
fewer bugs than anything we could implement initially with a refactor of
this scale.
Basically, I'd rather concentrate on one thing at a time. The
internal refactor is going to be a big task. This is why I jumped in and
starting hacking, I wanted to see the show stoppers, if any, first. Keeping
select/poll/epoll/kevent working should be fairly easy during this work.
IOCP won't work till towards the end and then only Windows would have a
libevent dependency until the local grown socket iocp reactor is then
implemented.
I suggested this path simply to reduce the number of moving parts
and overall risk involved. Not to mention given the performance desires, we
can track that over latency rates as we proceed and make comparisons as we
go in multiple ways.
KB
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
