Menu
▾
▴
Re: [Cppqed-support] FLENS
|
From: Michael L. <mic...@un...> - 2014-04-11 09:08:31
|
Hi András,
thanks for testing FLENS on your ARCH box! And of course for using FLENS :-)
About CXXLAPACK and FLENS-LAPACK:
- CXXLAPACK is a C++ wrapper for LAPACK. Like CBLAS is a C-wrapper for BLAS
or CLAPACK for LAPACK. So this requires a LAPACK backend. Having a link
error like "undefined reference to 'zheev_'" means that the backend is missing.
This wrapper is pretty low-level. It only eases the task of calling Fortran
functions from C++. The wrapper for (z)heev looks like this
http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/cxxlapack/interface/heev.tcc.html
- FLENS-LAPACK is a C++ rewrite of LAPACK.... unfortunately only of a subset
of LAPACK. As you noticed e.g. (z)heev is not yet rewritten. By rewrite
I actually mean that it is a standalone C++ implementation of LAPACK. So
no LAPACK backend is needed. But for testing my reimplementation of
FLENS-LAPACK I compare results against LAPACK. For users the advantage of
FLENS-LAPACK is that you don't have the LAPACK dependency. Furthermore you
can use mpfr data types. My reason for FLENS-LAPACK is to prove that with
C++ & FLENS you can do the same implementation as with Fortran (same speed)
just simpler.
If you compile with USE_CXXLAPACK then FLENS-LAPACK is preferred over LAPACK. But
if a functions is missing in FLENS-LAPACK the LAPACK implementation gets used. That
means for a non-symmetrix/non-hermitian matrix 'ev' calls the FLENS-LAPACK
implementation. And (at the moment) it calls for a symmetric/hermitian matrix the
LAPACK Version (through the CXXLAPACK wrapper).
-> So a reimplementation of heev is next on the list. That would mean that you
are independent of LAPACK
If you compile with ALWAYS_USE_CXXLAPACK then only the LAPACK beackend gets used.
Even if a C++ implementation exists in FLENS-LAPACK. I use this option for
benchmarking FLENS-LAPACK against LAPACK.
Speaking of benchmarks. The performance of LAPACK does not depend on the Fortran
compiler. Analogously, neither does the performance of FLENS-LAPACK depend on
the C++ compiler. In both cases it depends on the speed of the BLAS kernel. In
FLENS is include a simple default implementation similar to Netlibs REFBLAS.
So for high performance there still remains a dependency for a tuned BLAS core.
Sorry for the long mail. But I am watching my student taking their math final right
now so I have a lot of time to type. I hope it is not confusing even more :-)
Cheers,
Michael
Am 11.04.2014 um 10:25 schrieb Andras Vukics <and...@ui...>:
> Dear Michael,
>
> I have just run the testsuite with your latest commits on my ARCH box, and everything seems to be fine. I used gcc 4.8.2.
>
> As to USE_CXXLAPACK: what you say makes me suspect that I do not understand the fundamental structure of FLENS-LAPACK :) . I thought that FLENS-LAPACK needs some backend, which can be either cxxlapack (distributed together with flens) or some lapack library already present on the system. I thought that by defining USE_CXXLAPACK, we instruct FLENS to use cxxlapack, which we need to do if we do not have any other lapack library. What is it that I misunderstand?
>
> Whether there is something missing that we need:
> Without USE_CXXLAPACK (that I tried now after you said we don’t necessarily need this #define) everything works (compiles, links and runs correctly) except Hermitian eigenproblem, which doesn’t find the correct overload for the function ev.
> With USE_CXXLAPACK Hermitian eigenproblem also compiles, but it fails to link, issuing the error
> /usr/local/include/cxxlapack/interface/heev.tcc:91: error: undefined reference to 'zheev_'
>
> The good news is that we have released the new, shiny Milestone 10 release, which optionally depends on the header-only FLENS, we have completely deprecated our (optional) dependence on the old FLENS! We also have a very shiny new API documentation whose entry point is the SourceForge C++QED page: http://cppqed.sourceforge.net
>
> Thanks a lot for your help in this with bringing FLENS to a useable state for us. Compile time is not an issue in our case at the moment, but if it ever becomes so, precompiled headers sound like a good idea (although I have no experience whatsoever with them).
>
> Keep in touch!
> Best regards,
> András
>
>
>
>
> On Tue, Apr 8, 2014 at 9:07 PM, Michael Lehn <mic...@un...> wrote:
> Hi Andras and Raimar,
>
> I am done with merging the latest modification. Could you check if FLENS passes
> the LAPACK tests on your machines? I tested with gcc 4.7, 4.8 and 4.9. But only
> on Mac OS X. On my Ubuntu machine I only have gcc 4.6 which does not support all
> required C++11 features and clang++. But clang++ does complex arithmetic different
> from gfortran (as there is no IEEE standard that is legal) and therefore I get
> different roundoff errors.
>
> For testing set and export CXX, CC, FC and run make && make check.
>
> Andras also mentioned that he compiled with USE_CXXLAPACK. That is only required
> if some LAPACK function is not re-implemented in FLENS-LAPACK or if you want to
> compare results with netlib's LAPACK. So is there anything missing in FLENS-LAPACK
> that you need?
>
> Furthermore, if compile time becomes an issue (the drawback of header-only) we
> could think about using precompiled headers. This would have to be integrated
> into your build process.
>
> Cheers,
>
> Michael
>
>
> Am 28.02.2014 um 17:28 schrieb Andras Vukics <and...@ui...>:
>
>> Hi Michael,
>>
>> Thanks for the prompt reply, it’s good to see that FLENS-LAPACK is so well supported! The requirement of bitwise correspondence is indeed impressive.
>>
>> It would be very nice if we could use a fixed upstream version of FLENS in our new release of C++QED that we plan to publish in about a month.
>>
>> But I don’t want to press you :) .
>>
>> Cheers,
>> András
>>
>>
>>
>>
>> On Fri, Feb 28, 2014 at 4:53 PM, Michael Lehn <mic...@un...> wrote:
>> Hi Andras,
>>
>> thanks for the hints! ZGEEV has two workspaces work and rWork. The dimension
>> of rWork should always be 2*N. The wrapper with implicit workspace creation
>> should create an internal vector of correct size. The actual computational
>> routine should have an assertion that ensures the correct size. An actual workspace
>> query for calculating optimal workspace size is only needed for the workspace work.
>>
>> As the LAPACK test suit does not use the implicit workspace creation this was
>> undetected.
>>
>> The ZGEEV passed all the LAPACK tests. In this process I also compare results
>> bit-by-bit with calls to the original Netlib implementation (Version 3.3.1). Also
>> in each call of any subroutine the results get compared this way. So if there still
>> should be a bug it is also in LAPACK 3.3.1
>>
>> And having cout's in my repository is a really annoying weakness of me ... grrr
>>
>> Cheers,
>>
>> Michael
>>
>>
>> Am 28.02.2014 um 15:42 schrieb Andras Vukics <and...@ui...>:
>>
>>> Dear Michael,
>>>
>>> Recently, we have started to migrate C++QED to the header-only FLENS-LAPACK. The most important feature for us is the generic complex eigenvalue solver (zgeev). I guess it is also among the most problematic ones from the C++ implementation point of view.
>>>
>>> How would you evaluate the present maturity of the complex eigen solver? I see that in the public upstream branch, it still emits a note to cout at entering the routine.
>>>
>>> I noticed that the internal workspace query doesn’t work correctly, so e.g. this fails:
>>>
>>> typedef GeMatrix<FullStorage<dcomp> > Matrix;
>>> typedef DenseVector<Array<dcomp> > Vector;
>>>
>>> Matrix a(3,3);
>>>
>>> a=dcomp(0.89418418,0.88510796),dcomp(0.09935077,0.0955461 ),dcomp(0.19438046,0.77926046),
>>> dcomp(0.54987465,0.76065909),dcomp(0.07944067,0.34810127),dcomp(0.55701817,0.03426611),
>>> dcomp(0.80508047,0.48160102),dcomp(0.06586927,0.75840275),dcomp(0.15394400,0.99410489);
>>>
>>> Vector v(3);
>>>
>>> lapack::ev(false,false,a,v,a,a);
>>>
>>> cout<<v<<endl;
>>>
>>> with:
>>>
>>> flens_d: /usr/local/include/flens/vectortypes/impl/densevector.tcc:253: View flens::DenseVector<flens::Array<double, flens::IndexOptions<int, 1>, std::allocator<double> > >::operator()(const Range<IndexType> &) [A = flens::Array<double, flens::IndexOptions<int, 1>, std::allocator<double> >]: Assertion `range.lastIndex()<=lastIndex()' failed.
>>> Aborted (core dumped)
>>>
>>>
>>> But this works fine:
>>>
>>> typedef GeMatrix<FullStorage<dcomp> > Matrix;
>>> typedef DenseVector<Array<dcomp> > Vector;
>>>
>>> Matrix a(3,3);
>>>
>>> a=dcomp(0.89418418,0.88510796),dcomp(0.09935077,0.0955461 ),dcomp(0.19438046,0.77926046),
>>> dcomp(0.54987465,0.76065909),dcomp(0.07944067,0.34810127),dcomp(0.55701817,0.03426611),
>>> dcomp(0.80508047,0.48160102),dcomp(0.06586927,0.75840275),dcomp(0.15394400,0.99410489);
>>>
>>> Vector v(3), work(12); DenseVector<Array<double> > rwork(6);
>>>
>>> lapack::ev(false,false,a,v,a,a,work,rwork);
>>>
>>> cout<<v<<endl;
>>>
>>>
>>> This is all with USE_CXXLAPACK defined.
>>>
>>> Best regards,
>>> András
>>>
>>>
>>>
>>>
>>> On Wed, Oct 3, 2012 at 11:14 PM, Michael Lehn <mic...@un...> wrote:
>>> Hi András!
>>>
>>> I am using gcc 4.7.1, gcc 4.7.2 and clang 3.2. All of them support all the
>>> C++11 features I ever needed so far. However, I never tested things like lamda,
>>> regexp so far. Just the few thing that were very handy for FLENS:
>>>
>>> - rvalue-references
>>> - auto
>>> - alias templates
>>> - variadic templates
>>> - some type traits
>>>
>>> You are absolutely right about clang. It's error messages but also warnings are
>>> amazing and very useful! And its complete concept (from font-end to back-end) is
>>> amazing. I also use the clang parser for creating the tutorial. For example
>>> creating cross references in listings like in
>>>
>>> http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/flens/examples/lapack-gelqf.cc.html
>>>
>>> I also used to compile the examples in the tutorials with clang in the past. But
>>> because of a problem with how MacPort installed clang I had to switch to gcc. At
>>> the moment I switch the examples back to clang. (Yes I admit that I converted from
>>> Linux to Mac, but I still use VIM in fullscreen).
>>>
>>> For testing FLENS-LAPACK I use g++ and gfortran. The combination clang and gfortran
>>> should also work except for complex numbers. Both g++ and clang++ compute the complex
>>> arithmetic operations by falling back to their C99 implementation. And they seem to
>>> use different algorithms for that. Consequently you get different roundoff errors.
>>>
>>> Clang seems to implement the algorithm proposed in Appendix G in
>>>
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
>>>
>>> the division of two double complex numbers (p. 470) caused my tests to fail (ok, the
>>> difference was really small). It finally found out the gcc uses the following algorithm
>>> that merely avoids overflow:
>>>
>>> complex<double>
>>> c_div(complex<double> a, complex<double> b)
>>> {
>>> complex<double> c;
>>> if (fabs(b.real()) < fabs(b.imag())) {
>>> double r = b.real() / b.imag();
>>> double den = b.imag() + r * b.real();
>>> c.real() = (a.real() * r + a.imag()) / den;
>>> c.imag() = (a.imag() * r - a.real()) / den;
>>> } else {
>>> double r = b.imag() / b.real();
>>> double den = b.real() + r * b.imag();
>>> c.real() = (a.real() + r * a.imag()) / den;
>>> c.imag() = (a.imag() - r * a.real()) / den;
>>> }
>>> return c;
>>> }
>>>
>>> If you run the FLENS-LAPACK test let me know your results.
>>>
>>>
>>> Sorry, I just realize that I am really giving long answers to short questions ;-)
>>>
>>> Cheers,
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>> Am 03.10.2012 um 22:02 schrieb Andras Vukics:
>>>
>>> > Hi Michael,
>>> >
>>> > It's really kind of you to have a look into C++QED from an FLENS point of view.
>>> >
>>> > I have a question on a slightly other note: What compiler would you
>>> > recommend to be able to use as much of C++11 as possible today? I
>>> > myself have found that llvm-clang has already a lot of these features
>>> > implemented. I incidentally often use it for another purpose: its
>>> > error messages are often much nicer that those of gcc.
>>> >
>>> > What compiler do you use to test FLENS-LAPACK?
>>> >
>>> > Thanks with best regards,
>>> > András
>>> >
>>> >
>>> > On Sat, Sep 22, 2012 at 10:18 PM, Michael Lehn <mic...@un...> wrote:
>>> >> Hi Andras,
>>> >>
>>> >> thanks for your kind reply and sorry for my last response. I am
>>> >> very happy that FLENS is of use for you!
>>> >>
>>> >> You are right about the C++11 requirements and I completely understand
>>> >> your point. Luckily time will solve the problem of lacking C++11
>>> >> support for us. I will try to use the interim time to have a closer
>>> >> look on what FLENS features and LAPACK functions you need in C++QED.
>>> >> For example, I think it would be a useful feature for you if FLENS
>>> >> already contains generic implementations for all the LAPACK functions
>>> >> you need.
>>> >>
>>> >> Best wishes and greetings from Ulm,
>>> >>
>>> >> Michael
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Am 01.09.2012 um 18:57 schrieb Andras Vukics:
>>> >>
>>> >>> Hi Michael,
>>> >>>
>>> >>> Thanks for your mail. Not only in the past, but also presently C++QED
>>> >>> optionally depends on FLENS (recently we've even prepared some ubuntu
>>> >>> packages, cf. https://launchpad.net/~raimar-sandner/+archive/cppqed).
>>> >>> All the eigenvalue calculations of the framework are done with LAPACK
>>> >>> *through* FLENS, and if the FLENS dependency is not satisfied, then
>>> >>> these tracts of the framework get disabled. (Earlier, we used to use
>>> >>> our own little C++ interface to LAPACK, but soon gave it up -- you of
>>> >>> all people probably understand why.)
>>> >>>
>>> >>> However, it is not your new FLENS/LAPACK implementation, but your old
>>> >>> project that we use, namely the 2011/09/08 version from CVS. For
>>> >>> months now, we've been aware of your new project, and it looks very
>>> >>> promising to us.
>>> >>>
>>> >>> The reason why we think we cannot switch at the moment is that our
>>> >>> project is first of all an application programming framework, in which
>>> >>> end-users are expected to write and compile their C++ applications in
>>> >>> the problem domain of open quantum systems. This means that when they
>>> >>> compile, they also need to compile the FLENS parts that they actually
>>> >>> use. Now, as far as I understand, the new FLENS/LAPACK uses c++11
>>> >>> features, which at the moment severely limits the range of suitable
>>> >>> compilers.
>>> >>>
>>> >>> But we are definitely looking forward to be able to switch, and are
>>> >>> glad that the project is well alive!
>>> >>>
>>> >>> Best regards,
>>> >>> András
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sat, Sep 1, 2012 at 2:26 AM, Michael Lehn <mic...@un...> wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> I am a developer of FLENS. Browsing the web I saw that C++QED was using FLENS
>>> >>>> for some optional modules in the past. There was quite a list I always wanted to
>>> >>>> improve in FLENS. Unfortunately other projects were consuming too much time.
>>> >>>> Last year I finally found time. If you are still interested in using LAPACK/BLAS
>>> >>>> functionality from within a C++ project some of its features might be interesting
>>> >>>> of you:
>>> >>>>
>>> >>>> 1) FLENS is header only. It comes with generic BLAS implementation. By "generic" I
>>> >>>> mean template functions. However, for large problem sizes you still have to use
>>> >>>> optimized BLAS implementations like ATLAS, GotoBLAS, ...
>>> >>>>
>>> >>>> 2) FLENS comes with a bunch of generic LAPACK function. Yes, we actually re-implemented
>>> >>>> quite a number of LAPACK functions. The list of supported LAPACK function include LU,
>>> >>>> QR, Cholesky decomposition, eigenvalue/-vectors computation, Schur factorization, etc.
>>> >>>> Here an overview of FLENS-LAPACK:
>>> >>>>
>>> >>>> http://www.mathematik.uni-ulm.de/~lehn/FLENS/flens/lapack/lapack.html
>>> >>>>
>>> >>>> These LAPACK ports are more then just a reference implementation. It provides the same
>>> >>>> performance as Netlib's LAPACK. But much more important we carefully ensure that it
>>> >>>> also produces exactly the same results as LAPACK. Note that LAPACK is doing some cool
>>> >>>> stuff to ensure stability and high precision of its result while providing excellent
>>> >>>> performance at the same time. Consider the caller graph of LAPACK's routine dgeev which
>>> >>>> computes the eigenvalues/-vectors of a general matrix:
>>> >>>>
>>> >>>> http://www.mathematik.uni-ulm.de/~lehn/dgeev.pdf
>>> >>>>
>>> >>>> The routine is pretty sophisticated and for example switches forth and back between
>>> >>>> different implementations of the QR-method (dlaqr0, dlaqr1, dlaqr2, ...). By this
>>> >>>> the routine even converges for critical cases. We ported all these functions one-by-one.
>>> >>>> And tested them as follows:
>>> >>>> (i) On entry we make copies of all arguments.
>>> >>>> (ii) (a) we call our port
>>> >>>> (ii) (b) we call the original LAPACK function
>>> >>>> (iii) We compare the results.
>>> >>>> If a single-threaded BLAS implementation is used we even can reproduce the same roundoff
>>> >>>> errors (i.e. we do the comparison bit-by-bit).
>>> >>>>
>>> >>>> 3) If you use FLENS-LAPACK with ATLAS or GotoBLAS as BLAS backend then you are on par
>>> >>>> with LAPACK from MKL or ACML. Actually MKL and ACML just use the Netlib LAPACK and optimize
>>> >>>> a few functions (IMHO there's a lot of marketing involved).
>>> >>>>
>>> >>>> 4) You still can use an external LAPACK function (if FLENS-LAPACK does not provide a needed
>>> >>>> LAPACK port you even have to).
>>> >>>>
>>> >>>> 5) Porting LAPACK to FLENS had another big advantage: It was a great test for our matrix and
>>> >>>> vector classes:
>>> >>>> (i) We now can prove that our matrix/vector classes do not introduce any performance penalty.
>>> >>>> You get the same performance as you get with plain C or Fortran.
>>> >>>> (ii) Feature-completeness of matrix/vector classes. We at least know that our matrix/vector
>>> >>>> classes allow a convenient implementation of all the algorithms in LAPACK. An in our
>>> >>>> opinion the FLENS-LAPACK implementation also looks sexy.
>>> >>>>
>>> >>>> I hope that I could tease you a little to have a look at FLENS on http://flens.sf.net
>>> >>>>
>>> >>>> FLENS is back,
>>> >>>>
>>> >>>> Michael
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> ------------------------------------------------------------------------------
>>> >>>> Live Security Virtual Conference
>>> >>>> Exclusive live event will cover all the ways today's security and
>>> >>>> threat landscape has changed and how IT managers can respond. Discussions
>>> >>>> will include endpoint security, mobile security and the latest in malware
>>> >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> >>>> _______________________________________________
>>> >>>> Cppqed-support mailing list
>>> >>>> Cpp...@li...
>>> >>>> https://lists.sourceforge.net/lists/listinfo/cppqed-support
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>
|
