Question

I don’t Java much.

I am writing some optimized math code and I was shocked by my profiler results. My code collects values, interleaves the data and then chooses the values based on that. Java runs slower than my C++ and MATLAB implementations.

I am using javac 1.7.0_05
I am using the Sun/Oracle JDK 1.7.05

There exists a floor function that performs a relevant task in the code.

1. Does anybody know of the paradigmatic way to fix this?

2. I noticed that my floor() function is defined with something called StrictMath. Is there something like -ffast-math for Java? I am expecting there must be a way to change the floor function to something more computationally reasonable without writing my own.

   public static double floor(double a) {
       return StrictMath.floor(a); // default impl. delegates to StrictMath
   }
   

Edit

So a few people suggested I try to do a cast. I tried this and there was absolutely no change in walltime.

private static int flur(float dF)
{
    return (int) dF;
}

413742 cast floor function

394675 Math.floor

These test were ran without the profiler. An effort was made to use a profiler but the runtime was drastically altered (15+ minutes so I quit).

Answer 1

Here’s a sanity check for your hypothesis that the code is really spending 99% of its time in floor. Let’s assume that you have Java and C++ versions of the algorithm that are both correct in terms of the outputs they produce. For the sake of the argument, let us assume that the two versions call the equivalent floor functions the same number of times. So a time function is

t(input) = nosFloorCalls(input) * floorTime + otherTime(input)

where floorTime is the time taken for a call to floor on the platform.

Now if your hypothesis is correct, and floorTime is vastly more expensive on Java (to the extent that it takes roughly 99% of the execution time) then you would expect the Java version of the application to run a large factor (50 times or more) slower than the C++ version. If you don’t see this, then your hypothesis most likely is false.

---

If the hypothesis is false, here are two alternative explanations for the profiling results.

1. This is a measurement anomaly; i.e. the profiler has somehow got it wrong. Try using a different profiler.

2. There is a bug in the Java version of your code that is causing it to call floor many, many more times than in the C++ version of the code.