Fast BigFloat unit for Delphi

Question

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

Phrase

That is indeed the first hit on Google when looking for "delphi bigfloat". Have you tried the second, third and fourth too? – Trachyte

@Trachyte 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. – Phrase

@David Heffernan Which C lib should I take, how can I link it via DLL and how do I work with it in Delphi? – Phrase

I don't know the answer to the first Q, but I can do the others! – Repent

Here's a link to a SO question which gives a link to a suitable library. #26594 – Dufresne

And here's a link to a Delphi wrapper for GMP. code.google.com/p/gmp-wrapper-for-delphi – Dufresne

@Phrase You still didn't explain why your performance constraints are. Also, out of interest, what computation are you performing? – Repent

Answer 1

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.

Dufresne

Thanks, GMP for Delphi is faster than the library I used before, but it's still slow as hell... – Phrase

Answer 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.

Repent

Indeed. Size matters. Single floating point arithmitics are faster than Doubles too. – Trachyte

@GolezTrol: Except in Delphi-XE2-64bit. :-) – Stroller

@Warren Not true. Read Eric's follow up where he discovers {$EXCESSPRECISION OFF}. – Repent

@David: They're still not faster, though they're no longer slower. :-) – Fawn

@Fawn Do you know why that is? – Repent

{$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. – Stroller

@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. – Dufresne

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. – Gudrunguelderrose

@Eric, this bug is already in the pipeline to be fixed. Embarcadero seems to put much effort in XE2. – Dufresne