3

I'm looking for a fast BigFloat unit, which can deal with addition, subtraction, multiplication and division (log would be fine but isn't necessary) and which has a precision of at least 100 decimal places. I've tried this unit, but it's about 1,000 times slower than standard extended operations. So, does anyone know a fast(er) BigFloat unit for Delphi?

Henry

Henry
  • 65
  • 6
  • That is indeed the first hit on Google when looking for "delphi bigfloat". Have you tried the second, third and fourth too? – GolezTrol Sep 10 '11 at 08:54
  • @GolezTrol Yes I did. The second contains a broken link, the third leads leads to a unit which doesn't work for me and the fourth is this thread at stackoverflow.com. – Henry Sep 10 '11 at 09:02
  • @David Heffernan Which C lib should I take, how can I link it via DLL and how do I work with it in Delphi? – Henry Sep 10 '11 at 09:06
  • I don't know the answer to the first Q, but I can do the others! – David Heffernan Sep 10 '11 at 09:09
  • Here's a link to a SO question which gives a link to a suitable library. http://stackoverflow.com/questions/26094/most-efficient-implementation-of-a-large-number-class – LU RD Sep 10 '11 at 09:10
  • 2
    And here's a link to a Delphi wrapper for GMP. http://code.google.com/p/gmp-wrapper-for-delphi/ – LU RD Sep 10 '11 at 09:20
  • @Henry You still didn't explain why your performance constraints are. Also, out of interest, what computation are you performing? – David Heffernan Sep 10 '11 at 09:56

2 Answers2

5

To summarize the comments to the OP's question.

A C library is probably the best solution for a big floating point library.

GMP claims to be the fastest free library, optimized with assembly and established since 1991.

Use this Delphi wrapper for the GMP library.

For even faster speed with reasonable cost/effort a CUDA/GPU solution would do the job. There are work going on, but I could not find a finalized solution.

LU RD
  • 34,438
  • 5
  • 88
  • 296
  • Thanks, GMP for Delphi is faster than the library I used before, but it's still slow as hell... – Henry Sep 24 '11 at 06:24
2

Software floating point is inherently 1 or 2 orders of magnitude slower than hardware floating point. Couple this with the fact that you are looking for much greater precision and you probably have another order of magnitude.

Your expectations are probably unrealistic.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Indeed. Size matters. Single floating point arithmitics are faster than Doubles too. – GolezTrol Sep 10 '11 at 09:40
  • @GolezTrol: Except in Delphi-XE2-64bit. :-) – Warren P Sep 10 '11 at 16:26
  • 1
    @Warren Not true. Read Eric's follow up where he discovers `{$EXCESSPRECISION OFF}`. – David Heffernan Sep 10 '11 at 16:26
  • @David: They're still not faster, though they're no longer slower. :-) – afrazier Sep 10 '11 at 17:05
  • @afrazier Do you know why that is? – David Heffernan Sep 10 '11 at 17:10
  • {$EXCESSPRECISION OFF} disables the pathological code generation, by disabling single precision completely, right? So in a sense, you can not make singles faster in Delphi XE 64, but you can stop using them while still having code that says you're using them. – Warren P Sep 10 '11 at 17:11
  • 2
    @Warren, with the switch on (default), calculations in single float mimics the X32 bit by using a higher precision internally (extended in X32 and double in X64). With the switch off, calculations are made in single precision throughout, which leads to a significant speedup. MS compiler has a similar switch. You can lose some information in the process, but in graphics like FM this is no big deal. – LU RD Sep 10 '11 at 18:37
  • 1
    And the extra precision of EXCESSPRECISION ON is only gained during intermediate steps of expressions, if you store the result back in single precision, the excess is thrown away anyway, so it's a rather fragile precision gain. However if you re the re-follow up, a compiler bug was found, which in some case means that you can end up with garbage, so EXCESSPRECISION OFF is risky until the next compiler updated. – Eric Grange Sep 10 '11 at 20:35
  • @Eric, this bug is already in the pipeline to be fixed. Embarcadero seems to put much effort in XE2. – LU RD Sep 10 '11 at 22:21