|
|
Blitz Support : |
From: carlos.rega_at_[hidden]
Date: 2004-06-10 04:52:12
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.