2
$\begingroup$

I was looking to brush up and/or pick up some languages for a hobby project on my free Amazon EC2, and I was going through the benchmark results for Java vs C (or Scala vs C)and Fortran vs C. It seems that the margin in Java vs C is nearly the same in Fortran vs C, which made me wonder if JVM (and its JIT optimizations) advances are catching up fast enough to occupy the same status as C & Fortran in High Performance (Scientific) Computing in the near future.

Factors, other than performance, to be taken into consideration could be:

  1. readability, maintainability and expressivity of codes
  2. cost of scalable hardware infrastructure
  3. Availability of libraries
  4. Parallel and/or Concurrent programming support
  5. Talent pool

edited question: Among all high performance computational fields, what are the fields that might see the rise of Java/Scala JVM ecosystem? For example, it seems to me that complex system analysis, economic/finance, machine learning etc might be a few of those fields. What else?

Edited on 24 Sept 2015: After I had posted this question, I came across this old (2007) blog post that re-did some of those same benchmarks-game for Java and C, but after excluding the initial warmup/optimization run (although, its effect is debated) for a few different Java compilers, and the results are quite surprising. Although, as the comments from Isaac Gouy at that blog say, running 4-5 trials for each benchmark may not be enough to average out processor usage by other processes running on that system. But still, an interesting blog. Since that 2007 blog, I believe JRockit and HotSpot compilers have been merged by Oracle, but not sure how their combined performance stacks against C compilers'.

