switch to decNumber?

[stevengj]

@ScottPJones points out that the IBM decNumber package (under the ICU license) may be more portable than the Intel package, and supports more formats. We might consider switching to it, instead of the Intel library.

(A more complex option would be to link to both libraries: using Intel where the performance is better, and decNumber where it supports more functionality.)

Would be interesting to compare the performance of the two libraries.

[stevengj]

One thing I don't like about decNumber is that it seems to use pass-by-reference for everything, which seems silly for passing and returning 32- and 64-bit values. It may not make much performance difference (since the operations themselves are so expensive), but will make the Julia glue code significantly uglier.

[ScottPJones]

Well, you've got the source, does the ICU license allow you to modify that?
I don't think there is much danger of getting out of sync with the decNumber code ... there doesn't seem to have been any changes in years... (which, in this case, is a good thing, it is very stable, well tested)
I think the issue may have been that this code has probably been around for long enough, and back 20 years ago they (like me) had to deal with pure 32-bit platforms and compilers (ILP32), and no 64-bit long long support... so for 64-bit & 128-bit values they had to use pass-by-reference...
Otherwise, you might want a C wrapper around the library, to deal with those, at least combine the things into a single structure passed in from Julia.

[ScottPJones]

@stevengj I'm very willing to help out in getting decNumber to work in Julia, I was going to do it myself, but I don't yet have your mad skills in writing Julia code... I was very impressed by the way you generated all of the functions for the binding... cool!

[stevengj]

The ICU license certainly allows the code to be modified; I wouldn't consider using it otherwise. But we are talking about a lot of functions, so I'd be hesitant to go through and change it to pass-by-value unless the process could be automated.

It's not too terrible to use pass-by-reference in Julia. For speed (to avoid heap-allocating Ref objects), I'd want to preallocate globals length-1 arrays to use for the return values. (This is how e.g. the base Julia library gets its return values from Fortran Bessel-function routines, which are inevitably pass-by-reference.)

[stevengj]

(Yes, the code-generation features of Julia make it a lot easier to wrap these kinds of libraries, because there are zillions of functions with very similar call signatures.)

[ScottPJones]

I think we'll be needing this soon, so I'll definitely be testing this package ASAP... (it seems that love of Julia is spreading quickly at the startup I'm consulting for 😀 I think shortly some other people from the company will be contributing, some core work, improving some packages such as ODBC, and possibly adding some new packages)

[PallHaraldsson]

"back 20 years ago they (like me) had to deal with pure 32-bit platforms"

I'm confused.. The decimal types didn't exist then(?) Are we talking about similar libraries? Yes, decimal is not new. The packed format is I thought. And, yes, the non-packed version is used, but I thought that came after the packed one.

I've never quite understood how both the packed and non-packed are supposed to be supported. Implementations defined? Do you just stick with either one (non-packed)? Dealing with the out-side-world must, files using these bittypes or APIs, must factor in..

For now we need not worry about actual hardware (using packed) in PowerPC (right?) while Julia support for it is worked on or for SPARC.

[ScottPJones]

@PallHaraldsson Back then, with the 32-bit machines, the memory model was ILP32, i.e. int, long, and pointer types were all 32-bit, and often the C compilers did not yet support structure passing... so if you wanted to return 64-bit or 128-bit types, which this package does, you had to do so by passing a reference. That is what makes the Julia wrapper more difficult, as @stevengj commented on.
Both formats are part of the standard, AFAIK. The packed format is better for when you have hardware support, the "non packed" (or binary integer significand) format is better for a software library... which is the case we are dealing with...
Both are useful to have available... for example if you are talking to a platform that is trying to send you data in the packed form, you might want to read it in, and convert it to the other form for calculations.

Scott

[stevengj]

Yes, my feeling is that for the packed format we should only implement conversions, not arithmetic, so from Julia's perspective it is a storage-only format.

[stevengj]

@ScottPJones, I programmed a lot of 32-bit machines, but I'm having trouble recalling a compiler which did not support passing or returning struct by value by the 1990s. Am I suppressing dark memories? However, it could be that they used an inefficient calling convention in that case.

My suspicion is that decNumber probably used pass-by-reference in order to be callable by older Fortran code (prior to compiler support for pass-by-value in the Fortran 2003 standard). (The Intel library has an option for this too.)

Anyway, whatever the reason, we need to deal with it to use decNumber. If one of you could just try calling it from C in a quick benchmark, e.g. adding 10000 numbers, in comparison to the Intel library, that would be great. It would be good to know what we're dealing with.

[ScottPJones]

@stevengj I started programming in the early 70's... (I was in 6th grade... taking courses at the state university), so I have a LOT of dark memories I'd like to suppress! [Think stacks of punched cards, written in Fortran 1966, and later in PL/1]. About C, it wasn't until sometime in mid '90s, that we were finally able to move to ANSI C completely, after waiting 5 years after the standard came out until the last platform that we actively developed for (as opposed to maintanence / bug fixing)... I used a lot of macro tricks to take advantage of ANSI C wherever I could, but that wasn't always easy.
The decNumber package has very old roots... that's why I think it had to do with pre-ANSI C.

About the packed format, yes, that's exactly what I'd thought, when I was starting to look at writing a binding for it for Julia... I do also want the arbitrary precision support, not really for doing calculations, but just for parsing and storing numbers coming from JSON and later outputting them...

[ScottPJones]

@stevengj I'll try to take time off from annoying Stefan about numeric literal inconsistencies and string performance issues ;-) and download the Intel library, figure out out to use it, and add up 10000 numbers!

[PallHaraldsson]

Right now, I do not have time (or 0.4..) but I was going to test this with
numbers of similar scale. I saw some very high worst case latency in a C
implementation. I assume if the scale is the same there must be some fast
path.. (similar in DEC64, I was thinking of doing similar fast path stuff
if not) if all you are dealing with is say currency, that would be all that
matters?

2015-05-01 22:40 GMT+00:00 Scott P. Jones notifications@github.com:

@stevengj https://github.com/stevengj I'll try to take time off from
annoying Stefan about numeric literal inconsistencies and string
performance issues ;-) and download the Intel library, figure out out to
use it, and add up 10000 numbers!

