The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

double vs float performance in Java?

We have a trading application that does all its floating point calculations using doubles. While reading "Programming Pearls", it occurred to me that we don't need the extra precision of a double and that switching to floats should use less memory and might improve performance.

We aren't doing huge amounts of matrix math, there are probably only a couple hundred floating point operations in our processing of a typical message.

Anyone care to speculate on the performance impacts of this change?

Anyone suggesting that we should be using C++ without some evidence to back it up will be mocked. ;)
Hockey Player Send private email
Thursday, June 26, 2008
 
 
As I see it, you have three options:
1) Use C++.
2) Ask random people on the internet, who may or may not have a clue, to speculate about the hypothetical performance of code that you have described vaguely.
3) Measure it.

Only one of these is a good option.  I'll leave it to you to figure out which.
Michael Gibson Send private email
Thursday, June 26, 2008
 
 
While I haven't got any hard data, it seems to me that the performance difference between a double and a float is probably not nearly as large as the difference between a double and an int. Memory usage may be a factor, but I wouldn't guess there's large speed differences between two floating point data types.
BrotherBeal Send private email
Thursday, June 26, 2008
 
 
3) Mesure it.

'Programming pearls'?
Victor Noagbodji
Thursday, June 26, 2008
 
 
double vs float might be different in a 32 bit system.

I almost want to spend the 15 minutes to test it.
Lance Hampton Send private email
Thursday, June 26, 2008
 
 
> 'Programming pearls'?

A classic and wonderful book by Jon Bentley: http://www.amazon.com/Programming-Pearls-2nd-ACM-Press/dp/0201657880
Hockey Player Send private email
Thursday, June 26, 2008
 
 
> 3) Measure it.

Micro-benchmarks are hard to write in Java, see http://wikis.sun.com/display/HotSpotInternals/MicroBenchmarks

While we obviously aren't going to check-in the switch without a number of performance tests, I was hoping for some advice before we spend the time to convert the entire codebase.

For example, if someone knew the the floating point hardware in modern processors is optimized for doubles or floats, that would be helpful knowledge.
Hockey Player Send private email
Thursday, June 26, 2008
 
 
I don't think the speed will be different but the memory usage will be half.
Jimmy Jones
Thursday, June 26, 2008
 
 
Sounds like a case of premature optimization.  If the current double-based calculations are correct and haven't been giving you grief, why mess with them?
Austinian
Thursday, June 26, 2008
 
 
> Sounds like a case of premature optimization.

This is an arbitrage system; increased speed is directly correlated to increased profit.
Hockey Player Send private email
Thursday, June 26, 2008
 
 
> This is an arbitrage system; increased speed is directly correlated to increased profit.

And you won't mesure it?
Anon
Thursday, June 26, 2008
 
 
Best practice is to use doubles for all calculations.  The memory difference during calculations is minimal, and I don't think single-precision floats are any faster (the floating-point registers on x86 hardware are 80-bit).

You _might_ see some memory benefit from using single-precision floats to store the inputs to and outputs from your calculations, but that depends on how much of your data is made up of this floating-point stuff.  In practice, if your program is using too much memory, you're probably better off improving your data structures, plugging leaks, or upgrading your server, rather than fiddling with primitive type representations.
Iago
Thursday, June 26, 2008
 
 
In a financial trading application, why are you using doubles or floats at all? Shouldn't you be using a scaled integer data type (such as currency or money or similar) or doing your own scaling and integer arithmetic?
Philip Send private email
Thursday, June 26, 2008
 
 
I believe "float" has 8 digits of precision.  "Double" has 16 digits of precision.

So, with a "float", you could have 12,345,678 without losing any precision -- you wouldn't have the '8' rounded up or down, but any larger number than that would require some rounding.

With double, you get: 1,234,567,890,123,456 before you start getting rounding errors in the least significant digit.

