Re: Rust Client Lib
Relevant to this conversation about Rust / Swift bindings, is this recent interview with Yann LeCun which I think hits the nail in the head: https://venturebeat.com/2019/02/18/facebooks-chief-ai-scientist-deep-learning-may-need-a-new-programming-language/amp/ The questions are, do people / science community really want something different than Python? If so what language would it be? Rust would be good for production but for experimentation the most likely candidate is a language like Swift or Julia. Pedro. On Tue, Feb 19, 2019 at 5:53 AM Sheng Zha wrote: > > Hi, > > Thanks for sharing the results. A problem in the benchmark is that the > comparison does not take into account that MXNet is making a copy while > pytorch is not. > > MXNet made the choice of not doing a zero-copy for numpy arrays, but instead > making a copy of the numpy data. This means that users are free to change the > numpy array after passing it into MXNet. On the other hand, PyTorch chose not > to make a copy, by keeping the array alive through incrementing the reference > count and then reuse the data pointer. > > This also explains why pytorch fp16 is this much worse than fp32 in your > results (`.half()` has to make a copy). > > If you control for that factor, you will find MXNet to be 50%-100% faster on > your workload. I shared the results in your gist comments [1]. Feel free to > let me know if you have questions. > > -sz > > [1] > https://gist.github.com/SunDoge/59a8ff336703b45be30b46dc3ee8b4ab#gistcomment-2841120 > > On 2019/02/19 02:33:20, epsund...@gmail.com wrote: > > I wrote some benchmark code, and here's the discussion: > > https://discuss.mxnet.io/t/hybrid-training-speed-is-20-slower-than-pytorch/2731/3 > > > > There's another discussion here: > > https://discuss.mxnet.io/t/performance-of-symbol-vs-ndarray-vs-pytorch/870/6 > > > > I slightly modify it: > > https://gist.github.com/SunDoge/59a8ff336703b45be30b46dc3ee8b4ab > > > > > > On 2019/02/18 19:26:27, Edison Gustavo Muenz > > wrote: > > > Hello! > > > > > > > mxnet is somehow slower than pytorch, even with hybridize on, and that's > > > why I start writing binding for pytorch now. > > > > > > I believe many people in this list will be very interested in why you say > > > this. > > > > > > As far as I know, and correct me if I'm wrong, MXNet is supposed to be a > > > very fast, if not the fastest, dl framework. I mean in raw performance > > > numbers. > > > > > > Would you mind expanding on what you mean? I'm genuinely interested. > > > > > > Best, > > > Edison Gustavo Muenz > > > > > > On Mon 18. Feb 2019 at 17:28, epsund...@gmail.com > > > wrote: > > > > > > > The rust crate for tensorflow support only inference, which limit its > > > > usage. If you really want to deploy your network, TensorRT and TVM may > > > > be > > > > better choice. > > > > > > > > I really want to write a dl framework in rust from scratch. However, > > > > there's no mature GPU Tensor library in rust (rust-ndarray is a great > > > > crate > > > > but it only support CPU. arrayfire may support ND array in the future, > > > > which is a good candidate). So I have to write bindings for existing > > > > project, which is much easier. .The benefit is that I can safely wrap > > > > those > > > > unsafe C pointer, and with the help of generic, I can manipulate data > > > > with > > > > ndarray in a type-safe way. > > > > > > > > The only difficulty is that I'm a postgraduate and I'm pretty sure my > > > > boss > > > > won't be happy to see me writing rust code instead of doing research. > > > > Besides, mxnet is somehow slower than pytorch, even with hybridize on, > > > > and > > > > that's why I start writing binding for pytorch now. > > > > > > > > On 2019/02/09 01:35:04, Zach Boldyga wrote: > > > > > 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
Re: Rust Client Lib
Hi, Thanks for sharing the results. A problem in the benchmark is that the comparison does not take into account that MXNet is making a copy while pytorch is not. MXNet made the choice of not doing a zero-copy for numpy arrays, but instead making a copy of the numpy data. This means that users are free to change the numpy array after passing it into MXNet. On the other hand, PyTorch chose not to make a copy, by keeping the array alive through incrementing the reference count and then reuse the data pointer. This also explains why pytorch fp16 is this much worse than fp32 in your results (`.half()` has to make a copy). If you control for that factor, you will find MXNet to be 50%-100% faster on your workload. I shared the results in your gist comments [1]. Feel free to let me know if you have questions. -sz [1] https://gist.github.com/SunDoge/59a8ff336703b45be30b46dc3ee8b4ab#gistcomment-2841120 On 2019/02/19 02:33:20, epsund...@gmail.com wrote: > I wrote some benchmark code, and here's the discussion: > https://discuss.mxnet.io/t/hybrid-training-speed-is-20-slower-than-pytorch/2731/3 > > There's another discussion here: > https://discuss.mxnet.io/t/performance-of-symbol-vs-ndarray-vs-pytorch/870/6 > > I slightly modify it: > https://gist.github.com/SunDoge/59a8ff336703b45be30b46dc3ee8b4ab > > > On 2019/02/18 19:26:27, Edison Gustavo Muenz wrote: > > Hello! > > > > > mxnet is somehow slower than pytorch, even with hybridize on, and that's > > why I start writing binding for pytorch now. > > > > I believe many people in this list will be very interested in why you say > > this. > > > > As far as I know, and correct me if I'm wrong, MXNet is supposed to be a > > very fast, if not the fastest, dl framework. I mean in raw performance > > numbers. > > > > Would you mind expanding on what you mean? I'm genuinely interested. > > > > Best, > > Edison Gustavo Muenz > > > > On Mon 18. Feb 2019 at 17:28, epsund...@gmail.com > > wrote: > > > > > The rust crate for tensorflow support only inference, which limit its > > > usage. If you really want to deploy your network, TensorRT and TVM may be > > > better choice. > > > > > > I really want to write a dl framework in rust from scratch. However, > > > there's no mature GPU Tensor library in rust (rust-ndarray is a great > > > crate > > > but it only support CPU. arrayfire may support ND array in the future, > > > which is a good candidate). So I have to write bindings for existing > > > project, which is much easier. .The benefit is that I can safely wrap > > > those > > > unsafe C pointer, and with the help of generic, I can manipulate data with > > > ndarray in a type-safe way. > > > > > > The only difficulty is that I'm a postgraduate and I'm pretty sure my boss > > > won't be happy to see me writing rust code instead of doing research. > > > Besides, mxnet is somehow slower than pytorch, even with hybridize on, and > > > that's why I start writing binding for pytorch now. > > > > > > On 2019/02/09 01:35:04, Zach Boldyga wrote: > > > > 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! > > >
Re: Rust Client Lib
I wrote some benchmark code, and here's the discussion: https://discuss.mxnet.io/t/hybrid-training-speed-is-20-slower-than-pytorch/2731/3 There's another discussion here: https://discuss.mxnet.io/t/performance-of-symbol-vs-ndarray-vs-pytorch/870/6 I slightly modify it: https://gist.github.com/SunDoge/59a8ff336703b45be30b46dc3ee8b4ab On 2019/02/18 19:26:27, Edison Gustavo Muenz wrote: > Hello! > > > mxnet is somehow slower than pytorch, even with hybridize on, and that's > why I start writing binding for pytorch now. > > I believe many people in this list will be very interested in why you say > this. > > As far as I know, and correct me if I'm wrong, MXNet is supposed to be a > very fast, if not the fastest, dl framework. I mean in raw performance > numbers. > > Would you mind expanding on what you mean? I'm genuinely interested. > > Best, > Edison Gustavo Muenz > > On Mon 18. Feb 2019 at 17:28, epsund...@gmail.com > wrote: > > > The rust crate for tensorflow support only inference, which limit its > > usage. If you really want to deploy your network, TensorRT and TVM may be > > better choice. > > > > I really want to write a dl framework in rust from scratch. However, > > there's no mature GPU Tensor library in rust (rust-ndarray is a great crate > > but it only support CPU. arrayfire may support ND array in the future, > > which is a good candidate). So I have to write bindings for existing > > project, which is much easier. .The benefit is that I can safely wrap those > > unsafe C pointer, and with the help of generic, I can manipulate data with > > ndarray in a type-safe way. > > > > The only difficulty is that I'm a postgraduate and I'm pretty sure my boss > > won't be happy to see me writing rust code instead of doing research. > > Besides, mxnet is somehow slower than pytorch, even with hybridize on, and > > that's why I start writing binding for pytorch now. > > > > On 2019/02/09 01:35:04, Zach Boldyga wrote: > > > 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
Re: Rust Client Lib
Hello! > mxnet is somehow slower than pytorch, even with hybridize on, and that's why I start writing binding for pytorch now. I believe many people in this list will be very interested in why you say this. As far as I know, and correct me if I'm wrong, MXNet is supposed to be a very fast, if not the fastest, dl framework. I mean in raw performance numbers. Would you mind expanding on what you mean? I'm genuinely interested. Best, Edison Gustavo Muenz On Mon 18. Feb 2019 at 17:28, epsund...@gmail.com wrote: > The rust crate for tensorflow support only inference, which limit its > usage. If you really want to deploy your network, TensorRT and TVM may be > better choice. > > I really want to write a dl framework in rust from scratch. However, > there's no mature GPU Tensor library in rust (rust-ndarray is a great crate > but it only support CPU. arrayfire may support ND array in the future, > which is a good candidate). So I have to write bindings for existing > project, which is much easier. .The benefit is that I can safely wrap those > unsafe C pointer, and with the help of generic, I can manipulate data with > ndarray in a type-safe way. > > The only difficulty is that I'm a postgraduate and I'm pretty sure my boss > won't be happy to see me writing rust code instead of doing research. > Besides, mxnet is somehow slower than pytorch, even with hybridize on, and > that's why I start writing binding for pytorch now. > > On 2019/02/09 01:35:04, Zach Boldyga wrote: > > 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
The rust crate for tensorflow support only inference, which limit its usage. If you really want to deploy your network, TensorRT and TVM may be better choice. I really want to write a dl framework in rust from scratch. However, there's no mature GPU Tensor library in rust (rust-ndarray is a great crate but it only support CPU. arrayfire may support ND array in the future, which is a good candidate). So I have to write bindings for existing project, which is much easier. .The benefit is that I can safely wrap those unsafe C pointer, and with the help of generic, I can manipulate data with ndarray in a type-safe way. The only difficulty is that I'm a postgraduate and I'm pretty sure my boss won't be happy to see me writing rust code instead of doing research. Besides, mxnet is somehow slower than pytorch, even with hybridize on, and that's why I start writing binding for pytorch now. On 2019/02/09 01:35:04, Zach Boldyga wrote: > 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
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 > > >
Re: Rust Client Lib
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
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
Great response Carin. Just wanted to chime in and say, while the amount of work shouldn't be underestimated to maintain a new language binding, I'd love to see some Rust support. The interop patterns between Rust and C/C++ in particular could make propagating errors a little nicer of an experience. I've also often wished we had a native but memory-safe language that had a binding with MXNet. On Tue, Jan 29, 2019 at 10:13 AM Carin Meier wrote: > Hi Zach, > > I'm the original author of the Clojure package so I can give you my > perspective, (although your path might be different). > > First, one of the advantages that MXNet has of the other deep learning > libraries is its multi-language support. People can program and develop in > the language of their choice. > > The path the Clojure package took is that it originated in an github issue. > From there, the main package was developed in my personal repo until it got > to a point that I could share it and get feedback from other people in the > Clojure community. Once I felt like it was developed enough, I sent out a > email to the dev list, opened a PR, and drafted up some documentation on > the Design and Architecture as well as the state of things on the wiki > https://cwiki.apache.org/confluence/display/MXNET/MXNet+Clojure. > > After much feedback and review, it was brought in under as a "contrib" > package, where it is spending time stabilizing and generally improving to > the point that it can "graduate". > > It's a long term commitment to bring a new language support in, but it is > very rewarding for both the MXNet project and your language community. > > One valuable piece of feedback that I got on the original PR > https://github.com/apache/incubator-mxnet/pull/11205 that might be > valuable > for you as well to think of, came from Kovas Boguta on higher level > concerns: > > - What will the debug experience be like? How do users track down errors > that happen in the front end Rust code or lower level code? > - What does maintenance look like? How does the Rust API evolve with the > rest of the library? > - How do people learn to use this thing? Is there any easy way to go from > the current MXNet docs to the Rust version. How is the documentation going > to work long term. > > I hope this helps, > Carin > > > > > On Tue, Jan 29, 2019 at 5: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
Hi Zach, I'm the original author of the Clojure package so I can give you my perspective, (although your path might be different). First, one of the advantages that MXNet has of the other deep learning libraries is its multi-language support. People can program and develop in the language of their choice. The path the Clojure package took is that it originated in an github issue. >From there, the main package was developed in my personal repo until it got to a point that I could share it and get feedback from other people in the Clojure community. Once I felt like it was developed enough, I sent out a email to the dev list, opened a PR, and drafted up some documentation on the Design and Architecture as well as the state of things on the wiki https://cwiki.apache.org/confluence/display/MXNET/MXNet+Clojure. After much feedback and review, it was brought in under as a "contrib" package, where it is spending time stabilizing and generally improving to the point that it can "graduate". It's a long term commitment to bring a new language support in, but it is very rewarding for both the MXNet project and your language community. One valuable piece of feedback that I got on the original PR https://github.com/apache/incubator-mxnet/pull/11205 that might be valuable for you as well to think of, came from Kovas Boguta on higher level concerns: - What will the debug experience be like? How do users track down errors that happen in the front end Rust code or lower level code? - What does maintenance look like? How does the Rust API evolve with the rest of the library? - How do people learn to use this thing? Is there any easy way to go from the current MXNet docs to the Rust version. How is the documentation going to work long term. I hope this helps, Carin On Tue, Jan 29, 2019 at 5: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 >
