7

I often see pprograms like this, where Int64 is an absolute performance killer on 32-bit platforms. My question is now:

If I need a specific word length for my task (in my case a RNG), is Int64 efficient on 64-bit platforms or will it still use the C-calls? And how efficient is converting an Int64 to an Int?

Community
  • 1
  • 1
fuz
  • 88,405
  • 25
  • 200
  • 352
  • I would recommend using `Integer` as a first try. – Gabe Jan 04 '11 at 07:12
  • I need a fixed word size for implementing Xorshift, so Integer is no choice. – fuz Jan 04 '11 at 07:25
  • 4
    I would use whichever of `Int32` and `Int64` is better-suited for your RNG algorithm. Create a type synonym so you can easily test it later. Also be aware that an `Int` isn't the same as `Int32` (the Haskell spec only guarantees that an `Int` is at least 31 bits). – John L Jan 04 '11 at 09:17
  • See also http://stackoverflow.com/questions/5841577/performance-problem-with-euler-problem-and-recursion-on-int64-types – Don Stewart May 13 '11 at 18:28

2 Answers2

2

on a 64bit system Int64 should be fine, I don't know for sure though.

More importantly if you're doing Crypto or random-number-generation you MUST use the data type that the algorithm says to use, also be careful of signed-ness. If you do-not do this you will have the wrong results, which might mean that your cryptography is not secure or your random number generator is not really random (RNGs are hard, and many look random but aren't).

For any other type of work use Integer wherever you can, or even better, make your program polymorphic using the Integral type-class. Then if you think your program is slower than it should be profile it to determine where you should concentrate when you try to speed it up. if you use the Integral type-class changing from Integer to Int is easy. Haskell should be smart enough to specialize (most) code that uses polymorphism to avoid overheads.

Paul Bone
  • 802
  • 4
  • 9
1

Interesting article on 64 bit performance here:

Isn’t my code going to be faster on 64-bit???

As the article states, the big bottleneck isn't the processor, it's the cache and memory I/O.

Robinson
  • 9,666
  • 16
  • 71
  • 115
  • 2
    First, for my purpose, I just have one single number I want to manipulate, so memory access should be no problem. The real problem is, that GHC is known to do many things over C calls which isn't always clear. – fuz Jan 04 '11 at 12:00
  • The question really appears to be Haskell specific. – Dietrich Epp May 13 '11 at 19:11