Thank you Dan for this answer I have updated my ticket on the support channel with your comment. I have already tried to compile ligmp 6.0.0 but didn't succeed at this time. I'll try again.
Thanks Tore for your answer too. In the present case x86 is on vmware (with many others vm), but zLinux is on a z/VM LPAR alone a CPU is nearly 0%. Best Rgrds. -----Message d'origine----- De : Linux on 390 Port [mailto:[email protected]] De la part de Dan Horák Envoyé : jeudi 4 septembre 2014 12:39 À : [email protected] Objet : Re: zLinux Perf problem with OpenCobol and C and libgmp under RHEL65 On Thu, 4 Sep 2014 09:54:39 +0000 PROT Pierre-François <[email protected]> wrote: > Hello list, > > We have currently migrating part of our production appl from > Unix/Pseries to zLinux/zEC12. We have ported microfocus cobol programs > (previously running on PSeries) on our zEC12/zLinux plateform and > after comparing CPU times on z and on P, it turns out that overall cpu > times (java and oracle) are much better on the Z but it also turns out > that the cpu times for OpenCobol are far worse (although time elapse > treatment remain best on Z). > > As OpenCobol generates a C program from the Cobol source code we > investigated on th C side. After some days of analysis it seems that > on zLinux, the C calls to DLLs are more expensive on z than on x86 or > PSeries architecture. The application of different optimization > options (-O3, march, mtune) does not change the results. Finally, a C > program that does not calls to external modules is much more efficient > on zLinux. Here is our test program with libgmp : > > #include <stdio.h> > #include <stdlib.h> > #include <gmp.h> > > int main(void) > { > mpz_t x; > mpz_t y; > mpz_t result; > > long int i=0; > > while (i++<20000000) > { > > mpz_init(x); > mpz_init(y); > mpz_init(result); > > mpz_set_str(x, "7612058254738945", 10); mpz_set_str(y, > "9263591128439081", 10); > > mpz_mul(result, x, y); > > mpz_clear(x); > mpz_clear(y); > mpz_clear(result); > } > > return EXIT_SUCCESS; > } > > > It was compiled with gcc testgmp.c -lgmp and runned by the command > time ./a.out to obtain CPU times. the results are the following : > zLinux ZEC12/5.5 gHz > real 0m8.930s > user 0m8.802s > sys 0m0.006s > > linux on x86 HP Blade/2.2gHz > real 0m7.464s > user 0m7.438s > sys 0m0.000s > > > > When we make trace on library calls, zlinx seems better : > > zlinux > ltrace -c ./testgmp > % time seconds usecs/call calls function > ------ ----------- ----------- --------- -------------------- > 41.05 95.646614 159 600000 __gmpz_init > 29.01 67.588020 112 600000 __gmpz_clear > 20.27 47.224456 118 400000 __gmpz_set_str > 9.68 22.561771 112 200000 __gmpz_mul > 0.00 0.000058 58 1 > ------ ----------- ----------- --------- -------------------- > 100.00 233.020919 1800001 total > > > linux on x86 > ltrace -c ./testgmp > % time seconds usecs/call calls function > ------ ----------- ----------- --------- -------------------- > 34.49 153.162784 255 600000 __gmpz_init > 32.22 143.106564 238 600000 __gmpz_clear > 25.08 111.395971 278 400000 __gmpz_set_str > 8.21 36.475142 182 200000 __gmpz_mul > 0.00 0.000119 119 1 > ------ ----------- ----------- --------- -------------------- > 100.00 444.140580 1800001 total > > > > > We also conducted tests on Cobol on different zlinux distributions > but the problem seems to be the same for all z platforms. (Results > below: 6m40 for zLinux and 4m23 for x86). On our zLinux, the system > disk / is on CKD devices, so we also conducted a test with the / on > FCP disk to see if the problem could come from CKD disks. The results > is below: there is an improvement in CPU time (6m15 )but still worst > than on x86. RHEL 6.5 on zEC12 (with CKD devices for system) real > 7m5.370s user 6m41.487s sys 0m1.166s RHEL 6.5 on zEC12 with > FCP devices for the system real 7m47.700s > user 6m14.521s > sys 0m1.061s > > CentOS 6.4 on zEC12 > real 11m35.152s > user 6m40.513s > sys 0m1.094s > > Debian 7.4 on zEC12 > real 16m1.261s > user 6m38.751s > sys 0m1.136s > > CentOS 6.4 on x86 > [zadmin@QAVTL318041 ~]$ ps -aef | grep TST > zadmin 19327 19317 90 14:54 pts/0 00:04:22 /TSTPAT/bin/cobcrun > TSTSEQREW real 5m25.090s > user 4m21.355s > sys 0m1.647s > > > We also conducted tests with a recompiled gcc 4.9.1 but results are > the same. > > We finally used the benchmark tool provided by libgmp on our 3 > platerforms and the results are the following : > > RHEL65 zlinux with gmp 4.3.1 : 550.71 > RHEL65 x86 with gmp 4.3.1 : 1960.4 > Debian 7.4 zLinux with gmp 5.0.5 : 1291.9 > > Bench results is 2 times better on debian than on REHL (the hardware > is the same and the zVM guest are the same too) and HP blade 2.2GHz > is also better than zEC125.5GHz :-( It's seems that there is a > problem on RHEL65 s390x with libgmp (and maybe others libs). Does > anyone has always seen this problem or as any ideas on how to solve > this problem ? looking into the gmp sources it seems that 4.3.1 doesn't have a proper support for s390x, so it's not optimized for 64-bit s390 at all, while 5.0.5 already has some. Version 5.1.1 from RHEL-7 is better and version 6.0.0 is even much better, they already contain optimized routines written in assembler. I think this also explains the performance compared to x86/x86_64 as they have optimized routines already in 4.3.1 (and earlier). Please open a request for rebase of gmp via your Red Hat support channel. I don't know whether the rebase is feasible, but we should at least track the problem. Dan ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ***************************************************************************************** Ce message électronique, les éventuels fichiers joints et les informations qu'il contient, peuvent être couverts par le secret professionnel et sont exclusivement adressés à son destinataire. Si vous le recevez par erreur, merci d'en informer l'expéditeur et de le détruire. A ce titre, toute diffusion non autorisée de ce message, même partielle, sous quelque forme que ce soit, est interdite et punie par la loi. En aucun cas, le contenu de ce message ne peut valoir offre ou acceptation ou engagement de la part de la CNAV. Les opinions contenues dans ce message sont personnelles à l'émetteur. Il est de la responsabilité du destinataire de s'assurer que le message et ses éventuelles pièces jointes ne contiennent pas de virus informatique.
