https://github.com/deeplearning4j/jumpy

The hope here is to be able to "meet" the python frameworks here and run side by side benchmarks that anyone who only knows TF could do.

For those that don't know: DL4j is somewhere in between keras and TF flexibility wise.

Samediff will be a bit "closer" to what people in python see/understand.

The goal there is to import models from different frameworks and run them in production.

Also looking at https://deeplearning4j.org/keras

Could you have documentation which is helpful for the rest of us that use Linux ? Your choice of using docker is brilliant and hope that you make it significantly commandline driven and especially for GPU (nvidia-docker or something). Currently your documentation is extremly dependent on Kitematic and such.

I am not target data scientists. Granted, we will have python bindings later, but there's a huge amount of data engineers that know java just fine and need it for production. That's who I'm going after here.

You could try again when we have our python bindings out there..for now just wait I guess?

Same here. @agibson and crew are amazing and they've helped me numerous times over the past year or so.

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

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

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

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.

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..