5 ms·
This is super. Fwiw, Java and Scala aren't bad for numerical computing either: http://nd4j.org/ http://nd4j.org/ https://github.com/deeplearning4j/nd4j/ https:/
by vonnik 11y ago
This is super. Fwiw, Java and Scala aren't bad for numerical computing either: http://nd4j.org/ http://nd4j.org/ https://github.com/deeplearning4j/nd4j/ https://github.com/deeplearning4j/nd4j/
- namelezz 11y agoHow is nd4j compared to Breeze and jblas, which are used in Spark MLlib[1]? [1] - http://spark.apache.org/docs/latest/mllib-data-types.html http://spark.apache.org/docs/latest/mllib-data-types.html
- vonnik 11y agoND4J supports n-dimensional arrays, while Breeze does not. jblas is great but it's not fast enough. We've relied on netlibblas in the past, and we're moving to faster computation libs now. We'd love for Spark MLlib to plug into ND4J at some point.
- agibsonccc 11y agoSee my post here: https://news.ycombinator.com/edit?id=11275071 https://news.ycombinator.com/edit?id=11275071 We have this concept of a backend where we had net lib java and jblas, but both are horribly slow/limited and need some updating which is why we added our approach to this. If a new matrix framework comes out, I will just write a backend for it and allow people to keep the same dsl. Breeze also isn't usable from java: http://stackoverflow.com/questions/27246348/using-breeze-from-java-on-spark-mllib http://stackoverflow.com/questions/27246348/using-breeze-fro... FWIW, we also support both row and column major (you can specify the data as well as ordering) very similar to numpy. If you come use nd4j, it will mainly be for a dsl that encourages vectorization just like any other numerical language.
- noobermin 11y agoJava certainly has obtained a bad reputation in the sciences, however.
- vonnik 11y agoJust curious: Why is that?
- elcritch 11y agoHaving done both Java and scientific programming I'd mostly say that the verbosity of Java really distracts away from the task of writing scientific code. An academic really doesn't usually care to learn about singletons and classes to write really fast for-loops. Also while the speed of Java now is awesome, floating point performance is key for those scientists who do know more systems level programming (memory management is a big issues). Actually GC in Julia can be a pain also.
- agibsonccc 11y agoWhich is why a c++ underbelly is so important. The computations shouldn't happen at the java level if a scientific lib is being done right. I'd say scala isn't a bad alternative to that (which we have nd4s which is a wrapper over nd4j)
- tanlermin 11y agoUgh. But in julia, its written in julia. There are even julia native tensor and matrix ops.
- noobermin 11y agoI have a passing knowledge of Julia (I've written a simple Lorentz Force[0] stepper in it) is there a way to avoid GC in the middle of the calculation, ie., a performance critical loop or other? [0] https://github.com/noobermin/jelo https://github.com/noobermin/jelo
- ffriend 11y agoYou can turn garbage collection on and off using `gc_enable` function.
- ubasu 11y agoYou 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 agoFWIW, 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.