What I saw in my tests is that whatever approach you use in an attempt
to convert packed decimal in C++ to something "faster" (tried
__dectoi, QXXPTOI, cpynv) the result is exactly the same as if I make
a plain assignment of packed decimal variable value to integer (or
long long) value. So these functions provide no work around.
And at the same time I saw that ANY operation with packed decimal (or
as they call it BCD) is extremely expensive in terms of performance.
At the same time in C plain assignment is absolutely fastest of all
the ways to convert packed to int.

In this situation there are 2 things that surprise me:
1. Why IBM decided not to use the same engine for packed decimal in C
as they use in C++? What was the trade off? I mean did they gain
anything by loosing so much in performance?
2. How did it happen that noone have mentioned that earlier (at least
I googled and found no evidence that anyone new about it)?

But these questions can potentially be answered only by "insiders", I

On Tue, Feb 17, 2015 at 4:55 PM, Mark S Waterbury
<mark.s.waterbury@xxxxxxxxxxxxx> wrote:

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 is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2021 by midrange.com 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.