-------- Forwarded Message --------
Subject: Re: A not very Christmassy PL/I tale
Date: Sun, 25 Dec 2016 18:13:55 -0500
From: Charles Mills <[email protected]>
Reply-To: PL1 (language) discussions <[email protected]>
To: [email protected]
> the speed of the machine seems to obviate the need to write a good compiler.
Au contraire. Moore's law is over. Machines are not getting faster and have not
been for several generations. The need for good machine code has never been more
critical.
/Charles/
Sent from a mobile; please excuse the brevity.
-------- Original message --------
From: Tom Linden <[email protected]>
Date: 12/25/16 4:54 PM (GMT-05:00)
To: [email protected]
Subject: Re: A not very Christmassy PL/I tale
Is the PL/I code gen shared with other front-ends? I fear one point you
made is true, viz., the speed of the machine seems to obviate the need to
write a good compiler. This looks pretty amateurish. When machines were
slow, like 40 years ago, we did software engineering,
On Sun, Dec 25, 2016 at 1:34 PM, Bernd Oppolzer <[email protected]>
wrote:
> Cross-posted to the PL/1 list
>
>
>
> Hi Robert,
>
> IMO this is a valid and remarkable observation, but I don't believe that
> anybody in the companies that use PL/1 heavily will take much care of it.
>
> Because:
>
> a) there is no time to analyze the outcome of the compiler in such depth,
> that it could lead to recommendations or requests to IBM for changes
> (I wish, I would get the time to do that)
>
> b) the new machines are so fast that they tolerate this additional load
> which comes from "suboptimal" compilers
>
> c) if comparisons of performance are done, then between subsequent
> releases, but not with compilers that old; most companies will not be
> able to run those comparisons
>
> d) there would be some pressure to act for IBM, if there was some sort
> of competition; but regarding PL/1, there is no competition
>
> Most companies running PL/1 and their IT departments are loaded with
> other requirements and simply have no time to care about performance
> issues;
>
> if they do, they try to repair things locally or improve the logic of
> the application
> or the DB2 side or some other problem areas (there could be many); but IMO
> no one will look at the outcome of the compiler, under normal
> circumstances.
>
> Another look at the scene:
>
> regarding the competition between PL/1 / mainframe and (for example)
> Java / other platforms, the mainframe normally looks good regarding
> performance, availability and other indicators, in spite of possible
> problems
> of the PL/1 code generator. The mainframe should win this competition,
> but it will probably lose anyway, because of
>
> a) skill problems (specialists are too old, no young people available)
>
> b) IT managers are not aware of or don't like the mainframe platform
>
> That's just my private opinion
>
> Kind regards,
> have a good christmas time
>
> Bernd
>
>
>
> Am 25.12.2016 um 20:40 schrieb Robert Prins:
>
>> Hi all,
>>
>> Apologies for this rant on Christmas day...
>>
>> Let's assume you gate-crash an IBM GSE meeting, way back in 2010 and
>> talk to an IBM developer about optimizing code, and he tells you that
>> IBM is well ahead (by "at least" five years) of the Open Source
>> community!
>>
>> So on this Christmas day you decide, having nothing better to do than
>> to listen to your relatives blabbering away in Lithuanian, the
>> language of your wife of fifteen years, but a language that you still
>> do not speak, to look at some more code emitted by, admittedly not the
>> latest and greatest of IBM's Enterprise PL/I compilers (V4.3.0), and
>> compare that to the code of the long out-of-support V2.3.0 OS compiler.
>>
>> Now, you've already had, more than once, discussions with one of its
>> lead-developers about the quality of code emitted by the EPLI backend
>> after earlier remarks that it looks pretty bad, but with said
>> developer having access to the latest technology, there's little you
>> can put up against his arguments, although a claim that a loop to
>> initialize a PL/I array is faster than using MVC or overlapping MVC on
>> the latest z13 systems still makes you wonder.
>>
>> So in stead, lets look at some very simple PL/I code, a very
>> frequently called routine that calculates average times based on two
>> inputs, seconds and a divisor, which should result in some pretty
>> simple assembler code.
>>
>> Here is the output of the compiler, and lets start with the code
>> generated by the old OS compiler, and for what it's worth, w_hh and
>> w_mm are defined externally as "fixed dec (3)"
>>
>> 3829 AVERAGE_TIME: PROC(SECONDS, N);
>> 3830 DCL SECONDS FIXED DEC (15,6);
>> 3831 DCL N FIXED DEC (5);
>> 3833 DCL D FIXED DEC (9);
>> 3834 DCL S FIXED DEC (15,6) INIT (SECONDS);
>>
>> 3841 W_HH = TRUNC(SECONDS / (N * 3600));
>> 3842 SECONDS = SECONDS - W_HH * (N * 3600);
>> 3843 W_MM = TRUNC(SECONDS / (N * 60));
>> 3844 SECONDS = SECONDS - W_MM * (N * 60);
>>
>> And I've added this code, to help the compiler eliminate common
>> sub-expressions, as the V2.3.0 compiler wasn't all that optimizing,
>> especially for large programs, as indicated by these two messages:
>>
>> IEL0919I W 2105 VARIABLES IN PROGRAM. GLOBAL OPTIMIZATION PERFORMED
>> FOR 255 VARIABLES. LOCAL OPTIMIZATION PERFORMED ON REMAINDER.
>> IEL0917I W 1 BLOCK CONTAINS 424 FLOW UNITS. GLOBAL OPTIMIZATION
>> PERFORMED ONLY IN 'DO' GROUPS.
>>
>> 3847 D = N * 3600;
>> 3848 W_HH = TRUNC(S / D);
>> 3849 S = S - W_HH * D;
>> 3850 D = N * 60;
>> 3851 W_MM = TRUNC(S / D);
>> 3852 S = S - W_MM * D;
>>
>> And what comes out, slightly edited (removal of spaces and flowing
>> code on single lines) to show statement and generated code next to
>> each other:
>>
>> 3841 W_HH = TRUNC(SECONDS / (N * 3600));
>> * STATEMENT NUMBER 3841
>> 01D7E0 58 40 D 0D4 L 4,212(0,13)
>> 01D7E4 F8 52 D 098 4 000 ZAP WKSP.78+32(6),N(3)
>> 01D7EA FC 52 D 098 8 BDD MP WKSP.78+32(6),3037(3,8)
>> 01D7F0 D2 05 D 128 D 098 MVC 296(6,13),WKSP.78+32
>> 01D7F6 58 90 D 0D0 L 9,208(0,13)
>> 01D7FA F8 D7 D 098 9 000 ZAP WKSP.78+32(14),SECONDS(8)
>> 01D800 FD D5 D 098 D 128 DP WKSP.78+32(14),296(6,13)
>> 01D806 D2 07 D 12E D 098 MVC 302(8,13),WKSP.78+32
>> 01D80C 58 70 6 0CC L 7,204(0,6)
>> 01D810 D2 01 7 57C D 131 MVC LIFT_WORK.WT_AVG.W_HH(2),305(13)
>> 01D816 D1 00 7 57D D 135 MVN LIFT_WORK.WT_AVG.W_HH+1(1),309(13)
>>
>> 3842 SECONDS = SECONDS - W_HH * (N * 3600);
>> * STATEMENT NUMBER 3842
>> 01D81C F8 52 D 098 4 000 ZAP WKSP.78+32(6),N(3)
>> 01D822 FC 52 D 098 8 BDD MP WKSP.78+32(6),3037(3,8)
>> 01D828 D2 05 D 128 D 098 MVC 296(6,13),WKSP.78+32
>> 01D82E F8 71 D 098 7 57C ZAP WKSP.78+32(8),LIFT_WORK.WT_AVG.W_HH(2)
>> 01D834 FC 75 D 098 D 128 MP WKSP.78+32(8),296(6,13)
>> 01D83A D2 07 D 12E D 098 MVC 302(8,13),WKSP.78+32
>> 01D840 D2 07 D 098 D 12E MVC WKSP.78+32(8),302(13)
>> 01D846 94 F0 D 09F NI WKSP.78+39,X'F0'
>> 01D84A D7 02 D 0A0 D 0A0 XC WKSP.78+40(3),WKSP.78+40
>> 01D850 D1 00 D 0A2 D 135 MVN WKSP.78+42(1),309(13)
>> 01D856 FB A7 D 098 9 000 SP WKSP.78+32(11),SECONDS(8)
>> 01D85C F8 7A D 09B D 098 ZAP WKSP.78+35(8),WKSP.78+32(11)
>> 01D862 97 01 D 0A2 XI WKSP.78+42,X'01'
>> 01D866 D2 07 9 000 D 09B MVC SECONDS(8),WKSP.78+35
>>
>> 3843 W_MM = TRUNC(SECONDS / (N * 60));
>> * STATEMENT NUMBER 3843
>> 01D86C F8 42 D 098 4 000 ZAP WKSP.78+32(5),N(3)
>> 01D872 FC 41 D 098 8 91B MP WKSP.78+32(5),2331(2,8)
>> 01D878 D2 04 D 128 D 098 MVC 296(5,13),WKSP.78+32
>> 01D87E F8 C7 D 098 9 000 ZAP WKSP.78+32(13),SECONDS(8)
>> 01D884 FD C4 D 098 D 128 DP WKSP.78+32(13),296(5,13)
>> 01D88A D2 07 D 12D D 098 MVC 301(8,13),WKSP.78+32
>> 01D890 D2 01 7 57F D 130 MVC LIFT_WORK.WT_AVG.W_MM(2),304(13)
>> 01D896 D1 00 7 580 D 134 MVN LIFT_WORK.WT_AVG.W_MM+1(1),308(13)
>>
>> 3844 SECONDS = SECONDS - W_MM * (N * 60);
>> * STATEMENT NUMBER 3844
>> 01D89C F8 42 D 098 4 000 ZAP WKSP.78+32(5),N(3)
>> 01D8A2 FC 41 D 098 8 91B MP WKSP.78+32(5),2331(2,8)
>> 01D8A8 D2 04 D 128 D 098 MVC 296(5,13),WKSP.78+32
>> 01D8AE F8 61 D 098 7 57F ZAP WKSP.78+32(7),LIFT_WORK.WT_AVG.W_MM(2)
>> 01D8B4 FC 64 D 098 D 128 MP WKSP.78+32(7),296(5,13)
>> 01D8BA D2 06 D 12D D 098 MVC 301(7,13),WKSP.78+32
>> 01D8C0 D2 06 D 098 D 12D MVC WKSP.78+32(7),301(13)
>> 01D8C6 94 F0 D 09E NI WKSP.78+38,X'F0'
>> 01D8CA D7 02 D 09F D 09F XC WKSP.78+39(3),WKSP.78+39
>> 01D8D0 D1 00 D 0A1 D 133 MVN WKSP.78+41(1),307(13)
>> 01D8D6 FB 97 D 098 9 000 SP WKSP.78+32(10),SECONDS(8)
>> 01D8DC F8 79 D 09A D 098 ZAP WKSP.78+34(8),WKSP.78+32(10)
>> 01D8E2 97 01 D 0A1 XI WKSP.78+41,X'01'
>> 01D8E6 D2 07 9 000 D 09A MVC SECONDS(8),WKSP.78+34
>>
>> 3847 D = N * 3600;
>> * STATEMENT NUMBER 3847
>> 01D976 F8 52 D 098 4 000 ZAP WKSP.78+32(6),N(3)
>> 01D97C FC 52 D 098 8 BDD MP WKSP.78+32(6),3037(3,8)
>> 01D982 D2 04 D 0C0 D 099 MVC D(5),WKSP.78+33
>>
>> 3848 W_HH = TRUNC(S / D);
>> * STATEMENT NUMBER 3848
>> 01D988 F8 C7 D 098 D 0B8 ZAP WKSP.78+32(13),S(8)
>> 01D98E FD C4 D 098 D 0C0 DP WKSP.78+32(13),D(5)
>> 01D994 D2 07 D 128 D 098 MVC 296(8,13),WKSP.78+32
>> 01D99A D2 01 7 57C D 12B MVC LIFT_WORK.WT_AVG.W_HH(2),299(13)
>> 01D9A0 D1 00 7 57D D 12F MVN LIFT_WORK.WT_AVG.W_HH+1(1),303(13)
>>
>> 3849 S = S - W_HH * D;
>> * STATEMENT NUMBER 3849
>> 01D9A6 F8 61 D 128 7 57C ZAP 296(7,13),LIFT_WORK.WT_AVG.W_HH(2)
>> 01D9AC FC 64 D 128 D 0C0 MP 296(7,13),D(5)
>> 01D9B2 D7 0A D 098 D 098 XC WKSP.78+32(11),WKSP.78+32
>> 01D9B8 D2 06 D 099 D 128 MVC WKSP.78+33(7),296(13)
>> 01D9BE 94 F0 D 09F NI WKSP.78+39,X'F0'
>> 01D9C2 D1 00 D 0A2 D 12E MVN WKSP.78+42(1),302(13)
>> 01D9C8 FB A7 D 098 D 0B8 SP WKSP.78+32(11),S(8)
>> 01D9CE F8 7A D 09B D 098 ZAP WKSP.78+35(8),WKSP.78+32(11)
>> 01D9D4 97 01 D 0A2 XI WKSP.78+42,X'01'
>> 01D9D8 D2 07 D 0B8 D 09B MVC S(8),WKSP.78+35
>>
>> 3850 D = N * 60;
>> * STATEMENT NUMBER 3850
>> 01D9DE F8 42 D 0C0 4 000 ZAP D(5),N(3)
>> 01D9E4 FC 41 D 0C0 8 91B MP D(5),2331(2,8)
>>
>> 3851 W_MM = TRUNC(S / D);
>> * STATEMENT NUMBER 3851
>> 01D9EA F8 C7 D 098 D 0B8 ZAP WKSP.78+32(13),S(8)
>> 01D9F0 FD C4 D 098 D 0C0 DP WKSP.78+32(13),D(5)
>> 01D9F6 D2 07 D 128 D 098 MVC 296(8,13),WKSP.78+32
>> 01D9FC D2 01 7 57F D 12B MVC LIFT_WORK.WT_AVG.W_MM(2),299(13)
>> 01DA02 D1 00 7 580 D 12F MVN LIFT_WORK.WT_AVG.W_MM+1(1),303(13)
>>
>> 3852 S = S - W_MM * D;
>> * STATEMENT NUMBER 3852
>> 01DA08 F8 61 D 128 7 57F ZAP 296(7,13),LIFT_WORK.WT_AVG.W_MM(2)
>> 01DA0E FC 64 D 128 D 0C0 MP 296(7,13),D(5)
>> 01DA14 D7 0A D 098 D 098 XC WKSP.78+32(11),WKSP.78+32
>> 01DA1A D2 06 D 099 D 128 MVC WKSP.78+33(7),296(13)
>> 01DA20 94 F0 D 09F NI WKSP.78+39,X'F0'
>> 01DA24 D1 00 D 0A2 D 12E MVN WKSP.78+42(1),302(13)
>> 01DA2A FB A7 D 098 D 0B8 SP WKSP.78+32(11),S(8)
>> 01DA30 F8 7A D 09B D 098 ZAP WKSP.78+35(8),WKSP.78+32(11)
>> 01DA36 97 01 D 0A2 XI WKSP.78+42,X'01'
>> 01DA3A D2 07 D 0B8 D 09B MVC S(8),WKSP.78+35
>>
>> L : 3
>> ZAP : 18
>> MP : 10
>> MVC : 23
>> DP : 4
>> MVN : 8
>> NI : 4
>> XC : 4
>> XI : 4
>> SP : 4
>> ---
>> 82 instructions, 470 bytes of code
>>
>> And obviously common-subexpression elimination didn't make it, or, as
>> the above messages indicated, the source was simply too complex, this
>> is a procedure in a 13+K lines PL/I program.
>>
>> Jump forward two (or even more) decades to 2014-03-10, the version of
>> Enterprise PL/I V4.3.0 on the system where this test was done, and weep?
>>
>> 11200.0 average_time: proc(seconds, n);
>> 11201.0 dcl seconds fixed (15,6);
>> 11202.0 dcl n fixed (5);
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