I don't know about you, but limiting your system to 99 million dollars and below seems pretty limiting in a financial application.
AllanL5
Thursday, June 26, 2008
 
 
And +1 Phillip -- I thought the usual thing to do in these cases would be some "Fixed Point" format using longs or long-longs.
AllanL5
Thursday, June 26, 2008
 
 
float may actually be SLOWER than double. Modern floating point hardware (like Intel CPU's) use double or better precision internally. Which means that if you feed it floats, it need to convert from single to double, do the calculation, and then convert back.

I agree with the above posters: don't guess, measure. There are so many variables here (CPU hardware, cache size, cache misses based on data arrangement, and a bazillion other things) that the only way to find out is to test it.
Chris Tavares Send private email
Thursday, June 26, 2008
 
 
Thanks Chris, that was helpful.

As I've said on this thread already, we obviously aren't going to check in this change until it has shown improvement on our performance test suite (and passed all the unit tests).  But if this change is unlikely to provide a decent speedup, we have better things to do.
Hockey Player Send private email
Thursday, June 26, 2008
 
 
1) Doubles will be almost exactly as fast as floats. Most languages silently promote all floating point calculation to doubles under the covers, and the CPU is certainly performing ONLY double precision (or higher) calculations in hardware.

2) You shouldn't be using floating point for financial calculations unless you are guaranteed to NEVER have values in multiples of tenths of a dollar. A fair number of common monetary values (such as $0.10)) can't be precisely represented in floating point and will round up or down by a penny, even when represented in double precision.

The "best practice" for financial calculations is to represent all money values as pennies (or fractions of pennies) and use 64-bit integers (long long in C/C++) or BCD numbers for the calculations. This way you never have round-off errors and you get results at least as fast the floating point calculations.
Jeffrey Dutky Send private email
Thursday, June 26, 2008
 
 
Don't confuse what they're doing with accounting. In derivatives pricing, for instance, it is common to use doubles and do not bother about rounding to pennies etc. Why would you measure volatility in pennies, anyway?
quant dev Send private email
Thursday, June 26, 2008
 
 
As others have mentioned, you won't see any benefit in the speed of the computation.  Where you could see benefit is in the size reduction.

I did a test of inverting a matrix in both single and double precision.  For a small matrix (100x100) both single and double were within 5% of each other.  For a larger matrix (1000x1000) the single precision matrix was inverted considerably faster.  This was in C++, but I would expect that Java would be similar.

If you have a lot of data to transfer back and forth between memory, i.e. you are memory bound, then you might see a speedup by going to single precision.  You might see a speedup if cache effects start coming into play.

If you're dealing with megabytes of data, it seems like it would be a simple to do a search and replace to see if you get a speedup.  I would assume that verifying that you're still getting the right answers would take somewhat longer.
C++ programmer Send private email
Thursday, June 26, 2008
 
 
quant dev wrote: "Don't confuse what they're doing
    with accounting. In derivatives pricing, for
    instance, it is common to use doubles and do
    not bother about rounding to pennies etc. Why
    would you measure volatility in pennies, anyway?"

Well, I suppose it DOES make a difference what you are doing. I have no experience with arbitrage, but in the kinds of financial systems I've worked with, penny-sized round off errors RAPIDLY add up to thousands of dollars (even, MILLIONS, in one case). Round off errors like this are only ONE way to screw things up with floating point arithmetic, and the other ways are even more insidious. In any system where the values are supposed to correspond to real world values, I wouldn't take the chance.
Jeffrey Dutky Send private email
Thursday, June 26, 2008
 
 
Paste a chunk of representative code into a new project. Make it work standalone, ensuring it remains representative.

Copy the standalone project and port it to single precision.

If you wish, copy the standalone project and port it to integer or anything else you'd like to test.

Measure execution time and memory usage.

Compare.

(No I'm not going to speculate - the results depend on your actual code.)
less is more
Thursday, June 26, 2008
 
 
What C++ Programmer said.  It won't matter for a few calculations, but if you have enough data to fill the cache memory then size savings turn into performance gains.  (If you are doing large matrix operations you should look into using some BLAS implementation for Java, although what I could turn up in Google on this seems at least 5 years old.)
Michael
Friday, June 27, 2008
 
 
"Anyone suggesting that we should be using C++ without some evidence to back it up will be mocked. ;) "

Ok, how's this...

If this was C++ you could use typedef to define your basic data type then switch the program back and forth float<->double to measure the speed difference (if any). :-)
Jimmy Jones
Friday, June 27, 2008
 
 
@Jeffrey