$\endgroup$
  • 1
    $\begingroup$ Why specifically Java? There are many more high-level languages out there, some of them compiled to native code, and Java is only one of them. $\endgroup$ – Kirill Jan 2 '15 at 4:12
  • $\begingroup$ @Kirill I was curious about JVM+JIT mainly because of Scala on it. It seems to be quite an interesting language, with a lot of libraries (including Java's). For my hobby project, I would be implementing lambda calculus, first order probabilistic logic, stochastic boolean satisfiability and a probabilistic graphical model (like a markov random field). So I thought Scala might be better for implementing such a wide range of construct. But I think I will stick with C (some C++) and Python. $\endgroup$ – GuSuku Jan 2 '15 at 21:09
  • 1
    $\begingroup$ None of those are traditional computational science tasks. Also, for a hobby project you'd probably want to prioritize learning new concepts over ready access to existing libraries. This is a very vague question because your criteria for selecting a language are not stated clearly. Why is talent pool a factor in a hobby project? The phrase "some C++" suggests some (?) prejudice against C++, why? C++ is a decent language. So are Haskell and OCaml (they are both really good for learning, so are Scheme/Lisp variants). Sorry, I don't see how this question can ever get a clear useful answer. $\endgroup$ – Kirill Jan 2 '15 at 23:08
  • $\begingroup$ The question was not specific to my project - the question is generic and came up when I was looking up some benchmarks. As for using more of C than C++, it is purely because I think I may be able to implement most of what I need with C+Python, which I am more comfortable with than C++. $\endgroup$ – GuSuku Jan 3 '15 at 0:58
  • 1
    $\begingroup$ C++ is worth learning if you don't already know it well. I don't see what your linked paper has to do with anything: it seems the authors compared a clever algorithm in Java+PostgreSQL with an existing algorithm in C++. That's hardly a comparison of languages, unless you want to claim that higher-level languages allow you to implement more complicated algorithms (which is true but not relevant to the Java-C++ comparison). It makes no sense to ask this kind of question "in general", and when comparing languages you have to specifically say what you are going to use them for. $\endgroup$ – Kirill Jan 3 '15 at 1:49
9
$\begingroup$

Java has been around for almost 20 years now as a major programming language, but it hasn't caught on in scientific computing so far. I think that's a good indicator for what's going to happen in the future.

My take is that the issue isn't speed. Most people are probably willing to give up 20% of performance (or even a factor of 2) if they would be vastly faster in developing their programs. But that doesn't seem to be the case with Java vs C++ (though it is almost certainly true for Java vs Fortran). I would claim that in fact the opposite is the case: because practically all HPC libraries (for linear algebra and finite element methods, in particular) are written in C or C++, using Java would be a major pain since one would have to somehow translate the existing interfaces. For libraries the size of PETSc, Trilinos (or my own project deal.II), this is simply not feasible.

In other words, using Java (or Scala, or whatever other language you have in mind), the burden compared to C++ is huge: you'd either have to write wrappers and interfaces to existing libraries, or you'd have to reimplement the hundreds of thousands of lines of code of existing libraries. Neither sounds like an attractive option.

$\endgroup$
  • $\begingroup$ Yup, Java seems to be tedious and verbose to code while Scala seems to be pleasant. But Java/Scala lack the custom libraries like you say. But for someone starting out in a field where legacy custom lib are not an issue, would you suggest that Scala is worth taking a serious look at, for HPC. $\endgroup$ – GuSuku Dec 31 '14 at 17:23
  • 1
    $\begingroup$ @crackjack: Do you intend to stay in this field for a long period of time? If so, go for it. If not, then any time you spend looking at Scala is lost as soon as you change fields into something where they are an issue. $\endgroup$ – wolfPack88 Dec 31 '14 at 20:15
  • 2
    $\begingroup$ My take is that there are no fields where there are no legacy libraries that can make your life easier. If you're not using them, then you're seriously curtailing your productivity, or you're only dabbling and not doing serious work. If you're into something and want to stick with it for a while, find the libraries everyone is using and use them too -- there are good reasons why everyone is doing so. $\endgroup$ – Wolfgang Bangerth Dec 31 '14 at 20:18
  • $\begingroup$ True, but the abstraction level of those legacy libraries is also a factor. For example, even in Apache Spark, the core netlib-java engine is a java wrapper over C/C++/FORTRAN libraries, but when I said 'a field where legacy custom lib are not an issue', I was referring to those derived C/C++ libraries built over these. When they exist, I often find that their priority for use cases is different than mine. For example, commodity cloud clusters vs supercomputers have different requirements for efficiency and ease-of-implementation of fault tolerance (on node failure). But maybe I am wrong. $\endgroup$ – GuSuku Sep 24 '15 at 19:35
6
$\begingroup$

It seems unlikely to me. The Java MPI APIs haven't been worked on in years (so you're wrong about #4), and the JVM's floating-point performance is notoriously poor. Java may out perform C/C++ or Fortran in some areas due to rapid thread creation and easy memory management, but these aren't the bottlenecks in typical scientific programs.

As to your #5, the availability of lots of Java programmers isn't really all that helpful. I find that good scientific programmers need to understand the science and software engineering. Both aspects are trainable, so you have to spend the time training on either the science or the software engineering to be a good scientific programmer. There are lots of good scientists, too, so the latent talent pools are big enough to eventually supply good scientific programmers from either side.

$\endgroup$
  • $\begingroup$ I am not at all an expert on this, but I thought OpenMPI has Java bindings? Also, are non-MPI options like MapReduce/Yarn/Spark/etc completely out of the equation for HPC? As for #5, I get your point, and have edited my question too. $\endgroup$ – GuSuku Dec 31 '14 at 16:47
  • 2
    $\begingroup$ @crackjack: Huh, the OpenMPI Java bindings are new to me. I have no idea how they perform. They seem like an option. MR/Yarn/Spark do not have the typical low-latency, high-bandwidth communications abilities typically needed by HPC applications. They're fine for certain things, but not likely to allow Java to take over the HPC world. $\endgroup$ – Bill Barth Dec 31 '14 at 16:56
5
$\begingroup$

I would argue that Java will in fact REDUCE productivity when compared with modern c++, or even with modern Fortran for the purpose of scientific computing. Writing

A = B*C+2*D

is just so much more readable than

A = B.mult(C).add(D.mult(2))

Assuming the code above deals with arrays, both C++ and fortran will also produce significantly more efficient code for that example, depending on your library of choice. Scala is a much nicer language, as it will allow a decent syntax, although you will still take the performance hit from creating a a lot of temporary objects.

Neither Java nor Scala have complex data as a primitive type, which means there is a significant overhead when doing computations.

As others have stated, you need a decent interface to C/Fortran libraries for scientific computation.This can be done in Java and Scala, but it is likely to be a massive amount of work.

If you want to learn a "commercial" programming language, and you're using scientific computing as training, I would consider C#, which has a saner syntax for these things.

If you just want to do scientific programming, I would consider learning Julia, as a "get things done fast" language. This will get you faster code than the JVM languages, has excellent plotting support (via python) and is actively developed for scientific computing.

If you wish to learn a new programming paradigm, try F#, as you would still have easy access to the various .NET libraries for scientific computing.

Finally, if you want high performance, C++ is currently far more expressive than Java and has decent parallel support with OMP. Arguably, it also has the best library support of any of the mentioned languages.

That being said, Java is heavily used in finance. Keep in mind that the same is also true of COBOL, which tells you all you need to know about programming in the financial sector.

$\endgroup$
  • 1
    $\begingroup$ All of Jane Street's HFT systems are written in OCaml. Not disputing that the financial industry might be generally behind the times, just not universally. $\endgroup$ – Daniel Shapero Jan 2 '15 at 18:51
  • $\begingroup$ Thats a handful of languages! :) For the time being, I have decided to stick with python & C/C++, which I am more familiar with. Julia does seem interesting, given its features and benchmarks but it is too new. I was curious about JVM performance mainly because of Scala on it. $\endgroup$ – GuSuku Jan 2 '15 at 20:56
  • $\begingroup$ Sorry, didn't mean to imply that all of finance was stuck in 1990, just most of it ;) $\endgroup$ – LKlevin Jan 2 '15 at 21:26
1
$\begingroup$

I'm contributor to a machine-learning library called Deeplearning4j.

We see a fair amount of demand for JVM-based tools from sectors like finance, telecoms, government agencies.

We developed ND4J, which supports n-dimensional arrays for Java and includes a Scala wrapper ND4S.

All the optimizations are in C/C++, but the framework integrates with Hadoop and Spark, and enables them to run on multiple GPUs.

$\endgroup$
  • $\begingroup$ Interesting! Will check it out. By 'optimizations are in C/C++', do you mean like using standard java libraries (like netlib-java) that wraps over standard optimized C/C++/FORTRAN libraries? Or, are you referring to writing custom java wrappers over custom-optimized C/C++ code? $\endgroup$ – GuSuku Sep 24 '15 at 19:05
  • 1
    $\begingroup$ ND4J serves as a Java wrapper on C/C++/Fortran optimizations, but we also did a lot of stuff within Java itself, including writing our own bytecode compiler. ND4J works with what we call backends, which are optimized per chip. So we optimized on Cuda C and have a Jcublas backend for GPUs. Same for x86, etc. nd4j.org/dependencies.html nd4j.org/backend.html nd4j.org/benchmarking Feel free to join us on Gitter with Qs: gitter.im/deeplearning4j/deeplearning4j $\endgroup$ – racknuf Sep 25 '15 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.