IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

What is more fast: COMPUTE or DIVIDE, ADD, SUBTRACT, MULTIPL


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
delago

New User


Joined: 29 Jul 2005
Posts: 21
Location: Brazil

PostPosted: Fri Dec 10, 2010 11:44 pm
Reply with quote

Hi Guy's.

I tunnig a system in my jobs and it have a lot of arithmetics operations.
One people tell me to change the command COMPUTE for ADD, DIVIDE, MULTIPLY and SUBTRACT, but I don't if is the really better .
What is more faster: COMPUTE or the other arithmetics statements.
Somebody can help me?

Tks.

Fernando Delago - Brazil/SP
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Sat Dec 11, 2010 12:02 am
Reply with quote

Code:
       01  WS-VAR.
           05  WS-A                   PIC S9(04) VALUE 1234.
           05  WS-B                   PIC S9(04) VALUE 4321.
           05  WS-C                   PIC S9(04).
           05  WS-D                   PIC S9(04) COMP VALUE 1234.
           05  WS-E                   PIC S9(04) COMP VALUE 4321.
           05  WS-F                   PIC S9(04) COMP.
           05  WS-G                   PIC S9(04) COMP-3 VALUE 1234.
           05  WS-H                   PIC S9(04) COMP-3 VALUE 4321.
           05  WS-I                   PIC S9(04) COMP-3.
       PROCEDURE DIVISION.
           COMPUTE WS-C = WS-A + WS-B.
           ADD WS-A TO WS-B GIVING WS-C.
           COMPUTE WS-F = WS-D + WS-E.
           ADD WS-D TO WS-E GIVING WS-F.
           COMPUTE WS-I = WS-G + WS-H.
           ADD WS-G TO WS-H GIVING WS-I.
produces pseudo assembler code of
Code:
 000025  COMPUTE
    00035C  F223 D0F8 8000          PACK  248(3,13),0(4,8)        TS2=0
    000362  F223 D100 8004          PACK  256(3,13),4(4,8)        TS2=8
    000368  FA22 D0F8 D100          AP    248(3,13),256(3,13)     TS2=0
    00036E  940F D0F8               NI    248(13),X'0F'           TS2=0
    000372  F822 D0F8 D0F8          ZAP   248(3,13),248(3,13)     TS2=0
    000378  F332 8008 D0F8          UNPK  8(4,8),248(3,13)        WS-C
 000026  ADD
    00037E  F223 D0F8 8004          PACK  248(3,13),4(4,8)        TS2=0
    000384  F223 D100 8000          PACK  256(3,13),0(4,8)        TS2=8
    00038A  FA22 D0F8 D100          AP    248(3,13),256(3,13)     TS2=0
    000390  940F D0F8               NI    248(13),X'0F'           TS2=0
    000394  F822 D0F8 D0F8          ZAP   248(3,13),248(3,13)     TS2=0
    00039A  F332 8008 D0F8          UNPK  8(4,8),248(3,13)        WS-C
 000027  COMPUTE
    0003A0  4820 800E               LH    2,14(0,8)               WS-E
    0003A4  4830 800C               LH    3,12(0,8)               WS-D
    0003A8  1A32                    AR    3,2
    0003AA  4030 8010               STH   3,16(0,8)               WS-F
 000028  ADD
    0003AE  4820 800C               LH    2,12(0,8)               WS-D
    0003B2  4830 800E               LH    3,14(0,8)               WS-E
    0003B6  1A32                    AR    3,2
    0003B8  4030 8010               STH   3,16(0,8)               WS-F
 000029  COMPUTE
    0003BC  D202 8018 8012          MVC   24(3,8),18(8)           WS-I
    0003C2  FA22 8018 8015          AP    24(3,8),21(3,8)         WS-I
    0003C8  940F 8018               NI    24(8),X'0F'             WS-I
    0003CC  F822 8018 8018          ZAP   24(3,8),24(3,8)         WS-I
 000030  ADD
    0003D2  D202 8018 8015          MVC   24(3,8),21(8)           WS-I
    0003D8  FA22 8018 8012          AP    24(3,8),18(3,8)         WS-I
    0003DE  940F 8018               NI    24(8),X'0F'             WS-I
    0003E2  F822 8018 8018          ZAP   24(3,8),24(3,8)         WS-I
so which looks quicker to you?

And the other side of the coin is -- why do you think it matters? Modern machines can run, literally, hundreds of millions of COBOL statements per minute of CPU time. So you'd have to be doing billions upon billions upon billions of arithmetic operations for any difference to be really noticeable. The code algorithms are going to make much more difference in your end results than picking the "faster" computational method.
Back to top
View user's profile Send private message
Hariharan Ramachandran

New User


Joined: 30 Nov 2010
Posts: 28
Location: Chennai, Tamilnadu,INDIA

PostPosted: Sat Dec 11, 2010 12:23 am
Reply with quote

