3

I do mostly some numerical/physical simulations in C/Fotran/numpy and I use Java (especially Processing and jMonkey ) just to get some real-time interactivity during prototyping of code.

Recently I've read about new features of Java 8, namely:

  • Lambda expressions (watching this video )
  • proposed support of parallelism, heterogeneous computing ( GPGPU, OpenCL ) called sumatra project

To me it seems a bit contradictory - Functional programing and numerical performance. Maybe it is just my naieve prejudice.

Typical argument is like:

Functional style declarations make the code easier to paralelize and give compiler greater optimization oppurtinities than strictly sequential loops and mutable data types

OK, in theory it make sense, but in practice it seems that common Number-Crushing operations are much slower in functional programing languages like haskell, Erlang, Clojure and List than in imperative languages like C or Java. Probably this has something to do with the fact that you pay a lot of operations for abstraction - the functional constructs are just too far from machine code and how processors works. That's why I was never interested in functional programing.

So my question is:

  • what to expect from functional programing in Java 8. Should I care and try to learn if my area of interest is performance critical numerical code?
  • Is there, or is there not a performance penalty for using functional constructs instead of normal imperative code with loops ? ( I mean in simple tasks, like testing of prime numbers, or computing dot_product )
Prokop Hapala
  • 2,424
  • 2
  • 30
  • 59

2 Answers2

1

  1. Java 8 brings some nice and concise syntax constructions, generic and reliable, but not very functional and not magically fast streaming execution / parallelization framework. But it doesn't have really significant JIT compilation, inlining improvements which could be useful for number-crushing code. For example, Java 7's anonymous classes are much more ugly than lambdas, but not slower.

    So the answer to your question: no, if your was not interested in Java 7 and performance, not coding convenience is the concern.

  2. In simple enough cases, when the code is very hot, probably with JVM flags changed for deeper inlining, ideally, there is no penalty. But otherwise there is some (not big though) penalty. Even when JIT does perform inlining, it doesn't fold the machine code flawlessly in most cases.

Value types proposal promises to be much more interesting for number crushing, but it's hard to say when it will appear in Java (if any).

Community
  • 1
  • 1
leventov
  • 14,760
  • 11
  • 69
  • 98
0

I've found that the new functional features are not the most optimized way to do things but a way to breath more life to the aging Java language. In fact, I try to avoid functional syntax in my working environment until code quality tools and such are generally able to parse it.

Using functional features is nice, but why not choose a language that is functional to begin with, like Scala. Or at least something a bit more modern than Java, like Ruby.

Of course the new syntax is nice, but still it feels like writing yaml inside an XML file. It in itself looks good but also a bit ridiculous, when everything around it is old style.