mkl+boost problems
Hello. mkl (intel blas) has "mkl_cblas.h" file which in turn includes " mkl_types.h" file which defines P4 macro variable: 70 /** CPU codes for int MKL_CPU_DETECT(void) **/ 71 #ifdef _IPF 72 #define ITP 0 73 #else 74 #ifdef _EM64T 75 #define NI 0 76 #define CT 1 77 #define MNI 2 78 #define PNR 3 79 #else 80 #define DEF 0 81 #define PIII 1 82 #define P4 2 83 #define P4P 3 84 #define P4M 4 85 #endif 86 #endif This P4 variable creates havoc of MPL templates which have P4 template parameters names. What to do?
On 11/8/2010 4:25 PM, Andrey Asadchev wrote:
mkl (intel blas) has "mkl_cblas.h" file which in turn includes " mkl_types.h" file which defines P4 macro variable: [...] This P4 variable creates havoc of MPL templates which have P4 template parameters names.
What to do?
#undef P4 ...After you include that header. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 11/8/2010 5:25 PM, Andrey Asadchev wrote:
Hello.
mkl (intel blas) has "mkl_cblas.h" file which in turn includes " mkl_types.h" file which defines P4 macro variable:
70 /** CPU codes for int MKL_CPU_DETECT(void) **/ 71 #ifdef _IPF 72 #define ITP 0 73 #else 74 #ifdef _EM64T 75 #define NI 0 76 #define CT 1 77 #define MNI 2 78 #define PNR 3 79 #else 80 #define DEF 0 81 #define PIII 1 82 #define P4 2 83 #define P4P 3 84 #define P4M 4 85 #endif 86 #endif
This is HORRIBLE.
This P4 variable creates havoc of MPL templates which have P4 template parameters names.
What to do?
File a bug against mkl for subjecting the world to their macro pollution. And then create a wrapper header for yourself that includes mkl and then #undef's the macros that are causing you grief. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Nov 8, 2010, at 2:37 PM, Eric Niebler wrote:
On 11/8/2010 5:25 PM, Andrey Asadchev wrote:
Hello.
mkl (intel blas) has "mkl_cblas.h" file which in turn includes " mkl_types.h" file which defines P4 macro variable:
70 /** CPU codes for int MKL_CPU_DETECT(void) **/ 71 #ifdef _IPF 72 #define ITP 0 73 #else 74 #ifdef _EM64T 75 #define NI 0 76 #define CT 1 77 #define MNI 2 78 #define PNR 3 79 #else 80 #define DEF 0 81 #define PIII 1 82 #define P4 2 83 #define P4P 3 84 #define P4M 4 85 #endif 86 #endif
This is HORRIBLE.
This P4 variable creates havoc of MPL templates which have P4 template parameters names.
What to do?
File a bug against mkl for subjecting the world to their macro pollution. And then create a wrapper header for yourself that includes mkl and then #undef's the macros that are causing you grief.
See https://svn.boost.org/trac/boost/ticket/2107 for more about this problem. -- Marshall
Andrey Asadchev wrote:
This P4 variable creates havoc of MPL templates which have P4 template parameters names.
What to do?
I think mkl-10.0.3 was the last version that had this problem. The later versions mkl-10.0.4, mkl-10.1.x and mkl-10.2.x no longer define these constants. So there is no need to fill an additional bug report to Intel. Because the "numeric_bindings" use MPL, and you proposed extensions <http://lists.boost.org/MailArchives/ublas/2010/07/4480.php> to them some time ago, I have the impression that you might be using the "numeric_bindings"" interface to cblas. Even so the "numeric_bindings" are also tested with mkl, I have to admit that I tested the cblas interface only with atlas, not with mkl. So I didn't notice that you are forced to include both the headers from the "numeric_bindings" and "mkl_cblas.h" in the same source file. However, fixing this is not high on my priority list. Regards, Thomas
On Tue, Nov 9, 2010 at 5:20 AM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
Andrey Asadchev wrote:
This P4 variable creates havoc of MPL templates which have P4 template parameters names.
What to do?
I think mkl-10.0.3 was the last version that had this problem. The later versions mkl-10.0.4, mkl-10.1.x and mkl-10.2.x no longer define these constants. So there is no need to fill an additional bug report to Intel.
Because the "numeric_bindings" use MPL, and you proposed extensions <http://lists.boost.org/MailArchives/ublas/2010/07/4480.php> to them some time ago, I have the impression that you might be using the "numeric_bindings"" interface to cblas. Even so the "numeric_bindings" are also tested with mkl, I have to admit that I tested the cblas interface only with atlas, not with mkl. So I didn't notice that you are forced to include both the headers from the "numeric_bindings" and "mkl_cblas.h" in the same source file. However, fixing this is not high on my priority list.
Regards, Thomas _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Tomas My fix is: #ifndef BOOST_NUMERIC_BINDINGS_CBLAS_INC_H #define BOOST_NUMERIC_BINDINGS_CBLAS_INC_H extern "C" { #ifdef BOOST_NUMERIC_BINDINGS_MKL #include <mkl_cblas.h> #include <mkl_service.h> #undef P4 // mkl_types.h defines P4 macro which breaks MPL #else #include <cblas.h> #endif } #endif
On 11/9/2010 10:14 AM, Andrey Asadchev wrote:
My fix is:
#ifndef BOOST_NUMERIC_BINDINGS_CBLAS_INC_H #define BOOST_NUMERIC_BINDINGS_CBLAS_INC_H
extern "C" {
#ifdef BOOST_NUMERIC_BINDINGS_MKL #include<mkl_cblas.h> #include<mkl_service.h>
#ifdef P4
#undef P4 // mkl_types.h defines P4 macro which breaks MPL
#endif
#else #include<cblas.h> #endif
}
#endif
That way if/when mkl_cblas.h fixes their #define it will not break your header. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
On Tue, Nov 9, 2010 at 11:46 AM, Kevin Heifner <heifnerk@ociweb.com> wrote:
On 11/9/2010 10:14 AM, Andrey Asadchev wrote: #ifdef P4
#undef P4 // mkl_types.h defines P4 macro which breaks MPL
#endif
That way if/when mkl_cblas.h fixes their #define it will not break your header.
I was under the impression that #undef NEVER_WAS_DEFINED was completely harmless, kind of like delete NULL;
On 11/9/2010 2:40 PM, John B. Turpish wrote:
I was under the impression that #undef NEVER_WAS_DEFINED was completely harmless, kind of like delete NULL;
MSDN agrees with you and so does my preprocessor reference. Hmm, I wonder why I've been in the habit of wrapping them in #ifdef. Sorry for the noise. KevinH
On 09/11/10 21:16, Kevin Heifner wrote:
On 11/9/2010 2:40 PM, John B. Turpish wrote:
I was under the impression that #undef NEVER_WAS_DEFINED was completely harmless, kind of like delete NULL;
MSDN agrees with you and so does my preprocessor reference. Hmm, I wonder why I've been in the habit of wrapping them in #ifdef.
Sorry for the noise.
Some compilers warn about undefining not-defined things. e.g. gcc when -Wundef is specified (which I do). John Bytheway
On 11/09/2010 05:14 PM, Andrey Asadchev wrote:
Hi Tomas
My fix is:
#ifndef BOOST_NUMERIC_BINDINGS_CBLAS_INC_H #define BOOST_NUMERIC_BINDINGS_CBLAS_INC_H
extern "C" {
#ifdef BOOST_NUMERIC_BINDINGS_MKL #include<mkl_cblas.h> #include<mkl_service.h> #undef P4 // mkl_types.h defines P4 macro which breaks MPL #else #include<cblas.h> #endif
}
#endif
Hello Andrey, apparently you're using numeric_bindings-v1. We've made some significant improvements to the bindings, they reside in sandbox/numeric_bindings. I once tested the speed difference between ATLAS' cblas and ATLAS' fortran interfaces; there is none. So why go through all the trouble, and use MKL's cblas interface? Why not just link against the fortran libs? Cheers, Rutger
participants (9)
-
Andrey Asadchev -
Eric Niebler -
John B. Turpish -
John Bytheway -
Kevin Heifner -
Marshall Clow -
Rene Rivera -
Rutger ter Borg -
Thomas Klimpel