"Well, I suppose it DOES make a difference what you are doing. I have no experience with arbitrage, but in the kinds of financial systems I've worked with, penny-sized round off errors RAPIDLY add up to thousands of dollars (even, MILLIONS, in one case)."

What have you worked with? I can assure you that in case of derivatives pricing, in typical cases you won't need or desire fixed-point numbers.
quant dev Send private email
Friday, June 27, 2008
 
 
Probably won't gain any speed.

If you don't require that many sig. digits, floats are ok, but calculations should probably be done using double anyway.
Rick Tang
Friday, June 27, 2008
 
 
quant dev wrote: "What have you worked with? I can assure you
    that in case of derivatives pricing, in typical cases you
    won't need or desire fixed-point numbers."

I've worked with accounting systems: transaction processing, reconciliation, etc. Every value I work with corresponds to real money in somebody's pocket, so we can't stand any round off errors. The systems I've worked with have also done VERY large summations as a matter of course, which is EXACTLY how you get substantial round off errors in floating point arithmetic.

As I said, I have no experience with arbitrage systems, so I don't know what kinds of calculations are being done, or how closely they must reflect physical reality. If arbitrage is doing relatively short summations, or if the values only need to agree statistically with physical reality, then I guess FP is a very good fit.
Jeffrey Dutky Send private email
Friday, June 27, 2008
 
 
I got a response from someone who has written a benchmark: http://forums.java.net/jive/thread.jspa?messageID=282856

As for using integers, most of the doubles in my system are representing prices, not dollars.  And we do very little summing and the like, so we're not worried about compounding round-off errors.
Hockey Player Send private email
Friday, June 27, 2008
 
 
quant dev, would $92,000,000,000,000,000 be sufficient for the sorts of things you do? IOW, would 63-bit integer maths be adequate?
less is more
Friday, June 27, 2008
 
 
@JD

"I've worked with accounting systems: transaction processing, reconciliation, etc. Every value I work with corresponds to real money in somebody's pocket, so we can't stand any round off errors."

Then it's totally different from marking to model.

"or if the values only need to agree statistically with physical reality, then I guess FP is a very good fit."

I think that it is indeed so when one does statistical arbitrage.

@less is more

When I calculate a price of a CDO tranche, it gets expressed as

contingentPV - coupon * premiumPV - upfront.

All these numbers are of the order of one or less, even if the tranche notional is $40,000,000. Yes, there are certainly roundoff errors -- but the errors from the model and, like, Brent solver used to calibrate it are certainly bigger then what I would gain from counting every penny.
quant dev Send private email
Friday, June 27, 2008
 
 
Letting it run for a bit, Java will JIT your code down to asm.  Assuming an intel-ish machine, the FPU internally uses 80 bits of precision.

The real benefit of using floats are:
1. Storage space, in memory and disk
2. Memory bus & cache utilization.

Depending on bus contention, cache sizes, etc., you may see a benefit going to floats.  For a proper benchmark, you'll want to run those tests on a machine as similar to your deployment box as possible, and with the same level of load as when under deployment (to simulate contention for the memory bus, memory, cache, etc.)

If you want real speed, where speed==$$, offload that stuff off to a GPU program with something like CUDA.  They work with floats now, and the newest GPUs do doubles.

-ls
Lally Singh Send private email
Friday, June 27, 2008
 
 
"A classic and wonderful book by Jon Bentley: http://www.amazon.com/Programming-Pearls-2nd-ACM-Press/dp/0201657880"

In which one of the principle lessons was to MEASURE IT!

Anyway, in C (plain old C), the math libraries used doubles. Thus, any floats you had where converted into doubles. That means, you might optimize your code to use floats and get alot more conversions.
somebody else
Friday, June 27, 2008
 
 
I don't see how comparing C or C++ to Java is relevant.  Especially when the performance of the resulting C or C++ code is largely a factor of the compiler used to convert the C/C++ code into machine code.

The real question the OP is getting at is if an interpreted language can out perform machine code.
~Eric
Sunday, June 29, 2008
 
 
Floats can be faster than doubles if your code can be vectorized and take advantage of the SIMD instructions (or run on a gpu). I have no idea if the Sun VM can do that (GCC can) or if your code is easy to vectorize.
arg!
Monday, June 30, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz