Re: Packed and zoned decimal problem -- RPG400-L

Charles:

I do not have a "link to documentation that says this." I observed this performance difference in real-world application programs coded in ILE C versus the same programs coded in ILE RPG IV.

I did NOT say that RPG out-performs COBOL (or any other language) in ALL cases. What I said was, if you use zoned decimal fields and did lots of calculations (arithmetic) using those zoned fields, then RPG would out-perform COBOL because of this compiler generated implicit type conversion in working storage. Of course, a "smart" COBOL (or C) programmer could do the same thing, by just declaring working storage fields and after reading the record, copy the zoned fields into the working storage variables, use those working storage fields for all calculations, and then copy the value back to the zoned fields in the record just prior to writing the record back out again.

With the OPM COBOL/400 and RPG/400 compilers, you can specify GENOPT(*LIST) and you can study the MI assembler code generated, so you can see exactly what the compiled code is doing.

Or, perhaps you could write some "benchmark" programs?
HTH,

Mark S. Waterbury

> Charles Wilt wrote:

On Wed, Oct 22, 2008 at 11:25 PM, Mark S. Waterbury
<mark.s.waterbury@xxxxxxx> wrote:

Hi, Eric:

You might gain a small performance advantage on each I/O, but if you do
much arithmetic with any zoned fields, your performance will suffer
because the compiled code must convert zoned to packed internally to do
any arithmetic, and then covert back to zoned again when storing the
results into your zoned fields. If you do this in a loop, for example,
the added overhead to convert back and forth between packed and zoned
will start to dominate the total CPU consumed.

I wasn't aware of this, do you have a link to the documentation that says this.

By design, RPG is a "scatter/gather" language. On input, it copies (or
"scatters") all fields from the record buffer into equivalent working
storage fields, and converts all zoned fields into packed working
storage fields at that time. That way, all calculations (math, etc.)
can proceed at full speed, as the working storage fields are already in
packed format. Then, only when you WRITE or UPDATE the record, the
fields are "gathered" from working storage back into the record buffer,
and any packed working storage fields are converted back to zoned where
needed, and the record is written out.

This is one reason why, in many cases, if you re-wrote a program
line-for-line from ILE RPG IV into ILE COBOL or ILE C, if the program
does a fair amount of calculations with any of the zoned fields, the RPG
version will usually outperform the COBOL or C version by a wide margin.
(This was also true for OPM RPG/400 vs. OPM COBOL or OPM PL/I, etc.)

I thought the opposite was true. RPG's "scatter/gather" as you called
it, made RPG a poorer performer than COBOL.

At least until v5r2 and the ability to do file I/O directly to a data
structure which narrowed the gap. I couldn't find the message from
Barbara Morris that I was looking for, but there's a blurb in the v5r2
announcement http://www-01.ibm.com/cgi-bin/common/ssi/ssialias?infotype=an&subtype=ca&htmlfid=897/ENUS202-130&appname=usn&language=enus
or http://tinyurl.com/5u3k6d
"Data-structure result for externally-described files: A data
structure can be specified in the result field when using I/O
operations for externally-described files. Before V5R2, this was
available only for program-described files. Using a data structure can
improve performance if there are many fields in the file. "

Also I did find this thread:
http://archive.midrange.com/rpg400-l/200705/msg00753.html

Charles Wilt