1

Background: I want to store numbers that are precise to 4 decimal places, without roundoff. So I thought of using integers internally; for example, 12.3456 is represented as 123456 internally. But with 32b integers, I can count only upto 214748, which is very small.

I guess that 64-bit integers are the solution. But are operations involving 64-bit integers less efficient than 32-bit integers, given a machine running a 64-bit JVM?

BTW, I am using an information retrieval package (Solr), an optimization package (Drools) and other packages written in Java, and they may not play well with decimal datatype (if you suggest it).

skaffman
  • 398,947
  • 96
  • 818
  • 769
Jesvin Jose
  • 22,498
  • 32
  • 109
  • 202
  • 2
    In Java, `int` is *always* 32 bits, even on a 64bit JVM: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Integer.html#MAX_VALUE – skaffman Mar 07 '12 at 16:43
  • Why don't you just make a test app, and see for yourself? – ShaMan-H_Fel Mar 07 '12 at 16:44
  • It's called a `long` in java, and why would they be *less* efficient when modern processors are 64bit? – Brian Roach Mar 07 '12 at 16:45
  • possible duplicate of [Performance 32 bit vs. 64 bit arithmetic](http://stackoverflow.com/questions/8948918/performance-32-bit-vs-64-bit-arithmetic) – skaffman Mar 07 '12 at 16:51
  • @skaffman, I am specific about the JVM, whereas the question you mentioned seems inclined to machine code. – Jesvin Jose Mar 07 '12 at 17:55

3 Answers3

2

Even if it is slower, I doubt this would be the bottleneck in your system. You are very likely going to have more significant performance issues in other parts of your program.

Also, the answer to this question provides more details, but basically "It's platform dependent.". It's not necessarily true 64 bit will be slower than 32 bit.

Community
  • 1
  • 1
Oleksi
  • 12,947
  • 4
  • 56
  • 80
1

This is likely to be platform dependant. I have seen cases where using long instead of int is about 10% faster. The 64-bit JVM for Java 5.0 was about 5% - 10% slower than the 32-bit JVM for Java 5.0. Java 6 doesn't appear to have this problem.

I imagine the cost of dividing by 10000 far outweighs the cost of using a long instead of an int value.

You could also use double, rounding the result to four decimal places before printing/outputting it.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
1

Generally, the more data you need to hurl around, the slower it is, so even on a 64-bit VM sticking to int instead of long is faster in most cases.

This becomes very clear if you think in terms of memory footprint: an array of 1 million ints requires 4MB, 1M longs eat 8MB.

As for the computational speed, there is some overhead to perform operations on 64-bit types with 32-bit instructions. But even if the VM can use 64-bit instructions (which it should on a 64-bit VM), depending on the CPU they may still be slower than their 32-bit counterparts (add/subtract will probably go in one clock, but multiply and divide in 64-bit are usually slower than in 32-bit).

A very common misconception is that integer math is faster than floating point math. As soon as you need to perform extra operations to "normalize" your integers, floating point will beat your integer implementation flat in performance. The actual differences in clock cycles spent between integer and floating point instructions is neglible for most applications, so if floating point is waht you need, use it and don't attempt to emulate it yourself.

For the question which type to actually use: Use the type thats most appropriate in terms of data representation. Worry about performance when you get there. Look at wht operations you need to perform and what precision you need. Then select the type that offers exactly that. Judging by the libraries you mentioned, double will probably be the winner of that.

Durandal
  • 19,919
  • 4
  • 36
  • 70
  • He mentions that he wants to used packed decimals to archive true 4 digit precision, such as in BigInteger, as floats can have binary rounding errors, such as in `0.5` – Sebastian Nov 01 '13 at 16:40