3 ms·

You seem to be conflating "numerical computing" with machine learning. However, numerical computing typically involves solving PDEs via e.g. finite elements or

by ubasu 11y ago

You seem to be conflating "numerical computing" with machine learning. However, numerical computing typically involves solving PDEs via e.g. finite elements or finite differences, or solving large systems of linear equations associated with such methods. The difference between the two is that when solving PDEs, accuracy is paramount, so even using single precision is a bit of a compromise, whereas in machine learning, the trend seems to be to use half-precision or lower, sacrificing accuracy for speed. For classical numerical computing, e.g. solving PDEs or linear equations, Java may not be the best choice, e.g. see the following paper: How Java's Floating Point Hurts Everyone Everywhere: https://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf https://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

agibsonccc 11y ago
FWIW, we use blas just like matlab,numpy,r, and julia. The speed depends on the blas implementation. Nd4j has a concept of "backends". Nd4j backends allow us to sub in different blas implementations as well as different ways of doing operations. We have a data buffer type that allows people to specify floating point or double. Those data buffers then have an allocation type that can be javacpp pointers,nio byte buffers (direct/offheap) or normal arrays We are also currently working on surprassing the jvm's memory limits ourselves via javacpp's pointers. That allows us to have 64 bit addressing which people normally have access to in c++. Every current jvm matrix lib that uses net lib java or jblas is going to have problems with jvm communications as well. The reason for this is passing around java arrays and byte buffers is slower than how we handle it which is via passing longs (raw pointer addresses) around that are addressed via unsafe or allocated in jni where we retain the pointer address directly. We expose that to our native operators. We are solving this by writing our own c++ backend called libnd4j that supports cuda as well as normal openmp optimized for loops for computation. We also offer a unified interface to cublas and cblas (which is implemented by openblas as well as mkl) FWIW, I more or less agree with you, but it doesn't mean it shouldn't exist. JVM based environments can bypass the jvm just like python does now. The fundamental problem with the jvm is no one just took what works on other platforms and mapped the concepts 1 to 1. Our idea with nd4j is to not only allow people to write their own backends, but also provide a sane default platform for numerical computing on the jvm. Things like garbage collection shouldn't be a hindrance for what is otherwise a great platform for bigger workloads (hadoop,spark,kafka,..) In summary, we know the jvm has been bad till now - it's our hope for fixing that.
- tjl 11y ago
  Looking at it, I don't see anything dealing with sparse matrices or factorization (e.g., LU, QR, SVD). All the Java libraries for SVD are pretty bad. Plus, none of your examples mention double precision. Does the library support it? I find it interesting in the Numpy comparison no mention of the BLAS Numpy is linked to is mentioned, but it is for Nd4j. Numpy is highly dependent on a good BLAS and the basic Netlib one isn't that great.
  - agibsonccc 11y ago
    Those are implemented by lapack as part of an nd4j backend. Yes we have double precision - we have a default data type with the data buffer. If you're curious how we do storage: https://github.com/deeplearning4j/nd4j/blob/master/nd4j-buffer/src/main/java/org/nd4j/linalg/api/buffer/BaseDataBuffer.java https://github.com/deeplearning4j/nd4j/blob/master/nd4j-buff... We have allocation types and data types. Data types are double/float/int (int is mainly for storage) Allocation types are the storage medium which can be arrays,byte buffers or what have you. If you have a problem with the docs - I highly suggest filing an issue on our site: https://github.com/deeplearning4j/nd4j/issues https://github.com/deeplearning4j/nd4j/issues We actually appreciate eedback like this thank you. For net lib java, it links against any blas implementation you give it. It has this idea of a JNILoader which can dynamically link against the fallback blas (which you mentioned) or typically openblas or mkl. The problem there can actually be licensing though. The spark project runs in to this: https://issues.apache.org/jira/browse/SPARK-4816 https://issues.apache.org/jira/browse/SPARK-4816 If we don't mention on the site, it's probably because we haven't thought about it or haven't gotten enough feedback on something. Unfortunately, we're still in heavy development mode. FWIW, we have one of the most active gitter channels out there. You can come find me anytime if you're interested in getting involved.
    - tavert 11y ago
      Lapack doesn't implement any sparse linear algebra. If you think the landscape of "Java matrix libraries" is fragmented, when really they're all just different takes on wrapping Blas and Lapack or writing equivalent functionality in pure Java, wait until you look into sparse linear algebra libraries. There's no standard API, there are 3ish common and a dozen less common different storage formats, only one or two of these libraries have any public version control or issue tracker whatsoever, licenses are all over the map. The whole field is a software engineering disaster, and yet it's functionality you just can't get anywhere else.

by ubasu 11y ago

agibsonccc 11y ago

FWIW, we use blas just like matlab,numpy,r, and julia. The speed depends on the blas implementation. Nd4j has a concept of "backends". Nd4j backends allow us to sub in different blas implementations as well as different ways of doing operations. We have a data buffer type that allows people to specify floating point or double. Those data buffers then have an allocation type that can be javacpp pointers,nio byte buffers (direct/offheap) or normal arrays We are also currently working on surprassing the jvm's memory limits ourselves via javacpp's pointers. That allows us to have 64 bit addressing which people normally have access to in c++. Every current jvm matrix lib that uses net lib java or jblas is going to have problems with jvm communications as well. The reason for this is passing around java arrays and byte buffers is slower than how we handle it which is via passing longs (raw pointer addresses) around that are addressed via unsafe or allocated in jni where we retain the pointer address directly. We expose that to our native operators. We are solving this by writing our own c++ backend called libnd4j that supports cuda as well as normal openmp optimized for loops for computation. We also offer a unified interface to cublas and cblas (which is implemented by openblas as well as mkl) FWIW, I more or less agree with you, but it doesn't mean it shouldn't exist. JVM based environments can bypass the jvm just like python does now. The fundamental problem with the jvm is no one just took what works on other platforms and mapped the concepts 1 to 1. Our idea with nd4j is to not only allow people to write their own backends, but also provide a sane default platform for numerical computing on the jvm. Things like garbage collection shouldn't be a hindrance for what is otherwise a great platform for bigger workloads (hadoop,spark,kafka,..) In summary, we know the jvm has been bad till now - it's our hope for fixing that.

tjl 11y ago
Looking at it, I don't see anything dealing with sparse matrices or factorization (e.g., LU, QR, SVD). All the Java libraries for SVD are pretty bad. Plus, none of your examples mention double precision. Does the library support it? I find it interesting in the Numpy comparison no mention of the BLAS Numpy is linked to is mentioned, but it is for Nd4j. Numpy is highly dependent on a good BLAS and the basic Netlib one isn't that great.
- agibsonccc 11y ago
  Those are implemented by lapack as part of an nd4j backend. Yes we have double precision - we have a default data type with the data buffer. If you're curious how we do storage: https://github.com/deeplearning4j/nd4j/blob/master/nd4j-buffer/src/main/java/org/nd4j/linalg/api/buffer/BaseDataBuffer.java https://github.com/deeplearning4j/nd4j/blob/master/nd4j-buff... We have allocation types and data types. Data types are double/float/int (int is mainly for storage) Allocation types are the storage medium which can be arrays,byte buffers or what have you. If you have a problem with the docs - I highly suggest filing an issue on our site: https://github.com/deeplearning4j/nd4j/issues https://github.com/deeplearning4j/nd4j/issues We actually appreciate eedback like this thank you. For net lib java, it links against any blas implementation you give it. It has this idea of a JNILoader which can dynamically link against the fallback blas (which you mentioned) or typically openblas or mkl. The problem there can actually be licensing though. The spark project runs in to this: https://issues.apache.org/jira/browse/SPARK-4816 https://issues.apache.org/jira/browse/SPARK-4816 If we don't mention on the site, it's probably because we haven't thought about it or haven't gotten enough feedback on something. Unfortunately, we're still in heavy development mode. FWIW, we have one of the most active gitter channels out there. You can come find me anytime if you're interested in getting involved.
  - tavert 11y ago
    Lapack doesn't implement any sparse linear algebra. If you think the landscape of "Java matrix libraries" is fragmented, when really they're all just different takes on wrapping Blas and Lapack or writing equivalent functionality in pure Java, wait until you look into sparse linear algebra libraries. There's no standard API, there are 3ish common and a dozen less common different storage formats, only one or two of these libraries have any public version control or issue tracker whatsoever, licenses are all over the map. The whole field is a software engineering disaster, and yet it's functionality you just can't get anywhere else.