Suitability of Java for computational physics, as compared with C or F

[thecommexokid]

I have recently begun physics graduate school. My own programming background is in Java, but I haven't done much computational physics of a caliber that required me to implement things *well*.

My research advisor states that most of the numerical simulation that takes place in our field (quantum gravity) is written in C or FORTRAN. He doesn't know whether this is because the researchers are all old and crotchety and therefore don't use Java simply because it's too new-fangled, or if there are legitimate disadvantages to programming numerical physics in Java. He asked me to look into it, because far more incoming students these days seem to know Java than know C or FORTRAN.

Some specific questions I have:

1. What good scientific computing libraries are there for Java? Are there good libraries implementing things like Runge–Kutta, LU decomposition, and other common algorithms of typical numerical techniques?

2. Java doesn't have in-built support for complex variables or true multidimensional matrices. How much of a problem is this? What are the workarounds, and how good are they?

3. Then there's the obvious question of speed. I know that just-in-time compilation has been getting better and better, but I'm sure that running on the JVM must still have a cost compared to compiled machine code.

Please share any thoughts, or direct me to good places where this topic may have been discussed before. Thank you very much.

 

[phyzguy]

Try writing a simple routine to do a large number of numerical computations, like a loop that squares a million numbers, or takes the sine of a million random numbers, and time how long they take. Or better yet, take the sine of two random numbers and have an if statement that tests whether sin(a) > sin(b), then run that loop a million times. This will include comparisons as well as arithmetic. I predict that you will find that C or Fortran is hundreds of times faster than Java. This was the case when I compared Python to C. But I could be wrong...

 

[lpetrich]

Here is a site that has some tests: Computer Langauge Benchmarks Game

C, C++, and Fortran are about the same speed. Java is somewhat slower, but not much slower. That's likely due to its Just In Time (JIT) compilation.

Python is about 20 times slower on average, and Perl and Ruby are similar. However, those languages tend to need much less coding than C, C++, Fortran, and Java.

There's a *lot* of variation, however.

 

[harborsparrow]

I predict that you will find that C or Fortran is hundreds of times faster than Java. This was the case when I compared Python to C. But I could be wrong...

This may once have been true, and was for a long time alleged, but it is no long true. Java (and its sister languages such as VB.NET and C#.NET) have had their compilers so optimized that they run about as fast as "native" code created by C++ or C compilers, with a tiny (really imperceptible) cost at load time for the first compilation of the code. Read about "just in time compilation" in Wikipedia, or somewhere, to learn some of how that is done.

Python, OTOH, is often still implemented largely as a more purely interpreted language, and is generally much slower than Java or C#. Java and C# have been optimised heavily to work in huge, enterprise software systems. Thus, performance is not a reason not to use them. A lack of numerical libraries *might* be a reason, and I cannot speak on that matter.

I can also say, that if you are writing from scratch, the addition of type safety to Java and C# makes them a very good choice for numerical programming. No matter how experienced a person is, when writing a large wad of numerical code in C or C++, it is still awfully easy to introduce a memory leak or cause a segmentation fault, and despite ANSI standards, there are still issues with portability of C and C++ code across operating systems.

I do know, however, that as a physicist you will need to become competent in C and C++, and all the pain associated with their LACK of type safety, at some point anyway. You should not avoid doing that learning curve because you'll likely encounter a whole bunch of legacy physics code already written in those damnable languages. But if you already know that, then by all means (unless lack of libraries or another cause is prohibitive), give yourself the luxury of using a more modern language such as Java that fixed some of the problems inherent in ancient C and C++, namely, making it nearly impossible for you to have a memory leak or a segmentation fault.

I am not a physicist. I am a computer scientist who specialized in computer architecture and did a lot of programming in C and C++ way back, and have had to do a certain amount of numerical code upon occasion (though I don't love it). I'm married to a physicist and I've seen him wrestle with numerical code, including (once) when he had to translate a huge wad of code from Fortran into C. What made that tricky was that Fortran and C stored arrays internally in a different manner.

There is also a cultural issue. A physicist may be discouraged by their own colleagues from branching out to a new language. This can be healthy, or unhealthy. New languages do cost investment and learning time, but in some cases, especially if starting code from scratch, it might well be worth it. But the misperception about performance, a matter which levelled out years ago, is an example of a case where physics folks may not have been exposed to advances in computing technology.

 

[harborsparrow]

BTW, if you know enough, you can easily call libraries written in C or C++ from within a C# program. C# is very, very similar to Java, has all Java's advantages over C, and probably runs even faster. Also, there is a good implementation of C# available on Linux systems now. Having used both Java and C# extensively, I still favor C#. It came along somewhat later than Java and was able to improve upon certain issues in Java that had emerged after it had been used for several years, such as the string comparison pitfall. And Microsoft made it easy to call legacy libraries from within C#.

 

[SteamKing]

Your research advisor seems to have been born yesterday. There is a lot of legacy code out there which can be reused in newer C and Fortran programs, but which would have to be re-written just to program in Java. It's not just code for a particular simulation, but also code for numerical methods (e.g., solving large systems of linear equations), data input generation (for things like mesh descriptions), and analysis of results (plotting, etc.)

Some simulations are also very computationally intensive, requiring hours of expensive time to run on supercomputers. A compiled program can be executed immediately on such machines without lost time due to JIT compilation.

 

[harborsparrow]

Ahem. Java and C# programs can be precompiled. But even if they are JIT compiled, the code "warms up" as soon as all code has executed a single time, so precompiled code is cached as native code in memory. Thus after the first second or two, all the computation is being done as native code. There is not a significant performance loss in numerical computation in Java per se.

The library issue seems to be the one that really matters here. The question is whether existing libraries can be called from within the newer languages. I think that they can.

 

[phyzguy]

Here is a site that has some tests: Computer Langauge Benchmarks Game

C, C++, and Fortran are about the same speed. Java is somewhat slower, but not much slower. That's likely due to its Just In Time (JIT) compilation.

Python is about 20 times slower on average, and Perl and Ruby are similar. However, those languages tend to need much less coding than C, C++, Fortran, and Java.

There's a *lot* of variation, however.

Well, for example, I'm running n-body codes as part of my physics research, which I think is the kind of thing the OP was asking about. If I look at these benchmarks, Java is running 3.1X slower than C on the n-body code. Maybe in your book this counts as "somewhat slower, but not much slower", but to me 3X is a whole lot slower. The impact on your research program between getting a new result every day and getting one every three days is huge. While progress has clearly been made, it looks to me like Java is still not fast enough for real number crunching applications.

 

[lpetrich]

(quote of my post on benchmarks...)

Well, for example, I'm running n-body codes as part of my physics research, which I think is the kind of thing the OP was asking about. If I look at these benchmarks, Java is running 3.1X slower than C on the n-body code. Maybe in your book this counts as "somewhat slower, but not much slower", but to me 3X is a whole lot slower. The impact on your research program between getting a new result every day and getting one every three days is huge. While progress has clearly been made, it looks to me like Java is still not fast enough for real number crunching applications.

Fair enough.

I was thinking about a factor of 3 as opposed to a factor of 30 or so, what one gets for Python. But Python would be atrociously slow by this sort of standard, I'm sure.

 

[Daverz]

(quote of my post on benchmarks...)
But Python would be atrociously slow by this sort of standard, I'm sure.

Most people doing numerical work with Python will use the numpy library, which is written in C and Fortran.

The speed advantage of numpy depends on how "vectorizeable" the problem is. In those cases where you can't get a speed boost by vectorizing, you can use Cython, a variant of Python that allows type declarations, to compile to C. I've gotten 500X speed boosts with Cython, and it's very easy to use.

For anyone interested in doing scientific work with Python, I suggest checking out some of the videos available from past http://pyvideo.org/category/37/scipy-2013 at pyvideo.org.

 

[phyzguy]

(quote of my post on benchmarks...)

Fair enough.

I was thinking about a factor of 3 as opposed to a factor of 30 or so, what one gets for Python. But Python would be atrociously slow by this sort of standard, I'm sure.

Agreed. Python is clearly a whole lot slower than Java. In my work, what I do is write the wrappers (file handling, plotting, etc.) in Python, then I write subroutines in C for the calculation-intensive parts, which I call from Python. This works pretty well. Some of my co-workers do the same thing, but use Fortran for the number crunching. Clearly you could do the same thing using Java instead of Python, and it would probably be faster still.

 

[crackjack]

Well, for example, I'm running n-body codes as part of my physics research, which I think is the kind of thing the OP was asking about. If I look at these benchmarks, Java is running 3.1X slower than C on the n-body code. Maybe in your book this counts as "somewhat slower, but not much slower", but to me 3X is a whole lot slower. The impact on your research program between getting a new result every day and getting one every three days is huge. While progress has clearly been made, it looks to me like Java is still not fast enough for real number crunching applications.

I am debating with myself on this Java VM versus C/C++ question for a while now. I had also asked a related question at SciComp SE on this (I should have known better than asking it there when the scicomp SE did not even have a 'java' tag).

A 2007 blog post ran some of those benchmarks, but after excluding JVM's warm up times (even though, as you can read from the exchanges with the benchmarks-game guy, Isaac Gouy, in the comments for that blog, this does not matter much apparently), and the results are quite surprising. For the same n-body, for example, a "warmed up" JVM ran faster than the fastest C compiler. Those same exchanges with Isaac Gouy, in the blog's comments, has a good point though: Running 4-5 trials of each benchmark may not be enough to average out processor usage by other processes running on that system.

 

[Svein]

My research advisor states that most of the numerical simulation that takes place in our field (quantum gravity) is written in C or FORTRAN. He doesn't know whether this is because the researchers are all old and crotchety and therefore don't use Java simply because it's too new-fangled, or if there are legitimate disadvantages to programming numerical physics in Java. He asked me to look into it, because far more incoming students these days seem to know Java than know C or FORTRAN.

One specific problem with classic Java is the inability to interact with the physical world. Some years a customer of mine decided to order a program for betting ticket recognition from a big software house in Java (the reason being that "Java is the big thing now"). Sadly, after a couple of weeks the implementer discovered that there was no way for Java to communicate with the scanner driver. So I was asked to create an interface with the scanner driver (I think I wrote it in C, because it was very easy to communicate with the scanner software in C). OK, so I have started the scanner, I have read in the picture, where do you want me to place the data - shared memory, pipe or what? Turned out that the only way to present the data to Java was to place it on an internal web server (which was not trivial in 2001). Needless to say, the project was cancelled.

 

[newjerseyrunner]

I'm confused about something, won't most of your intensive calculations be done inside of libraries anyway? When libraries are ported between languages, they libraries themselves aren't; only the bindings are. OpenGL in Java is just a Java binding to the same C written OpenGL library that I use if I'm writing in C++ directly. The same would be true with most math and physics libraries wouldn't it?

 

[crackjack]

In addition to my earlier reply, let me also pass on what I have been generally told/read over time:

Real world constraints: Given unlimited resources (time, money, access to enough top-skilled programmer etc), a C/C++/FORTRAN program can certainly be tuned to perform better than a similarly tuned Java program. But given the real world constraints along each of those resource dimensions, the distinction becomes blurry, to say the least.

Move to commodity clusters: Java ecosystem is generally more suitable for commodity clouds like AWS, GCE etc (which brings its own sets of advantages like cost, availability etc and disadvantages like network latency etc to many of the traditional HPC tasks) because of fault-tolerance, load balancing frameworks that Java provides. Sure, C++ (not sure about C or FORTRAN) also provides such tools like CAF and Charm++, but Java-based projects like Akka are generally better developed, supported and documented.

Also, as @newjerseyrunner already said, one can always port the bottlenecks to C++ or C or FORTRAN or OpenCL or assembly language or FPGA hardwares or whatever, and call them through Java wrappers like JNI, JNA, BridJ etc. This is what the Java-based Spark does, by calling netlib-java at its core. On this, there is a good report from MITRE on Mixing C and Java for HPC.

 

[D H]

I should have known better than asking it there when the scicomp SE did not even have a 'java' tag.

That should have been a big red flag. While Java is once again the leading programming language (per TIOBE), it has almost no place in scientific computing. There are many good reasons for this.

C has overtaken Fortran in many areas of scientific computing because C is about as fast as Fortran and because it is now very hard to find Fortran programmers. C++ has been overtaking both C and Fortran in scientific computing because it is as fast as both and because it offers things that those other languages don't have such as OOP, operator overloading, type safety, and lazy evaluation. Java would not be a step forward in this regard. Since it lacks operator overloading and (until recently), lazy evaluation, it would be a step backwards. Python has been overtaking C++, C, and Fortran because it's so well-suited to scientific computing, and also because of momentum.

C++ and python offer object oriented programming, when you want it. Both also offers plain old procedural programming when you want it. In Java, you have no choice. Every function is a member of a class in Java. OOP is not a be-all and end-all. In many places in scientific computing, it just gets in the way.

C++ and python also offer lazy evaluation, which can sometimes make an algorithm extremely fast, faster than C or Fortran. Until very recently, this was impossible with Java. It is possible with Java 8, but it is rather difficult to implement and it is computationally expensive.

Python has been growing in popularity in scientific computing because of ease of prototyping, ease of extensibility (pip antigravity at the command line, and from that point on, you can import antigravity), duck typing, operator overloading, not having to declare variables (python doesn't have a mechanism for declaring variables), and many other reasons.Why do you want to step backwards to a language that suffers even more bondage and disciple programming aspects than does C++? That Java is a B&D language is great for Android, where apps absolutely need to behave. (If it wasn't for Android, Java would be a nearly dead language.) In the world of scientific computing, c++ and python represent steps forward. Java does not.The above is my opinion. That it is very hard to find scientific computing projects that use Java indicates that this is not just my opinion.

 

[crackjack]

That should have been a big red flag.
...
That it is very hard to find scientific computing projects that use Java indicates that this is not just my opinion.

I wouldn't read too much into it. That SE community has been in beta, and does not have tags for charm++ or CAF or Julia or fault-tolerance either, none of which means anything about the current/future potential of these tools/languages/concepts in HPC.

Dont mistake me - I am more comfortable with C/C++ environment than JVM's, and looking for reasons to stick with former.

Just to play the devil's advocate here...

CPython seems to be way slower than C/C++/Java (if you consider Numpy/Numba/Cython as wrappers for C code that Java can/already wraps around). It is a good language to prototype, script, visualize etc, all of which can be used even when you develop your core in Java. While we are at this, I would also point out JVM-based languages like Scala etc that have modern language features and tools (REPL notebooks etc).

On lazy evaluation: I just know that both C++ and Java are (or were) inherently strict evaluating languages, that picked up lambdas over time. But I don't know enough about them (performance, ease of use, lazy evaluation, side-effect handling etc) to comment on.

On OOP: Sure it is not a be-all. But it would be very hard to justify developing and maintaining a huge code base (like it often happens in scientific projects) today, without OOP. In fact, since the time I came across Actor Models, I am wondering why the HPC world did not adopt enough of such a natural parallel-computing framework.

 

[mpresic]

Although I have been criticized for programming mainly in FORTRAN rather than modern languages. (I do know a little JAVA, C, and Perl), I still like Fortran for numeric computations and it seems to complete the benchmarks faster, (a lot faster than JAVA). Some of my younger colleagues still use Fortran for numeric computation, but being very skilled, they use these more current languages in areas where they are better suited.

 

[fizzle]

Your item #1 is the most important issue. Are there Java libraries to help you accomplish your goal? If not, that's a *big* problem because you'll spend a lot of time re-implementing C/C++ or FORTRAN code in Java (including extensive debugging and testing of numerical results, which can get tricky in scientific programming). People stick with the existing non-Java code because it's "known" and assumed to produce correct results.

Item #2 would naturally fall out of the library quest in #1.

The only time to worry about item #3 is if you find the resulting Java code is too slow for what you're trying to accomplish. Programmers really get off on showing off their code optimizations ... even if the overall result is insignificant. If your Java code ends up being too slow, slap a profiler on it to find out where the problems are and fix them.

Note: I'm a C/C++ programmer (previously an x86 programmer) but am not "wedded" to the language. If C# or Java gets the job done easier - from a coding perspective - and fast enough - from an execution perspective - that's great. Stick with it.

 

[thecommexokid]

Hey everybody, Not sure why there was such a sudden resurgence in this thread this week, but my original post was more than 2 years ago. By all means keep discussing the topic if you want, but I have already graduated with the Master's degree I was starting out on when I asked the question.

 

[jim mcnamara]

Good for you! Keep on going...

A lot of what you see posted is in this thread is opinion, not fact. DH posted the most reasonable answers. Lots of applications can be written in almost any language. The bottom line is: are there efficient libraries? And can I link to them?

I used to work with a mathematician, Nick Metropolis, in Los Alamos. He realized that publications like 'Numerical Recipes' were not useful - they were aimed at making money. He is the guy behind the the creation of GSL - Gnu Scientific Library.

It is still out there. But once folks got the message they went crazy... R, matlab, alpha Wolfram, and libraries like LAPACK are all available. Some are no cost. R is opensource for example.

 

[jtbell]

Since this thread is no longer relevant to the OP, it is now closed.