Add Intel DFP library benchmarks using Intel Compiler

[mborland]

The Intel docs says the library was updated recently to run under the new Intel oneAPI compiler.

CC: @glenfe, @jzmaddock

[mborland]

So as I am studying the Intel lib I am realizing I completely botched the first set of benchmarks. C23, IBM, and libstdc++ define a _Decimal32 type, and it works exactly as one would expect a built-in type to work. On the other hand Intel just does this:

typedef unsigned int Decimal32

If you don't specifically use their functions you're just running our benchmarks as an unsigned int so of course it's fast. It does not help that Intel provides exactly 0 documentation and useful examples so this is all experiential learning.

[jzmaddock]

Ugh, that would do it!

And yes, it's just a C library, there are no operator overloads or anything, you have to call the appropriate C library function for every operation :(

[mborland]

Ugh, that would do it!

And yes, it's just a C library, there are no operator overloads or anything, you have to call the appropriate C library function for every operation :(

Exactly. Now I am getting much more reasonable results all being as equal as it's going to be (C++14 vs C11 both on the Intel compiler)

Us:

===== Comparisons =====
comparisons<float      >: 73257      us (s=299999985)
comparisons<double     >: 144571     us (s=299999985)
comparisons<decimal32  >: 2183205    us (s=299999985)
comparisons<decimal64  >: 2608329    us (s=299999985)
comparisons<dec32_fast >: 639140     us (s=299999985)
comparisons<dec64_fast >: 560221     us (s=299999985)

Intel:

===== Comparisons =====
Comparisons    <Decimal32  >: 2113898    us (s=299999985)
Comparisons    <Decimal64  >: 2340342    us (s=299999985)

[ckormanyos]

Exactly. Now I am getting much more reasonable results all being as equal as it's going to be (C++14 vs C11 both on the Intel compiler)

Thank you Matt (@mborland) for figuring this mystery out or getting close to it.

This was expected. Or something like it. I mentioned earlier that I won't try all that hard to beat those numbers --- as it's impossible. But I'm willing to swap out our big integer backend for the fastest possible thing(s) we can find to shave off a reasonable amount like some number of percent.

[mborland]

Here is most of the basic functions:

Us:

===== Addition =====
Addition<decimal32  >: 2013988    us (s=1000134990395)
Addition<decimal64  >: 2473012    us (s=1000134990395)
Addition<dec32_fast >: 1248342    us (s=1000134990395)
Addition<dec64_fast >: 906706     us (s=1000134990395)

===== Subtraction =====
Subtraction<decimal32  >: 1788740    us (s=166680686215)
Subtraction<decimal64  >: 2045088    us (s=166680686215)
Subtraction<dec32_fast >: 1081617    us (s=166680686215)
Subtraction<dec64_fast >: 783670     us (s=166680686215)

===== Multiplication =====
Multiplication<decimal32  >: 1761256    us (s=2500419801094285)
Multiplication<decimal64  >: 2115496    us (s=2500419770901035)
Multiplication<dec32_fast >: 715356     us (s=2500419801094285)
Multiplication<dec64_fast >: 717914     us (s=2500419770901035)

Intel:

===== Addition =====
Addition       <Decimal32  >: 445353     us (s=84724946464366650)
Addition       <Decimal64  >: 494678     us (s=14357476611999199848)

===== Subtraction =====
Subtraction    <Decimal32  >: 767511     us (s=191056411610879880)
Subtraction    <Decimal64  >: 564294     us (s=14357475945510500058)

===== Multiplication =====
Multiplication <Decimal32  >: 375991     us (s=84725181629688240)
Multiplication <Decimal64  >: 388470     us (s=14359974966624609773)

Our fast types are reasonably close and now that I know Intel does the same non-compliant IEEE 754 BID encoding as IBM, it's basically worth writing off any comparison to our complaint types. You can decode their number with two bitwise and plus one right shift, whereas true IEEE 754 BID layout decoding is a non-trivial operation.

[ckormanyos]

Our fast types are reasonably close and now that I know Intel does the same non-compliant IEEE 754 BID encoding as IBM, it's basically worth writing off any comparison to our complaint types. You can decode their number with two bitwise and plus one right shift, whereas true IEEE 754 BID layout decoding is a non-trivial operation.

I am happy you looked into this Matt. Also as a rule of thumb, I usually put a fudge-factor of $25$ on software-versus-hardware type(s). So a factor of only $10$ is kind of good.

[mborland]

Our fast types are reasonably close and now that I know Intel does the same non-compliant IEEE 754 BID encoding as IBM, it's basically worth writing off any comparison to our complaint types. You can decode their number with two bitwise and plus one right shift, whereas true IEEE 754 BID layout decoding is a non-trivial operation.

