mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Minjie Wang <minjie.w...@nyu.edu>
Subject Re: ZeroMQ dependency
Date Tue, 21 Feb 2017 22:06:00 GMT
My colleagues and I are working on adding more support for data
transmission. For example, send/recv operators in dataflow graph to support
some fancier parallelism. I feel like this could be part of mxnet in the
future (need more discussions for sure). Currently, we are using zeromq
since we already depend on it. Does that mean we should actually consider
using other libraries?

For 3), it should not be hard since we are only transmitting arrays. We
don't need to support rich types and complex data structures like normal
RPC.

- Minjie

On Tue, Feb 21, 2017 at 11:53 AM, Will, Martin <hansmart@amazon.com> wrote:

> Re 3.) Nanomsg is licensed under BSD. [http://nanomsg.org/]. It’s written
> by one of the original authors of zeromq, and can be considered as an
> evolution it. The API mostly maps 1-to-1.
>
> - Martin
>
>
> On 2/20/17, 11:54 PM, "Henri Yandell" <bayard@apache.org> wrote:
>
>     How tied is MXNet to ZeroMQ?
>
>     My notes are that ps-lite depends on it.
>
>     Options I can see here are:
>
>     1) Discuss on general@incubator and determine if the exception is
>     acceptable. I suspect this is unlikely given that Apache Toree had a
>     problem with jeromq which led to jeromq very kindly relicensing to MPL
> (
>     https://github.com/zeromq/jeromq/issues/326).
>     2) Request libzmq relicense to MPL. This is something the project has
>     begun, but seems to be in frozen currently (unless I'm missing recent
>     activity).
>     3) Rewrite MXNet to not rely on zeromq. How difficult would that be?
>     4) Switching MXNet to use something other than ps-lite? (Not sure if
> that's
>     easier than #3).
>
>     Any thoughts on #3 + #4?
>
>     Thanks,
>
>     Hen
>
>
>


-- 
Minjie Wang
*New York University | Computer Science*
715 Broadway, New York, NY, 10009

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message