As announced with the M1 change, we will be renamespacing to org.eclipse.deeplearning4j. In light of the upcoming change we will also be moving the framework to 1.0.0.
New features will of course continue to be added, but the core features we were hoping for the 1.0 have been added recently including:
- Better model import with allowance for extensions. This can be seen here:
deeplearning4j/GlobalAveragePooling.kt at master · eclipse/deeplearning4j · GitHub
This means missing ops if needed can be expressed by the user in terms of samediff ops which already should support anything you would like to build
Spark 3 support: a lot more can be done here, but the versions have been updated in place. A more comprehensive overhaul is due. The framework may migrate to horovod for our distributed training but more research needs to be done in this direction.
More transparency of what is being executed in c++: we’ve substantially improved the logging and validation when using cudnn, onednn, and armcompute: armcompute,cudnn platform checks are re-written, re-write is_callable to workaround for gcc sfinae bug by quickwritereader · Pull Request #9442 · eclipse/deeplearning4j · GitHub
Keras import layers added including deconv3d: Add deconvolution 3d for import by agibsonccc · Pull Request #9399 · eclipse/deeplearning4j · GitHub
Better support for the jetson nano: in our upcoming push to become a better runtime to deploy models we’ve improved support for the jetson nano including publishing updated cuda bindings with first class CI support for the nano now. deeplearning4j/build-deploy-linux-cuda-10.2-arm64.yml at master · eclipse/deeplearning4j · GitHub
Our last big remaining change will be to add better support for modular nd4j binaries. Currently, the binaries are fairly large. Our code base has for a while had a proof of concept of way of picking which operations you would like to include in the code base. We introduce a new -o operations flag to the libnd4j code base allowing you to specify which ops you would like to include. You can see the finished work for that here: WIP: enable selective include of operations to minimize binary size by agibsonccc · Pull Request #9443 · eclipse/deeplearning4j · GitHub
As an addendum to this, we will also be allowing selective data type inclusion as well.
All of these factors will give users the ability to pick and choose what they need to support for their use case dramatically improving the binary size for users trying to deploy on mobile devices or edge devices.
Better model zoo support. Leveraging the new model import framework, it will be much easier to support new models leveraging import from various ecosystems.
Training/updates of models in other frameworks. If you want to import and retrain a model, we will implement minimal support for reusing an existing model file and updating the parameters in place. Obviously model export is preferred , but that will require some more work. The stubs for export have been put in place in the new model import framework. All of the mapping rules in the framework have an apply process reverse that will eventually allow you to reverse an import process.
With the new model import framework, we already allow model import to be described in terms of rules. Allowing users to describe mapping rules in terms of rules can be found here:
Better graalvm support: Javacpp (which underpins a lot of what we do) has fairly extensive support for graalvm. Internally, we’ve been testing graalvm support for a while and have it pretty well under control allowing binaries to be compiled to c and even used from cython.
A new ETL framework: we’re aware of the concerns around datavec and will introduce a new ETL framework in the coming months that should be a much better user experience for java developers.
There are a lot of other ideas we have in the pipeline, but this is just what’s already in the works or already have some work towards it done.