3 ms·

I'm not exactly sure I'd call those "bindings". If you want an actual compelling competitor to us because we're not a big name, at least look at mxnet. That's m

I'm not exactly sure I'd call those "bindings". If you want an actual compelling competitor to us because we're not a big name, at least look at mxnet. That's more credible. It's incredible that folks insist on this still. Both those frameworks aren't even going to be aiming for any level of integration with the JVM. At least take a look at what makes us different. A big one being: https://github.com/bytedeco/javacpp https://github.com/bytedeco/javacpp We own the whole stack here and integrate pretty deeply. This has lead to some great performance improvements. We aren't just "java bindings" but offering a lot more in one place than the other frameworks. Also: I highly doubt you've even looked at the numbers. We're actually doing pretty well in the rankings: https://twitter.com/fchollet/status/915366704401719296 https://twitter.com/fchollet/status/915366704401719296 We're not #1 but we have an actual user base. I think a lot of our upcoming things like our python bindings where people don't have to "see" java and integrations with spark will win over some folks at big companies..maybe not DL researchers which is also fine. Our upcoming api will be like pytorch though. Regardless: I'm not sure the framework will matter long term given that model import and things like ONNX are becoming more common. Finally, I'll just say this: It doesn't hurt the ecosystem to have more competition and different interests than research. Every single person who says this usually dismisses us for 1 silly reason or another ranging from: 1. Not a "big name" (despite being put in production by a ton of them) 2. Not a lot of research papers (yeah no crap we're not a research framework, we do have publications though!) 3. They see java bindings and can't tell the difference between a full application suite and a tensor lib with java bindings generated by SWIG 4. Usually a PHD student at a university who hasn't worked at a large company and doesn't understand my actual target audience

albertzeyer 9y ago
It sounds like you got a bit angry because of my comment? Sorry, I didn't meant to mean it negative in any way, esp nothing negative about DL4J. I just thought that it might be a good contribution to the discussion to have a more complete overview of the DL options in Java, as it was not mentioned here. Of course, there are advantages and disadvantages for each. E.g. TensorFlow might be more well-known but its Java bindings are lacking a lot of the tools which you have in the Python bindings. Also, despite the programming language, each framework underlying design has its advantages and disadvantages. I know some people / companies who do the research and training in Python with TensorFlow and in production for inference they use the Java bindings (or C++). That works quite well. Also, competition never hurts.
- agibsonccc 9y ago
  Oh no problem! I guess what I was getting at with my reply. We get dismissed all the time by the folks doing research (understandly, they wouldn't use us) I guess what I was elaborating on (partially for clarity of other readers who really don't know the difference, partially as a response to your comment here) was the fact that they really are very different things. My problem with these things being posted as "alternatives" is: deep learning is just 1 part of the suite. When you want to do anything with these other frameworks, usually python is somewhere in your workflow. That isn't my only complaint though: Dl4j "the deep learning framework" is 2 parts. Nd4j (the tensor library directly comparable to TF/mxnet,..) and dl4j the deep learning DSL which is higher level like keras. As for your point about folks using C++/Java bindings: Even "production" ends up being nuanced there. TF has different deployment modes with almost no out of the box tooling for very common deployment scenarios. That includes things like kafka, spark,.. We take an angular js like approach to this. Rather than have deployment as an exercise left to the reader, you get imports from different frameworks, a clear way of doing everything from ETL to setting up a server, and a way of actually debugging/controlling things from the JVM rather than using some SWIG bindings with a black box. For example, our tensor library has deep integrations with the java gc which allows reference collecting as well as in java memory management system for cpu and gpu all for handling management on the gpu. You need to control those things if you say: run things on a tomcat server. You don't get that granularity when just deploying some c++ bindings. There's a reason I emphasize having the full runtime tooling available to you (not just integrations). So yes: In general when I see someone just off hand pitching these things, I clarify it. As I said in my previous comment: A whole application suite is a very different approach than a "tensor lib with autodiff and some java bindings". People have different use cases and different requirements. I'd at least like a fair comparison side by side though..

albertzeyer 9y ago

It sounds like you got a bit angry because of my comment? Sorry, I didn't meant to mean it negative in any way, esp nothing negative about DL4J. I just thought that it might be a good contribution to the discussion to have a more complete overview of the DL options in Java, as it was not mentioned here. Of course, there are advantages and disadvantages for each. E.g. TensorFlow might be more well-known but its Java bindings are lacking a lot of the tools which you have in the Python bindings. Also, despite the programming language, each framework underlying design has its advantages and disadvantages. I know some people / companies who do the research and training in Python with TensorFlow and in production for inference they use the Java bindings (or C++). That works quite well. Also, competition never hurts.

agibsonccc 9y ago
Oh no problem! I guess what I was getting at with my reply. We get dismissed all the time by the folks doing research (understandly, they wouldn't use us) I guess what I was elaborating on (partially for clarity of other readers who really don't know the difference, partially as a response to your comment here) was the fact that they really are very different things. My problem with these things being posted as "alternatives" is: deep learning is just 1 part of the suite. When you want to do anything with these other frameworks, usually python is somewhere in your workflow. That isn't my only complaint though: Dl4j "the deep learning framework" is 2 parts. Nd4j (the tensor library directly comparable to TF/mxnet,..) and dl4j the deep learning DSL which is higher level like keras. As for your point about folks using C++/Java bindings: Even "production" ends up being nuanced there. TF has different deployment modes with almost no out of the box tooling for very common deployment scenarios. That includes things like kafka, spark,.. We take an angular js like approach to this. Rather than have deployment as an exercise left to the reader, you get imports from different frameworks, a clear way of doing everything from ETL to setting up a server, and a way of actually debugging/controlling things from the JVM rather than using some SWIG bindings with a black box. For example, our tensor library has deep integrations with the java gc which allows reference collecting as well as in java memory management system for cpu and gpu all for handling management on the gpu. You need to control those things if you say: run things on a tomcat server. You don't get that granularity when just deploying some c++ bindings. There's a reason I emphasize having the full runtime tooling available to you (not just integrations). So yes: In general when I see someone just off hand pitching these things, I clarify it. As I said in my previous comment: A whole application suite is a very different approach than a "tensor lib with autodiff and some java bindings". People have different use cases and different requirements. I'd at least like a fair comparison side by side though..