On Thu, Apr 7, 2011 at 12:47 PM, McKown, John <[email protected]> wrote: >> -----Original Message----- >> From: IBM Mainframe Assembler List >> [mailto:[email protected]] On Behalf Of Edward Jaffe >> Sent: Thursday, April 07, 2011 2:21 PM >> To: [email protected] >> Subject: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!) >> >> On 4/7/2011 9:42 AM, Angel Luis Domínguez wrote: >> > On Thu, 7 Apr 2011 14:32:56 +0300, Binyamin Dissen >> > <[email protected]> wrote: >> >> LE will LOAD the module on the first call and then BALR >> the later calls. >> >> Change your ASM module to LOAD it and BALR as well. >> > I did it and now the results are for the same work in cpu seconds >> > >> > ASSEMBLER: 10,584402 versus COBOL: 15,438726 >> >> I keep attending IBM presentations that assert the code >> generated by the C >> compiler will outperform assembler. Some programmers I >> respect have asserted the >> same thing. Every time I look into this I see the wonders of >> the C compiler's >> optimizer--which understands cache effects and how to best >> use the System z >> instruction pipe line. >> >> Empirically, however, I have yet to find a program written in >> C or any other >> language that can actually outperform a well-written >> assembler language program. >> Every time I think I've finally found the example that proves >> these assertions, >> it turns out the assembler program is doing something >> inefficient (like this >> case with LOADing a service module over and over) and, once >> fixed the assembler >> language program runs faster. >> >> Is it just me?? >> >> -- >> Edward E Jaffe > > The statement, at least as phrased, is obviously false. Why? Because all > compilers generate "assembler code". OK, not assembler source code, but z > instructions. Which can be duplicated by using HLASM. Of course, what is > meant is more along the lines of: "The C compiler will consistently produce > better performing programs than even a good HLASM programmer can consistently > write." That statement may be true. An excellent HLASM program may produce > code which is as good or better than the C compiler in a specific case. > Perhaps even in every possible case. But it is very likely that code will > take longer to write and debug. Therefore it is more expensive code. Also, > the HLASM code may need to be revised on a new z box due to changes in box's > implementation of the z architecture. Once the C backend generator is > updated, the C code can more likely just be recompiled, as is, to get a > performance boost. So C is once again "superior" to HLASM in more cases where > either can be used. ! "E! > ach to his own". Personally, if we had the C compiler, I'd use it in > preference to HLASM. >
Agreed with above > Of course, C programmers, as a general class, are not as good as HLASM > programmers in designing and implementing algorithms. And a poor algorithm in > any language will perform poorly. So I would wager that it is more likely > that a randomly selected HLASM program will perform better than a randomly > selected C program which does an equivalent function. > It is a non-sequitur to say knowing a certain programing language makes you better at designing and implementing algorithms. Analysis of algorithms is more of a mathematical endeavor than a language endeavor. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets® > > 9151 Boulevard 26 . N. Richland Hills . TX 76010 > (817) 255-3225 phone . > [email protected] . www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. HealthMarkets® is the brand name for products underwritten and > issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake > Life Insurance Company®, Mid-West National Life Insurance Company of > TennesseeSM and The MEGA Life and Health Insurance Company.SM >
