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 <z...@scalabull.com> 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 <z...@scalabull.com> 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 <chenhy12...@gmail.com> 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 <pedro.larroy.li...@gmail.com> 于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 <z...@scalabull.com>
> >> 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
> >> >
> >>
> >
> 

Reply via email to