I'm rewriting a piece of fortran code to java to improve its maintability but i'm concerned about it's speed. This code doesn't make anything except lots of floating point calculations (electromagnetic fields simulations) and doesn't make heavy memory usages.
Does anyone have experience in such kind of projects? Any advices would be appreciated.
SCJP 6, SCBCD, SCWCD. Making SCEA assignment atm.
Kees Jan Koster
Joined: Mar 31, 2009
Java is so different from Fortran that we cannot help you here. The best route forward is for you to write the code and then optimize it. Don't start optimizing now, you will end up with unmaintainable code and probably not actually gain anything significant.
Performance in Java is not clear-cut. You have the HotSpot compiler that (re)compiles your code at run-time. You have the server JVM (use -server on the command line) and the client JVM (don't use that one). So you won't know the performance by looking at the code. In fact, your code may start running faster the longer it runs. So be *very* careful when you do 2-minute benchmarks to find out what is fast and not.
Just write maintainable code. Once the code is done, get a decent CPU profiler and start locating hotspots in your code and fix those.
I agree with the previous poster. I'd also add if you are concerned about performance create a small program that does the types of calculations your fortran program did and time the performance. I do a fair amount of calculations on doubles in my programs and I am continually surprised by how fast it executes.
Actually, this is a particular sore spot with Java. Java is intended to be "write once, run anywhere", and they take that directive so seriously that even the floating-point calculations and binary serializations should be accurately reproducible.
However, there are a number of different floating-point implementations, depending on the hardware involved. To stay portable, Java dictates the IEEE floating-point representation.
The original IBM System/370 floating point (optional on selected S/360 models) was a rather odd format. So to run IEEE floating point on it, and its descendants, the floating-point hardware had to be totally ignored and the actual floating-point calculations be done totally in software. As a result, although on most benchmarks, Java can often exceed the runtime speeds of native C code, when you add floating-point, it loses badly (C isn't required to be write once, run anywhere so it can use whatever FP resources it wants).
Two mechanisms were provided to compensate for this. For general Java use, there's a modifier that says "Use the machine's native floating-point facilities". That way you can take advantage of the hardware accelerators. For IBM mainframes, the recent crop of z/Series machines added IEEE accelerators alongside their older unique FP hardware.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jun 26, 2002
For general Java use, there's a modifier that says "Use the machine's native floating-point facilities". That way you can take advantage of the hardware accelerators.