—
Reply to this email directly or view it on GitHub
#12 (comment).

Palli.

[ScottPJones]

@stevengj Here are some initial results... this is with the arbitrary precision decNumber type, not even using the shorter types...

julia> @time run(dec)
(1.25 + 2.55) => 25500000001.25, 255
elapsed time: 255.405512641 seconds (9 MB allocated)

julia> @time run(dbl)
(1.250000 + 2.550000) => 25499995395.430843, 24
elapsed time: 23.543102345 seconds (1 kB allocated)

So, it is only about 10x slower than C double... (and gets correct results!)
That doing a = 1.25, b = 2.55, and then for (i=0; i<10000000000; i++) a += b;

Can you run that comparison for your Intel library?
(I couldn't even measure the time for just 10000 additions!)

int main(int argc, char *argv[]) {
    double numa, numb;
    numa = 1.25;
    numb = 2.55;

    long ts = time(0);
    for (long i=0; i<10000000000; i++) {
    numa += numb;
    }
    long te = time(0);
    printf("(%f + %f) => %f, %ld\n", 1.25, 2.55, numa, te - ts);
    return 0;
} // main

int main(int argc, char *argv[]) {
    decNumber numa, numb;            // working decNumbers
    decContext set;                  // working context
    char string[DECQUAD_String];     // number->string buffer

    if (argc<3) {                    // not enough words
    printf("Please supply two numbers for a + b).\n");
    return 1;
    }
    decContextDefault(&set, DEC_INIT_DECQUAD); // initialize

    decNumberFromString(&numa, argv[1], &set); // get a
    decNumberFromString(&numb, argv[2], &set);

    long ts = time(0);
    for (long i=0; i<10000000000; i++) {
    decNumberAdd(&numa, &numa, &numb, &set); // numa=numa + numb
    }
    long te = time(0);
    decNumberToString(&numa, string);               // ..

    printf("(%s + %s) => %s, %ld\n", argv[1], argv[2], string, te - ts);
    return 0;
} // main

[PallHaraldsson]

2015-05-03 20:48 GMT+00:00 Scott P. Jones notifications@github.com:

So, it is only about 10x slower than C double... (and gets correct
results!)

Very good. Before you think this library is better 10x vs. 100x the latter
should be compared also with the similar scale. I think that would also get
closer to 10x or maybe better (vise versa could also be tried with more
random numbers) - probably loose the 9 MB allocation. There must be some
fast path..

I actually though about doing some fast path - by wrapping a slow decimal
floating point type. Then I got close to 1x compared to Int.