RE: Odd/Even packed numbers.

Hello Guiseppe,

I am having performance as my main area of interest (and living), and I
looked in details into this question when the RISC machines first came.

If you (or anybody else) are interested, I can provide rather detailed
documentation - what I did was that I ran MI instructions for packed
arithmetic in a loop ten million times (for each type, i.e. ADD, SUB, MUL,
DIV, even/odd, with and without decimals, etc.)

On a CISC box there was a remarkable difference - using an even number of
digits could be several times slower than an odd number, and unlike number
of decimals would also degrade performance quite something.

This has all changed for RISC, which basically cannot handle packed
arithmetic - rather than one "simple" AP (Add Packed) assembler instruction,
which in one instruction took care of adding two packed fields (if the
result had an odd number of digits, and number of decimals were the same),
the RISC box generates 33 (yes, it is 33) assembler instructions for the
most simple add packed - some of this even seems to do a loop.

But - the RISC CPU is much, much faster, so it competes not too badly,
although test runs on machines with the same RPR (as CPW used to be called)
showed that CISC was faster with packed arithmetic - I tried an E50 against
a model 500.

The bottom line to answer your question is that a few additional CISC
instructions needed to cope with decimal alignment or an even number of
digits gave a relatively large overhead (3 additional instructions compared
to one AP-instruction could mean 300% overhead, although it cannot be
calculated that simple) - - - but if you have to add 3 instructions to the
RISC code already consisting of 33 instructions, it only adds less than 10%.
This over-simplified calculation agrees fairly well with the results of my
tests.

SO THEREFORE: Yes, an even number of digits in a packed field is still
slower on the RISC box, but the overhead is now so small that even I, being
a performance fanatic, don't care any more.

Regards, Kaare

============================================
. . . NEVER accept bad performance from your
iSeries or AS/400 - let us solve the problem
See our "No cure - no pay" offer on the WEB
--------------------------------------------
Kaare Plesner        I     SOSY A/S
                     I     Generatorvej 6A
mailto:kp@sosy.dk    I     DK-2730 Herlev
                     I     Denmark
Home office:         I     Tel +45 4494 8105
+45 5835 3305        I     Fax +45 4494 8205

    SOSY A/S - an IBM Business Partner
      Meet us at http://www.sosy.dk/



-----Original Message-----
From: mi400-admin@midrange.com [mailto:mi400-admin@midrange.com]On
Behalf Of Giuseppe Costagliola
Sent: Thursday, November 28, 2002 10:39 AM
To: mi400@midrange.com
Subject: [MI400] Odd/Even packed numbers.


In the past (at S/38 times) we have been told that odd packed numbers were
not so efficient as even ones, and that - at design time - it was better to
define even packed numbers (for example 9.0 instead of 8.0).

The simple anwser could be to use 9.0 because it occupies the same storage
as 8.0, but unfotunately it occupies also one more byte in reports, panels,
etc. and - with other values - another byte for one more decimal separator.

Is there any evidence that with RISC processors this is still true?
If so, how much system performances could degrade in case of large files?

-- Giuseppe



_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
or email: MI400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.