2 Replies Latest reply on Aug 22, 2014 8:45 AM by lejeczek

    gcc 4.8.2 (rhel 7) regresses R with ACML (5.3.1, 6.0) ?

    lejeczek

      hi

      wanted to ask if you tried R+ACML on RHEL 7 or derivatives?

      R+ACML compiled by gcc 4.7.2 (not default) on RHEL 6.5 is pretty! fast

      same both R+ACML on RHEL 7 with default compiler suite (4.8.2) is a disaster!!

      thanks

        • Re: gcc 4.8.2 (rhel 7) regresses R with ACML (5.3.1, 6.0) ?
          kknox

          Hi lejeczek~

           

          I'm sorry to say that we have not tested ACML with R in our labs.  Can you confirm that R+ACML compiled by gcc 4.7.2 (not default) on RHEL 6.5 works with both acml 5.3.1 & 6.0?  And it breaks with both on gcc 4.8.2?  Is this a functionality break or a performance break?

            • Re: gcc 4.8.2 (rhel 7) regresses R with ACML (5.3.1, 6.0) ?
              lejeczek

              hi,

              yes, I have a such a setup on rhel (to be specific Scientific Linux) 6.5 with gcc 4.7.2 and compilation runs find and resulted binaries perform quite well.

              but!! there is more immediate problem!

               

              I've been poking around R users (and devel) list and there seem to be a general notion that ACML is pretty bad in some respects. I shared my finding with MKL advocates over there which were that R+ACML was almost (still sad and you know why) as fast as MKL. Durring my fiddling and tampering I discovered that there was BLAS problem with R (I even reported it here) - on R-devel list search for "blas test problem" and a bug report to Redhat I submitted.

              from R developers:

              "......

              I can reproduce this. It is a bug in reference BLAS.

               

              With the R 3.1.0 release, Fedora changed from using the internal BLAS

              that comes with R to using external BLAS. But reference BLAS does not

              handle missing values correctly. I expect this has been true since at

              least 2010, when Brian patched the R copy of BLAS, but the bug has only

              been revealed by the Fedora policy change.

               

              I am taking this over to R-SIG-Fedora where we can discuss the issue

              with Tom Callaway from Red Hat.

              ..... "

               

              it seems this has been fixed:

              * Wed May 07 2014 Tom Callaway <spot@fedoraproject.org> - 3.1.0-5

              - add blas-devel and lapack-devel as Requires for R-devel/R-core-devel

                to ease rebuild pain

              plus blas and lapack developers also responded and fix their ends

               

              and now!!

              R compilation on RHEL 7.0 (probably 6.x too) with ACML fails:

               

              unning code in 'reg-IO2.R' ... OK

                comparing 'reg-IO2.Rout' to './reg-IO2.Rout.save' ... OK

              running code in 'reg-plot.R' ... OK

                comparing 'reg-plot.pdf' to './reg-plot.pdf.save' ... OK

              running code in 'reg-S4.R' ... OK

                comparing 'reg-S4.Rout' to './reg-S4.Rout.save' ... OK

              running code in 'reg-BLAS.R' ...make[3]: *** [reg-BLAS.Rout] Error 1

              make[3]: Leaving directory `/__.aLocalStorages/lv.0/__.amyRPMbuild/os.generic/build/R-3.1.1/tests'

              make[2]: *** [test-Reg] Error 2

              make[2]: Leaving directory `/__.aLocalStorages/lv.0/__.amyRPMbuild/os.generic/build/R-3.1.1/tests'

              make[1]: *** [test-all-basics] Error 1

              make[1]: Leaving directory `/__.aLocalStorages/lv.0/__.amyRPMbuild/os.generic/build/R-3.1.1/tests'

              make: *** [check] Error 2

               

               

              guys, can I say this, thoughts and friendly advice

              can we give your bosses, people on the top of the ladder the sack? We are quite frustrated at times and we have lot of AMD hardware (servers) and we see AMD struggle not knowing what to do just like a headless chicken.

              Now friendly advice, here not only cheap games but scientific applications you should keep on par with present and the future. Many examples, a few: it must NOT be that you have libs that don't work on gee.. extremely popular enterprise Linux distos and users in order to use it have to heavily interfere with the software stack, like rhel 6.x and derivatives cannot take advantage of your ACML - what? science on laptop with Fedora - sure but mostly only for fun.

              All major open source scientific software AMD must make sure it all works smoothly, I'd start with R if were you - otherwise they will bury you all those Intel (and now! other vendors) fans and proponents. 

              And then even those who my like/prefer AMD will have to give in.

               

              Let me know if you need me to do anything, provide any more info, though my finding/results are easily reproducible I am happy to help in any way I can.

               

              p.s. suggestion - let the post go public so people can read it and give their support, also vocally, there should be few.