Delago,

When you need to combine arithmetic operations, using the COMPUTE statement may be more efficient than writing a series of separate arithmetic statements. Because it allows you to combine arithmetic operations without the restrictions on receiving data items that the rules for the ADD, SUBTRACT, MULTIPLY, and DIVIDE statements impose.

Kind Regards,
Hari
Back to top
View user's profile Send private message
delago

New User


Joined: 29 Jul 2005
Posts: 21
Location: Brazil

PostPosted: Sat Dec 11, 2010 12:28 am
Reply with quote

Robert, Hariharan,

Thank's a lot my friends.
Now I know what do.
Simplify the life.

Tks again.

Fernando Delago - Brazil/SP
Back to top
View user's profile Send private message
Hariharan Ramachandran

New User


Joined: 30 Nov 2010
Posts: 28
Location: Chennai, Tamilnadu,INDIA

PostPosted: Sat Dec 11, 2010 12:28 am
Reply with quote

Quote:
So you'd have to be doing billions upon billions upon billions of arithmetic operations for any difference to be really noticeable
.

As Robby said changing computational method is not goin to show any great performance.

Kind Regards,
Hari
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Sat Dec 11, 2010 12:52 am
Reply with quote

Try to avoid (unless absolutely necessary) computations on doubleword-binary (an unfriendly format for COBOL), PIC 9(10) through PIC 9(18) COMP/COMP-4/BINARY.

Even if your compiler supports COMP-5, it is suggested to limit doubleword-binary computation usage.

In some cases of doubleword-binary computations, the compiler may very well resolve to calling a COBOL run-time routine, instead of resolving in-line. icon_confused.gif

FWIW, this is also true for COBOL exponentiation computations. icon_eek.gif

Bill

PS: I said to my Doctor "When I hit my hand with this hammer, it hurts". His reply "Then don't do that!". IMHO, this same idea applies to doubleword-binary usage in COBOL. icon_wink.gif
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia

PostPosted: Sat Dec 11, 2010 1:09 am
Reply with quote

Rules 1,2,3:

Make your code eminently readable by whoever inherits it from you.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Sat Dec 11, 2010 1:14 am
Reply with quote

Bill O'Boyle wrote:
In some cases of doubleword-binary computations, the compiler may very well resolve to calling a COBOL run-time routine, instead of resolving in-line. icon_confused.gif

FWIW, this is also true for COBOL exponentiation computations. icon_eek.gif

Would you recommend a looped multiplication rather than using the exponentiation operator?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Sat Dec 11, 2010 1:58 am
Reply with quote

Akatsukami asked -
Quote:

Would you recommend a looped multiplication rather than using the exponentiation operator?

Yes, instead of -

Code:

03  WS-RESULT PIC  9(18) COMP.
03  WS-BASE   PIC  9(18) COMP VALUE 2.

COMPUTE WS-RESULT = (WS-BASE ** 8).

Calculate the exponent ahead of time and issue a straight multiply -

Code:

COMPUTE WS-RESULT = (WS-BASE * 128).

For small exponents, a loop multiply would suffice.

But, keep in mind that regardless of the data-type, which could also be packed-decimal, display-numeric, binary-halfword or binary-fullword, COBOL deals with exponentiation via a run-time routine. icon_eek.gif

Enterprise PL/I deals with 64-Bit (Doubleword) Arithmetic much better than COBOL as the PL/I compile folks utilize the more modern Assembler "Grande" instructions for in-line computations, such as "LG" (Load Grande), "AG" (Add Grande), CVDG ("Convert to Decimal Grande"), etc, which all use 64-Bit registers.

Although I haven't worked with it for nearly 30 years, PL/I has always been ahead of the curve when utilizing newer techniques. IMHO, a superior HLL to that of COBOL. icon_wink.gif

Bill
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Tue Dec 14, 2010 10:54 pm
Reply with quote

According to the latest Enterprise Cobol Performance Tuning Guide , floating-point is much faster than fixed point (up to 98%) when you are doing exponentiation. I have not verified this but it's interesting.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Dec 15, 2010 12:59 am
Reply with quote

Hello,

Quote:
floating-point is much faster than fixed point
Which leads to the old question:

Does it need to be correct or does it need to be fast. . . icon_cool.gif

d
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Wed Dec 15, 2010 2:30 am
Reply with quote

Dick, if it doesn't have to be correct, I can make it REAL fast!
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts A way to see a particular file fast w... TSO/ISPF 10
No new posts Divide and edit the sum - OutRec DFSORT/ICETOOL 5
No new posts Compute statement with Cobol Z/os 5.2 COBOL Programming 2
No new posts Subtract the ZD fields to provide neg... DFSORT/ICETOOL 4
No new posts Compare two files and subtract values DFSORT/ICETOOL 7
Search our Forums:

Back to Top