Why Intel decimal library?
|
03-11-2014, 12:35 AM
(This post was last modified: 03-11-2014 12:35 AM by Claudio L..)
Post: #1
|
|||
|
|||
Why Intel decimal library?
From what I understand, WP34S used the Intel decimal library, and now also Free42 is using the Intel library.
My question is what are the advantages of the Intel library versus decNumber? The following series of tests seem to prove that decNumber is faster than the Intel library: http://speleotrove.com/decimal/dpintro.html Of course, they are the maintainers of decNumber so they might be biased, but from what I see they are very similar in the functions they offer, with decNumber actually having some additional functions (though most of the advanced functions are only for the decNumber format, not for decFloats) if you are willing to pay the price in speed. We are about to add real numbers to newRPL and wanted to discuss here these two contenders. I'm wondering what's the reason why everyone seems to be converging on the Intel library. Claudio |
|||
03-11-2014, 06:37 PM
Post: #2
|
|||
|
|||
RE: Why Intel decimal library?
(03-11-2014 12:35 AM)Claudio L. Wrote: From what I understand, WP34S used the Intel decimal library, and now also Free42 is using the Intel library.I have to disagree. WP 34S is using decNumber. The storage of numbers is done in a modified (simplified) decimal64/decima128 format but all internal computations are done with decNumber objects. Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basic-compare.html |
|||
03-11-2014, 10:33 PM
Post: #3
|
|||
|
|||
RE: Why Intel decimal library?
As Marcus wrote, the 34S uses a modified decNumber library for its basic arithmetic. Internally I work with higher than decimal128 precision and convert before and after operations. In this case, of not using decmial64 or decimal128 for much bar storage) even those old comparisons indicate that the Intel library would be faster. The comparison is somewhat misleading in that there isn't mention of the many functions included in the Intel library but not in decNumber (but not vice versa). I also wouldn't be concerned about the type conversion benchmarks, the two libraries, by default, use different ways to store the mantissa internally and the decNumber flavour makes format conversions very quick -- these aren't done all that often compared to the number crunching.
The first major difference between the Intel library and decNumber is the support for transcendental functions. decNumber implements e^x and log and that's it (well, it has square root). On the 34S we don't even use the decNumber log since it is extremely slow. The Intel library implements all these plus the trigonometric functions, the hyperbolic functions and gamma and probably some others too. They are also fairly accurate implementations, usually with an error bound in the last digit published. The other big difference between the two libraries is their size. The Intel library is large. Very large. It uses lots of look up tables to reduce functions to one of many low degree polynomial or rational approximations. This makes it very fast. If you have the space, use the Intel library. You get a large suite of well tested fast functions. If you are tight for space, use decNumber and crib the transcendentals etc from the 34S project. You'll get a slightly larger set of functions that aren't as well tested or fast but which are tightly coded. - Pauli |
|||
03-12-2014, 01:18 AM
Post: #4
|
|||
|
|||
RE: Why Intel decimal library?
(03-11-2014 10:33 PM)Paul Dale Wrote: As Marcus wrote, the 34S uses a modified decNumber library for its basic arithmetic. Internally I work with higher than decimal128 precision and convert before and after operations. In this case, of not using decmial64 or decimal128 for much bar storage) even those old comparisons indicate that the Intel library would be faster. decNumber is very slow when you use the actual decNumber format. Using the decDouble (decimal64) or decQuad (decimal128) seems to be faster than the Intel one, at least in those numbers. (03-11-2014 10:33 PM)Paul Dale Wrote: The comparison is somewhat misleading in that there isn't mention of the many functions included in the Intel library but not in decNumber (but not vice versa). Very misleading, I was lead to believe that the Intel library didn't have trascendental functions. I see now why it would be a better choice. (03-11-2014 10:33 PM)Paul Dale Wrote: The other big difference between the two libraries is their size. The Intel library is large. Very large. It uses lots of look up tables to reduce functions to one of many low degree polynomial or rational approximations. This makes it very fast. I guess I'll have to download and compile the Intel library to see how large it is. We only have 2 MB of flash, but if the library is that good, perhaps it will be worth the extra space. (03-11-2014 10:33 PM)Paul Dale Wrote: If you have the space, use the Intel library. You get a large suite of well tested fast functions. If you are tight for space, use decNumber and crib the transcendentals etc from the 34S project. You'll get a slightly larger set of functions that aren't as well tested or fast but which are tightly coded. I guess we'll have to evaluate both and decide. Speed will be a major factor, since the idea is to be faster than userRPL, and I think that pushes towards decQuad. Availability of functions (equals faster development) pushes towards Intel, so it's a tie. We need to look at the size of the library to break the tie... if it fits, the Intel library will probably help get us there faster. Thanks for the insight. Claudio |
|||
03-12-2014, 01:45 AM
Post: #5
|
|||
|
|||
RE: Why Intel decimal library?
(03-12-2014 01:18 AM)Claudio L. Wrote: I guess I'll have to download and compile the Intel library to see how large it is. We only have 2 MB of flash, but if the library is that good, perhaps it will be worth the extra space. Don't bother it won't fit. Not even close. The 34S mathematics library and decNumber will fit easily. I used decNumber internally for a couple of reasons. The decNumber library I used didn't support decimal64 and decimal128 directly for arithmetic operations and there are the packing and unpacking steps to consider. I also wanted the increased precision to give me some room to round better. Having extra guard digits during a computation is a godsend. The comparison you mentioned seems flawed in other ways too. For example, it doesn't seem to mention what decNumber settings were used to get their timings? How many digits e.g. If you look at the functions that really matter (addition, multiplication and to a lesser degree division) the timings aren't so different. The format conversions are where the big differences are and they aren't important at all, these are done very rarely. I also notice square root isn't there. The IEEE standard requires this to be correctly rounded and the decNumber method works perfectly but isn't overly fast. - Pauli |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)