Re: Call for Ideas and Approaches to Community Building
This is a great discussion, thanks for opening, Carin! As a newcomer to MXNet and Apache communities in general, I’ve been considering what I can bring to the table here, and what importance it would have to me. I'm not employed by large organizations, and communities like this are perhaps the only way to be involved in projects of such a large scale and importance. An opportunity to join this type of team without the full commitment of employment is fantastic! I see potential for this to be a form of validation, a chance to meet others and build professional relationships, and a vehicle to learn from some of the most well-educated people in the industry. That said, here’s what I’ve noticed thus far: 1. There is a healthy amount of activity in Github Issues, and the committers are doing a great job at allowing newcomers to jump in. I was able to get started on my first ticket within 10 minutes of searching thru issues. 2. The dev mailing list is a great place to discuss all of the nuances of the project. I also like meeting people and it would be rewarding to get to know people in the community via Skype or in-person meetups! This doesn’t have to be for everyone, and I don’t think it’s appropriate for Q&A, but for some people a social element purely for the sake of putting names with faces can be rewarding. I’m open to virtual meetups :) 3. My first commit was smooth. When approaching the second one, I’m hitting some hiccups. For instance, I recently created a JIRA ticket based on a Github Issue some users reported, and the ticket has been sitting for a week without any activity. Should I just dig in and open a PR? How do the commiters decide what can and can’t reasonably go into the project? We may be able to make some changes to the contribution documentation or processes to make it easier for first time contributors to ramp-up into regular contributors? 4. I would love to see more discussion about the future of MXNet. I imagine those who have been involved in the project for a long time have thoughts about next major steps, but as an outsider I’m not sure where to find this information. The roadmap on Github is fairly short-term and outdated, and lots of interesting ideas are sprouting in projects like TF Swift as of 2019. 5. Something I’ve observed across many Apache projects: there isn’t much focus on marketing. I wonder why? A tool like Tensorflow is reaching 10x more people, mainly because of marketing. Best, Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101 On Thu, Mar 7, 2019 at 5:38 AM Tianqi Chen wrote: > what happens (also) happens in the mail-list. > > If there is a certain things or person’s contribution is only known by > colleagues, it is a indication of things that should be improved toward > more apache way. > > Tianqi > > On Thu, Mar 7, 2019 at 4:42 AM Isabel Drost-Fromm > wrote: > > > On Wed, Mar 06, 2019 at 10:03:57PM -0800, Steffen Rochel wrote: > > > I agree with Tianqi on "One approach toward building a more diverse > > > community is to acknowledge the fact that we want to encourage > > interactions > > > in the Apache way beyond our physical cycle." However, I disagree with > > his > > > suggestion regarding "One principle to toward that is to encourage PMC > > > members only nominate committers from other organizations" for the > > > following reasons: [...] > > > > I spent quite some time digging remembering that a similar topic had been > > discussed somewhere at the ASF at some point in time with many whys, pros > > and > > cons towards contributor employer diversity - finally found a long and > > winding > > thread there: > > > > > > > https://lists.apache.org/thread.html/7a7412316ddbe1d43f5fb3d3703ea25a6b26e56de602e27e175785c0@1337815698@%3Cgeneral.incubator.apache.org%3E > > > > > > There is one answer in there from Roy Fielding which has a similar story > > to the > > one that you are describing, Steffen. My main takeaway of what was > > discussed > > back then: "Diversity is only a warning sign that means we need to check > > for > > decisions made in our forums and advise accordingly." > > > > The questions I personally tend to ask myself: How easy is it to follow > the > > project from just subscribing to it's mailing lists (remember the "if it > > didn't > > happen on the mailing list, it didn't happen"), get active, get involved, > > be > > treated as a fellow project member and be voted in as committer and PMC > > member. > > > > For a more condensed text on the topic of "ASF projects are made of > > individuals" > > you might also want to check out the ASF
Re: First class support for MxNet?
Really interesting stuff, Iblis. Thanks for sharing! I'm excited to stick around and absorb :D Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101 On Mon, Feb 11, 2019 at 6:25 AM Carin Meier wrote: > +100 on Iblis's thoughts: > > "We know tools and frameworks keep changing. > People learn the lesson from making and attempting. > It's just the path of the human technology evolution. > The point is the ideas/experiences > which this community is going to surprise you at." > > - Carin > > > On Mon, Feb 11, 2019 at 9:08 AM iblis wrote: > > > well, I'm not going to talk about technical stuffs. > > You can find some design concepts on doc or wiki. > > ( > > > https://mxnet.incubator.apache.org/versions/master/architecture/index.html > > ) > > > > For me, working on MXNet is a rare chance to verify my ideas of > > a machine learning framework. > > During implementing MXNet Julia package, I can explicitly compare the > > experience of MXNet with Flux's > > ...and than start to complaining about them. :p > > I think a way to moving forward is comparison. > > So that's why I said I want to increase the diversity of DL tools in > Julia. > > > > I like the spirit of portability in MXNet community. > > We welcomed all of language packages and open-minded. > > Although some of languages might be considered not popular in ML/DL, > > this community still keep polishing them day in day out. > > Yeah, someone has to try it, compare and gain experience from this > > process regardless of how the language has been evaluated in ML. > > The experience is valuable. > > (e.g. I think lack of function overloading is a disadvantage > > of Python; the file-based namespace does help for maintainability > > in Python. > > After I did some works in Julia, I can clearly point out pros and > cons.) > > > > From a long-term view... maybe twenty years after, > > none of the languages we are using now will be popular. > > But I believe the meta-rules which extracted from experiences are still > > applied. > > > > So.. why not have a Rust lib? maybe Rust's macro can do something crazy, > > maybe. > > e.g. Julia package shows a more elegant way to stack a network than > Python, > > thanks to metaprogramming. > > > >mlp = @mx.chain mx.Variable(:data) => > > mx.FullyConnected(name=:fc1, num_hidden=128) => > > mx.Activation(name=:relu1, act_type=:relu) => > > mx.FullyConnected(name=:fc2, num_hidden=64) => > > mx.Activation(name=:relu2, act_type=:relu) => > > mx.FullyConnected(name=:fc3, num_hidden=10) => > > mx.SoftmaxOutput(name=:softmax) > > > > > > > Wondering where that leaves MxNet... > > > > Actually, I don't case about this issue. > > We know tools and frameworks keep changing. > > People learn the lesson from making and attempting. > > It's just the path of the human technology evolution. > > The point is the ideas/experiences > > which this community is going to surprise you at. > > > > > > Iblis Lin > > 林峻頤 > > > > On 2/11/19 12:04 PM, Zach Boldyga wrote: > > > Those are compelling points! There's also another more recent follow-up > > > from the Julia team: > > https://julialang.org/blog/2018/12/ml-language-compiler > > > . > > > > > > It seems that Julia will likely have it's place in ML regardless of how > > > other tools progress; the latest offerings from Julia/Flux are really > > > compelling. > > > > > > Wondering where that leaves MxNet... > > > > > > Zach Boldyga > > > Scalabull | Founder > > > 1 (866) 846-8771 x 101 > > > > > >
Re: First class support for MxNet?
Those are compelling points! There's also another more recent follow-up from the Julia team: https://julialang.org/blog/2018/12/ml-language-compiler . It seems that Julia will likely have it's place in ML regardless of how other tools progress; the latest offerings from Julia/Flux are really compelling. Wondering where that leaves MxNet... Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101 On Sat, Feb 9, 2019 at 11:02 PM Iblis Lin wrote: > (well, I'm a Julia programmer, my opinion might be quite bias. :p) > > No. I think Python is still dominating at this moment. > I agree the Julia blog post about ML and PL > (it also mentioned in that Swift artical): >https://julialang.org/blog/2017/12/ml&pl > >(Chinese version) >https://julialang.org/blog/2017/12/ml&pl-cn >https://julialang.org/blog/2017/12/ml&pl-zh_tw > > TL;DR from my view: > (Quote from the blog) > "Any sufficiently complicated machine learning system contains an ad-hoc, > informally-specified, bug-ridden, slow implementation of half of a > programming language." > > Runtime & Ecosystem > Basically, I will say that TensorFlow/MXNet/PyTorch are different > standalone > programming languages for specific domain -- numerical computation. > They use Python as their interfaces to build models. > Where do the models get computed? In their own runtime. > This runtime shares nothing with CPython's runtime. > User puts "+-*/" symbols and placeholders in Python, > but nothing is computed by CPython. > > So...what's the problem about having own runtime? > In case of TF/MXNet/PyTorch, they splits and throws away the original > ecosystem. > For example, MXNet have its own array type 'NDArray'. > This type only run on our own runtime (libmxnet). > You have to abandon the great works done by scikit-learn from the > ecosystem of Scipy project, which people have already devoted tons of > efforts to. > You need to re-write a porting for NDArray if you want something like > Gaussion Process. > And this builds a wall between libmxnet and numpy runtime. > > I feel so sorry about another example: > > https://mxnet.incubator.apache.org/versions/master/api/python/ndarray/linalg.html > This API was added about 1 year ago (or half year ago?). > It made me anxious. > Tons of numerical systems have more robust and versatile linear algebra > functions. > But some of MXNet developers have to spend their valuable time on > implement linalg > stuffs again. > > About Julia's ecosystem > (Alought selling Julia is not the point.) > Let's talk about what Julia comminuty have done on integrating ecosystem. > There is a package named Flux.jl[1]. > It fully untilized Julia's native Array type and runtime. > For a CPU run, the code is written in pure Julia, and the performance is > quite > competitve[2] for the case of all the code written in high-level > language. > So that I can do some small experiemnts on my FreeBSD desktop > without compiling any C/Cpp extension. > For GPU run, there is a crazy package CUDANative.jl[3] to let user write > kernel code > in pure Julia. It leverages LLVM's PTX backend. > This package is baked by JuliaGPU[4] comminuty. > About AD stuffs, it's supported by another group of poeple from > JuliaDiff [5], > who is doing reseaches on ODE/PDE. > Flux integrates them all and become a part of ecosystem as well. > If user want to use some exotic statistic distributions, just plug the > another > package from JuliaStats[6]. > > > Any plans to take an approach similar to this for the MxNet library? > > TBH, I'm selfish. My answer is Julia. I only care about Julia stuffs. > I'm trying to make more re-use of interfaces from Julia's stdlib and > runtime. > It' challange. I hope the MXNet Julia package is more than a binding and > connecting with the ecosystem. > > So... you might ask that why I'm here and work on MXNet? > I want to increase the entroy of DL tools in Julia. > I think freedom is the symbol in the world of open source, > user should always have anothr choice on softwares. > I personally dislike the state of TF -- being a huge, closed ecosystem. > Many poeple is porting stuffs into TF's system and nothing fed back > ( the backprop got truncated :p ). > I think Julia can find a balance point between MXNet's and original > ecosystem. > > > [1] https://fluxml.ai/ > [2] > https://github.com/avik-pal/DeepLearningBenchmarks#cpu-used-intelr-xeonr-silver-4114-cpu--220ghz > [3] https://github.com/JuliaGPU/CUDAnative.jl > [4] https://github.com/JuliaGPU > [5] https://github.com/JuliaDiff > [6] https://github.com/JuliaStats > > Iblis Lin > 林峻頤 > > On 2/10/19 4:08 AM, Zach Boldyga wrote: > > Any plans to take an approach similar to this for the MxNet library? > > > > > https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md > > > > -Zach > > >
First class support for MxNet?
Any plans to take an approach similar to this for the MxNet library? https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md -Zach
Re: Rust Client Lib
I did some homework and stumbled across something that changed my view of where machine learning libraries are headed: https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md Google & Apple are building first-class support for Tensorflow right into the Swift language. They chose Swift very carefully, and while they noted Rust is a great choice for lots of reasons, the learning curve of the language is too steep... It seems like Rust isn't going to get much love from the ML community in the places that matter. I also see that as of writing this, the Rust crate for Tensorflow has only ~10,000 lifetime downloads, which is pretty low considering how much effort the client library required. So the existing set of practitioners in the language is very small, and it's unlikely to grow. Also, the benefits of Rust memory safety and ownership won't really be realized via a client library that uses FFI on a C API. I'm not going to move forward with this client lib. I'll check back here in the future and see if there's any activity... In the meantime, if someone stumbles across this in the future and wants to pick it up, don't let me stand in the way! - Zach On Wed, Jan 30, 2019 at 11:16 PM Zach Boldyga wrote: > Rad, thanks for the input everyone! > > I'm anticipating some friction with using FFI with the C API since it's > considered unsafe in Rust; difficulty of integrating will depend on the > nuances of the C API as HY mentioned... > > Going to go ahead and dive in. Will be back eventually for feedback / > input! > > Zach Boldyga > Scalabull | Founder > 1 (866) 846-8771 x 101 > > > On Wed, Jan 30, 2019 at 12:02 AM HY Chen wrote: > >> I have tried to create a a module via existing rust FFI generators but >> failed. It seems like you have to think a lot more than just translate the >> C api to make it work. It's better understand the C API first and make >> sure >> it won't introduce new problems in rust. >> >> HY >> >> Pedro Larroy 于2019年1月30日周三 上午4:35写道： >> >> > I have been thinking about this and I find really exciting to have >> > Rust bindings and bring a powerful framework like MXNet to the Rust >> > community and to native applications in a convenient Rust crate. I >> > would love to see this happen. I think basically MXNet needs to be >> > wrapped in a Rust crate via FFI / C Bindings. >> > >> > Pedro. >> > >> > On Tue, Jan 29, 2019 at 11:05 AM Zach Boldyga >> wrote: >> > > >> > > Hey y'all! >> > > >> > > I'm thinking about spending this week working on a rust client lib for >> > > MXNet. saw a little bit of chatter about this in the github issues >> and no >> > > strong existing crates at the moment. Any pointers on approaching this >> > in a >> > > way that will lead to it being adopted as an officially supported >> client >> > > library? And overall yay/nay on whether adding a Rust lib makes sense >> & >> > why >> > > / why not? >> > > >> > > Zach Boldyga >> > > Scalabull | Founder >> > > 1 (866) 846-8771 x 101 >> > >> >
Re: Rust Client Lib
Rad, thanks for the input everyone! I'm anticipating some friction with using FFI with the C API since it's considered unsafe in Rust; difficulty of integrating will depend on the nuances of the C API as HY mentioned... Going to go ahead and dive in. Will be back eventually for feedback / input! Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101 On Wed, Jan 30, 2019 at 12:02 AM HY Chen wrote: > I have tried to create a a module via existing rust FFI generators but > failed. It seems like you have to think a lot more than just translate the > C api to make it work. It's better understand the C API first and make sure > it won't introduce new problems in rust. > > HY > > Pedro Larroy 于2019年1月30日周三 上午4:35写道： > > > I have been thinking about this and I find really exciting to have > > Rust bindings and bring a powerful framework like MXNet to the Rust > > community and to native applications in a convenient Rust crate. I > > would love to see this happen. I think basically MXNet needs to be > > wrapped in a Rust crate via FFI / C Bindings. > > > > Pedro. > > > > On Tue, Jan 29, 2019 at 11:05 AM Zach Boldyga > wrote: > > > > > > Hey y'all! > > > > > > I'm thinking about spending this week working on a rust client lib for > > > MXNet. saw a little bit of chatter about this in the github issues and > no > > > strong existing crates at the moment. Any pointers on approaching this > > in a > > > way that will lead to it being adopted as an officially supported > client > > > library? And overall yay/nay on whether adding a Rust lib makes sense & > > why > > > / why not? > > > > > > Zach Boldyga > > > Scalabull | Founder > > > 1 (866) 846-8771 x 101 > > >
Rust Client Lib
Hey y'all! I'm thinking about spending this week working on a rust client lib for MXNet. saw a little bit of chatter about this in the github issues and no strong existing crates at the moment. Any pointers on approaching this in a way that will lead to it being adopted as an officially supported client library? And overall yay/nay on whether adding a Rust lib makes sense & why / why not? Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101
mxnet slack, contributor
hello, I'm contributing to mxnet and would like to join the slack channel. thanks! Zach Boldyga Scalabull | Founder 1 (866) 846-8771 x 101
