|
View previous topic :: View next topic
|
| Author |
Message |
delago
New User
Joined: 29 Jul 2005
Posts: 21
Location: Brazil
|
|
|
|
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 |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
Hariharan Ramachandran
New User
Joined: 30 Nov 2010
Posts: 28
Location: Chennai, Tamilnadu,INDIA
|
|
|
|
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 |
|
|
delago
New User
Joined: 29 Jul 2005
Posts: 21
Location: Brazil
|
|
|
|
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 |
|
|
Hariharan Ramachandran
New User
Joined: 30 Nov 2010
Posts: 28
Location: Chennai, Tamilnadu,INDIA
|
|
|
|
| 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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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. 
FWIW, this is also true for COBOL exponentiation computations. 
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.  |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1054
Location: Richmond, Virginia
|
|
|
|
Rules 1,2,3:
Make your code eminently readable by whoever inherits it from you. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| 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.
FWIW, this is also true for COBOL exponentiation computations. |
Would you recommend a looped multiplication rather than using the exponentiation operator? |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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.
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.
Bill |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 767
Location: Whitby, ON, Canada
|
|
|
|
| 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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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. . . 
d |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Dick, if it doesn't have to be correct, I can make it REAL fast! |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