I am happy you looked into this Matt. Also as a rule of thumb, I usually put a fudge-factor of 25 on software-versus-hardware type(s). So a factor of only 10 is kind of good.

Yeah before I went down the wrapper road for intel I wanted to make certain the readings were correct. Since refactoring some cruft is 2 of the post review issues it'll be good to re-look the add/sub/mul/div impls since our comps are a good bit faster.

[ckormanyos]

I like the multiplication comparison at 64-bit the most.

The general rule of thumb is that the multiplication operation dominates most mathematical calculations of pure and applied mathematics. Being within a factor of 2, while retaining (close to) IEEE-754 compliance is actually a remarkable result.

A factor of 5 on the IEEE-754 compliant types is good, I owuld say at least subjectively.

This is really good Matt.

[mborland]

Here is a set of generally analogous benchmarks using the 2025.2 Intel Compiler and 20U3 version of Intel's libbid.

===== Comparisons =====
Comparisons    <Decimal32  >: 2127236    us (s=299999985)
Comparisons    <Decimal64  >: 2338538    us (s=299999985)

===== Addition =====
Addition       <Decimal32  >: 1182215    us (s=9896289315)
Addition       <Decimal64  >: 1245921    us (s=999796373730)

===== Subtraction =====
Subtraction    <Decimal32  >: 1310659    us (s=18446744073709551331)
Subtraction    <Decimal64  >: 962473     us (s=10080)

===== Multiplication =====
Multiplication <Decimal32  >: 935892     us (s=244841101225)
Multiplication <Decimal64  >: 973832     us (s=2498870510577490

[mborland]

And after a bugfix here is where we are at using our benchmarks with the 2025.2 Intel Compiler:

====== BEGIN OUTPUT ======
===== Comparisons =====
comparisons<float      >: 72737      us (s=299999985)
comparisons<double     >: 142954     us (s=299999985)
comparisons<decimal32  >: 1484193    us (s=299999985)
comparisons<decimal64  >: 1638340    us (s=299999985)
comparisons<decimal128 >: 4847950    us (s=299999985)
comparisons<dec32_fast >: 577152     us (s=299999985)
comparisons<dec64_fast >: 566893     us (s=299999985)
comparisons<dec128_fast>: 587864     us (s=299999985)

===== Addition =====
Addition<float      >: 77520      us (s=9223372036854775808)
Addition<double     >: 72723      us (s=9223372036854775808)
Addition<decimal32  >: 1615759    us (s=9827570466811016471)
Addition<decimal64  >: 1445492    us (s=10731210489930524555)
Addition<decimal128 >: 3436821    us (s=16027718929636343473)
Addition<dec32_fast >: 706459     us (s=9827464416810516466)
Addition<dec64_fast >: 945210     us (s=10731210489930697615)
Addition<dec128_fast>: 1224971    us (s=3929884617988136407)

===== Subtraction =====
Subtraction<float      >: 77636      us (s=0)
Subtraction<double     >: 72448      us (s=9223372036854775808)
Subtraction<decimal32  >: 1526291    us (s=5501060890425553197)
Subtraction<decimal64  >: 1428809    us (s=11235638221977265650)
Subtraction<decimal128 >: 3138637    us (s=12413787457732268901)
Subtraction<dec32_fast >: 950588     us (s=5501060890425553197)
Subtraction<dec64_fast >: 922812     us (s=11235638221981570510)
Subtraction<dec128_fast>: 1146858    us (s=8962571179270989724)

===== Multiplication =====
Multiplication<float      >: 77696      us (s=9223372036854775808)
Multiplication<double     >: 72582      us (s=9223372036854775808)
Multiplication<decimal32  >: 1670484    us (s=12977635561851367651)
Multiplication<decimal64  >: 2347936    us (s=2444112243153066082)
Multiplication<decimal128 >: 6396224    us (s=17982360340480646839)
Multiplication<dec32_fast >: 958018     us (s=12977635561843323801)
Multiplication<dec64_fast >: 1680713    us (s=2444112243153066082)
Multiplication<dec128_fast>: 6393797    us (s=17982360340480646839)

===== Division =====
Division<float      >: 100216     us (s=889346465)
Division<double     >: 103545     us (s=889346420)
Division<decimal32  >: 2098840    us (s=12667720160319606110)
Division<decimal64  >: 5672048    us (s=9681494407404311270)
Division<decimal128 >: 9584565    us (s=13104797390727794381)
Division<dec32_fast >: 1006128    us (s=12667720160320455630)
Division<dec64_fast >: 2138371    us (s=9681494407404311270)
Division<dec128_fast>: 8661224    us (s=12181188509800041417)


EXIT STATUS: 1
====== END OUTPUT ======