|
From: | Brian Tiffin |
Subject: | Re: [open-cobol-list] openCobol performances issues |
Date: | Fri, 12 Sep 2014 23:25:20 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 |
Michael D. Setzer II wrote:
On 12 Sep 2014 at 17:00, Sergey Kashyrin wrote: Date sent: Fri, 12 Sep 2014 17:00:07 -0400 From: Sergey Kashyrin <address@hidden> To: "Michael D. Setzer II" <address@hidden>, ARCHAMBAULT Philippe <address@hidden>, "address@hidden" <address@hidden> Subject: Re: [open-cobol-list] openCobol performances issuesHi, Try cobc -O2 -std=ibm ... There is some COMP-4 optimization there. -std=mf should also work. You can look at the difference in C code COMP-5 should also work well in any mode. Regards, SergeyOriginal with COMP-5 time ./coblooporg +200000000 real 0m0.015s user 0m0.000s sys 0m0.001s With -std=ibm time ./coblooporg +0200000000 real 0m0.190s user 0m0.188s sys 0m0.000s with -std=mf time ./coblooporg +0200000000 real 0m0.194s user 0m0.186s sys 0m0.002s But the binary-c-long signed is fastest so far time ./cobloop +00000000000200000000 real 0m0.002s user 0m0.001s sys 0m0.000s Still not clear while the original takes so much longer? time ./coblooporg +200000000 real 0m15.802s user 0m15.733s sys 0m0.000s
Not sure if this is relevant, as 200 million shouldn't trip this, but see http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=1348&forum=1&viewmode=flat&order=ASC&start=0
There is more details in the thread, but there is a huge performance penalty if a loop variable ever gets treated as a cob_field and not native. Same goes for field access.
And maybe?The default endian for GNU Cobol is big. Intel suffers with big-endian. Every access has to be tested for need to flip.
Huge gains from little-endian in the .conf files, when appropriate.One cost would be head scratching during network transfers, but it can be a boon for math heavy runs.
Cheers, Brian
On 9/12/2014 4:46 PM, Michael D. Setzer II wrote:On 12 Sep 2014 at 13:47, ARCHAMBAULT Philippe wrote: From: ARCHAMBAULT Philippe <address@hidden> To: "address@hidden" <address@hidden> Date sent: Fri, 12 Sep 2014 13:47:52 +0000 Subject: [open-cobol-list] openCobol performances issuesHello,We are migrating from Pseries to Zseries zLinux (redhat 6.4) and from MicrofocusCobol to GNUCobol 1.1, and on certains programs we see bad CPU PerformanceFor examples this kind of test: Loop on add 1 to a variable define in PIC S9(09) binary we see:AIX MFCobol 0,960 sec cpu / linux OCobol 16,411 sec CPUSame test on pic s9(03), pic 9(07), pic 9(10) Packed decimal, pic9(09) comp-5 do sameresults…Same result on xLinux (rh 6.4) on HPBlade sample program: IDENTIFICATION DIVISION.PROGRAM-ID. TESTCOB. ENVIRONMENT DIVISION. CONFIGURATION SECTION. INPUT-OUTPUT SECTION. DATA DIVISION. WORKING-STORAGE SECTION. 01 NumericArea. 02 nums99 pic s9(09) binary. PROCEDURE DIVISION. DEBUT-PROGRAMME. move 0 to nums99 PERFORM 200000000 TIMES add 1 to nums99 end-perform. stop run.Any ideas ?Did some quick testing, and found this? Used Linux machine. Original program compiled on machine (added display at end). IDENTIFICATION DIVISION. PROGRAM-ID. TESTCOB. ENVIRONMENT DIVISION. CONFIGURATION SECTION. INPUT-OUTPUT SECTION. DATA DIVISION. WORKING-STORAGE SECTION. 01 NumericArea. 02 nums99 pic s9(09) binary. PROCEDURE DIVISION. DEBUT-PROGRAMME. move 0 to nums99 PERFORM 200000000 TIMES add 1 to nums99 end-perform. Display nums99. stop run. cobc -x -O2 coblooporg.cbl time ./coblooporg +200000000 real 0m15.862s user 0m15.769s sys 0m0.003s Just changed variable definition < 02 nums99 pic s9(09) binary. ---02 nums99 binary-c-long signed.cobc -x -O2 cobloop.cbl time ./cobloop +00000000000200000000 real 0m0.002s user 0m0.000s sys 0m0.001s So, originaly got a speed like your 16 seconds, but after that one minor change got a much better time??+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:address@hidden mailto:address@hidden http://www.guam.net/home/mikes Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) address@hidden CREDITS ROSETTA 19616734.793850 | SETI 33119292.390468 ABC 16613838.513356 | EINSTEIN 32606373.008230 ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ open-cobol-list mailing list address@hidden https://lists.sourceforge.net/lists/listinfo/open-cobol-list+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:address@hidden mailto:address@hidden http://www.guam.net/home/mikes Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) address@hidden CREDITS ROSETTA 19616734.793850 | SETI 33119292.390468 ABC 16613838.513356 | EINSTEIN 32606373.008230 ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ open-cobol-list mailing list address@hidden https://lists.sourceforge.net/lists/listinfo/open-cobol-list
[Prev in Thread] | Current Thread | [Next in Thread] |