Yes, the overhead of converting the data to and from packed decimal needs to be considered, when working with the data in other formats.

Support for financial data is why IBM developed "packed decimal" support in the first place, on the IBM mainframes (S/360, S/370, S/390, z/Series). It looks like the IBM z/OS XL C compiler also supports packed decimal directly, in the same way that ILE C/400 does, and the IBM C++ compiler on the mainframe uses the same "BCD" library, the same way ILE C++ does.

IBM has made some improvements in each new generation -- Power4, Power5, Power6, Power7 and Power8, with regard to better support for "packed decimal" arithmetic and what is called "decimal floating point," so I am not surprised that your results are different from mine. (That is why I posted the source code, so that anyone can try it on their systems.)

I think this is the right approach -- to test various coding alternatives, and measure the results, before deciding which way to go, for your "live" production applications.

All the best,

Mark S. Waterbury

> On 2/17/2015 8:56 AM, Jevgeni Astanovski wrote:

Spent some time and rewrote the API to use long long.
However I have nothing to do about the data that I'm processing.
I work in the finance area so effectively my API works not with
numbers - rather with money.
And all the money in the tables is kept as packed decimals.
So what I did - I read packed decimals and immediately convert them to
long long before I make some arithmetics with them.
Result is still the same - 2 times slower than the C version...

I'll now go and experiment with the benchmarking program of yours to
see what consumes time. If conversion of packed to int (or long) is
most ti,e consuming, then probably I'm digging in the wrong

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].