Re: Odd/Even packed numbers.

Hi  Kaare,

 I posted the same on MidrangeL and I also added:

>apart from rough testing . . . I don't have rights to use sst and not even
>enough knowledge about RISC instructions, but maybe it could be interesting
>to compare how both versions are compiled to see if there are some machine
>instruction added to fix the missing NIBBLE.

you gave me the answer that I was lookink for.

Thanks.

-- Giuseppe



----- Original Message -----
From: "Kaare Plesner, SOSY A/S" <kaaple@attglobal.net>
To: <mi400@midrange.com>
Sent: Thursday, November 28, 2002 8:21 PM
Subject: RE: [MI400] 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.
>
> _______________________________________________
> 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.
>
>