4 Replies Latest reply on Dec 16, 2014 4:31 AM by bugchucker

    ACML_LOG_FILTER not recognized anymore by version 6.1.0.31

    bugchucker

      Hello everybody,

       

      it seems that the most recent version of ACML(v6.1.0.31)  does not

      respect the ACML_LOG_FILTER environment variable anymore.

       

      Is there another way to get run-time information?

       

       

      Regards,

       

      bugchucker

        • Re: ACML_LOG_FILTER not recognized anymore by version 6.1.0.31
          timmy.liu

          Hello,

           

          I will copy the answer from the release note.

          "

          Renamed the environmnet variable ACML_LOG_FILTER to ACML_TRACE_TYPE, which can take a number

              to control logging.  Undefined or 0 disables logging, 1 logs to a file, and 2 logs to

              the console.  ACML_TRACE_FLUSH can be set to a non 0 number to force the logger to

              flush all output immediately.

          "

           

          Sorry about the inconvenience!

           

          Timmy

            • Re: ACML_LOG_FILTER not recognized anymore by version 6.1.0.31
              bugchucker

              Timmy,

               

              thanks for the info, I didn't see that one.

              I just checked the library for symbols, and the ACML_LOG_FILTER was still there .

               

              At a first glance, there seems to be less debug output. Would it be possible to

              increase the verbosity level somehow again?

               

              In addition to the cgemm segfault when using acml_mp mentioned in the release notes,

              in my tests also sgemm and dgemm crashed.

              Switching off the multi-threaded code via OMP_NUM_THREADS=1 helped.

               

              Having a quick look through the default Spectre files, the BLAS level2 routines (gemv, symv)

              are always kept on the cpu now. Could you comment on this?

               

              Regards,

               

              bugchucker

                • Re: ACML_LOG_FILTER not recognized anymore by version 6.1.0.31
                  timmy.liu

                  Hi,

                   

                  ACML_LOG_FILTER is deprecated. I am afraid for this release it is not possible to get more information than what have already returned. But it should give you the information whether the computation was offload to CPU or GPU. Can you elaborate what other debug info you would like to see in the future?

                   

                  The reason for keeping gemv and symv offloading to CPU was purely based on performance evaluation. We found that on Kaveri system, the CPU implementation on gemv and symv (which are O(n2) routines) are always faster than the GPU computation. But for other hardware combination, it is possible at certain size the gemv/symv implementation on the GPU out performs.

                   

                  Timmy

                    • Re: ACML_LOG_FILTER not recognized anymore by version 6.1.0.31
                      bugchucker

                      Timmy Liu wrote:

                       

                      Hi,

                       

                      ACML_LOG_FILTER is deprecated. I am afraid for this release it is not possible to get more information than what have already returned. But it should give you the information whether the computation was offload to CPU or GPU. Can you elaborate what other debug info you would like to see in the future?

                       

                      In addition to the information given it would be nice to know which kernel is being called, as well as information about the memory allocation/usage.

                       

                      Timmy Liu wrote:

                       

                      The reason for keeping gemv and symv offloading to CPU was purely based on performance evaluation. We found that on Kaveri system, the CPU implementation on gemv and symv (which are O(n2) routines) are always faster than the GPU computation. But for other hardware combination, it is possible at certain size the gemv/symv implementation on the GPU out performs.

                       

                      I'll give it a try to see how the difference turns out.

                       

                       

                      Regards,

                       

                      bugchucker