|
|
Blitz Support : |
From: Julian C. Cummings (cummings_at_[hidden])
Date: 2004-06-10 15:40:17
Hello Carlos,
I would need to see the precise code being compiled to offer more specific
comments. However, just looking over the code snippets below, I am puzzled
by this one:
> template<class T>
> void lapack_function_wrapper(MKL_Traits<T>::Type *,MKL_Traits<T>::Type
*,int*)
Why would you template the wrapper function on the exported types from the
MKL_Traits class rather than templating on the initial type T and then
converting types inside the wrapper function specializations? How is this
any better than simple overloading?
void lapack_function_wrapper(float *x, float *y, int *z) {
return slapack_function(x,y,z);
}
void lapack_function_wrapper(double *x, double *y, int *z) {
return dlapack_function(x,y,z);
}
void lapack_function_wrapper(std::complex<float> *x, std::complex<float> *y,
int *z) {
return clapack_function(reinterpret_cast<MKL_Complex8 *>(x),
reinterpret_cast<MKL_Complex8 *>(y), z);
}
void lapack_function_wrapper(std::complex<double> *x, std::complex<double>
*y, int *z) {
return zlapack_function(reinterpret_cast<MKL_Complex16 *>(x),
reinterpret_cast<MKL_Complex16 *>(y), z);
}
Since you are specializing the wrapper function, there is no real need to
utilize the MKL_Traits class here, as the result type is already known.
Maybe I am missing something here? A complete example of the code that
fails to compile under VS.NET would help clarify the problem you are having.
I tried to cook up my own example using template specialization, but I don't
encounter any similar compilation problems with VS.NET.
Regards, Julian C.
Dr. Julian C. Cummings
Staff Scientist, CACR/Caltech
(626) 395-2543
cummings_at_[hidden]
> -----Original Message-----
> From: blitz-support-bounces_at_[hidden]
> [mailto:blitz-support-bounces_at_[hidden]] On Behalf Of
> carlos.rega_at_[hidden]
> Sent: Thursday, June 10, 2004 2:52 AM
> To: Support list for Blitz++
> Subject: [Blitz-support] Template support in VC++ .NET
>
>
>
> Hi,
>
> Just had a quick look about the exporting makefiles issue in
> the VC++ help, and the 2003 version explicitly says that you
> can not export makefiles (whatever the reason for that may
> be). However, there seems to be the possibility of running
> the editor, would you believe it, in a command line mode that
> will treat the solution file as a makefile. Whatever was
> wrong with exporting makefiles and running them through nmake
> does not explain.
>
> Anyhow, now that I am in rant mode about Visual Studio I will
> comment on a problem I have found. As I said in a previous
> message we are trying to write a wrapper that uses blitz and
> the intel MKL implementation of LAPACK. In general it is
> rather simple, just passing the pointers returned by the
> data() method to the LAPACK functions.
>
> I started writing my code using gcc, just to check that the
> project was feasible and would not take a huge amount of
> time. Using gcc I used the following approach to wrap the
> LAPACK functions. For each function there are usually 4
> flavours, two real (single and double precision) and two
> complex (again single and double). The signature of the
> function is the same, only the types of the arguments are different:
>
> slapack_function(float *,float*,int*) // single precision real
> dlapack_function(double*,double*,int*) // double precision real
> clapack_function(MKL_Complex8*,MKL_Complex8*,int*) // single
> precision complex
> zlapack_function(MKL_Complex16*,MKL_Complex16*,int*) //
> double precision complex
>
> the MKL_Complex types are structs like:
>
> struct MKL_Complex8 {
> float real;
> float imag;
> };
>
> so you can cast safely from complex<float>* to MKL_Complex8*
> and the other way around.
>
> The C++ interface will be a set of classes that call MKL as a
> back-end, and use blitz for the matrix representation, like so:
>
> template<class T> class LUFactorisation
> {
>
> public:
>
> /// default constructor
>
>
> CLUFactorisation(void):mResult(Array<T,2>(FortranArray<2>())),
> mIpiv(Array<int,1>(FortranArray<1>())){;}
>
> /// implements the call to the LAPACK function
>
> void Factor(const Array<T,2>&);
>
> /// returns the L matrix
>
> Array<T,2> L(void);
>
> /// returns the U matrix
>
> Array<T,2> U(void);
>
> private:
>
> Array<T,2> mResult;
>
> /// contains the permutation vector, row i is swapped
> with row mIpiv(i)
>
> Array<int,1> mIpiv;
>
> };
>
> There are two possibilities for getting Factor to call the
> right LAPACK function, explicit specialisation of the
> template for each type, or writing a template function that
> wraps the LAPACK function and let the compiler generate the
> four different Factor functions. The second approach is more
> economical, as in this case the only difference between the
> four template specialisations is which function to call, and
> the rest of the code is exactly the same.
>
> So, I would write something like:
>
> template<class T> void
> lapack_function_wapper(MKL_Traits<T>::Type
> *,MKL_Traits<T>::Type *,int*)
>
> and specialise for each type. Here MKL_Traits<T>::Type
> returns the correct type expected by the MKL functions, float
> for T = float, double for T=double, MKL_Complex8 for
> complex<float> and MKL_Complex16 for complex<double>.
>
> This worked fine with gcc, with these wrappers getting
> expanded in line, even without optimisation.
>
> Now, here it is a VS only shop, so I need to port that code
> to VS, luckily VS .NET 2003 compiles blitz, so it should be a
> matter of just copying the files and generating the project,
> as there is nothing really fancy in what I have written,
> right? Nope, The above template trick will not work in VS, it
> refuses to recognise the specialisations as specialisations
> of the above template, and I end up with no other choice but
> to use overloading instead. Not that overloading is all that
> bad, but I would expect that templates would give slightly
> better performance, as they should get automatically inlined
> at compile time, while it might be slightly trickier to get
> the compiler to inline the overloaded functions.
>
> So, my question is, is what I am trying to do non standard
> and it just happens that it works in gcc, but it is not
> really supposed to or is VS support of templates still
> slightly flaky?
>
> Thanks for your patience
>
> Carlos A. Rega, PhD
> Development Scientist
> Malvern Instruments Ltd
> Grovewood Rd, Malvern
> WR14 1XZ
>
> Tel: +44 (0)1684 581 304
> Fax: +44 (0)1684 892 789
>
> e-mail: carlos.rega_at_[hidden]
>
> --------------------------------------------------------------
> ------------------------------------------------------
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity
> to whom they are addressed.
>
> If you have received this email in error please notify the
> originator of the message.
>
> Any views expressed in this message are those of the
> individual sender, except where the sender specifies and with
> authority, states them to be the views of Malvern Instruments.
>
>