Re: [eigen] FLENS C++ expression template Library has excellent documentation |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] FLENS C++ expression template Library has excellent documentation*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Sat, 18 Apr 2009 11:01:53 -0400*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Y8tkOHH9ICPuxIu+ctV9hxBoAsCJ80v/ZYMZtfTllGs=; b=hS4xgfZGQXPxBZ6YXktB7669rFIuuoUjkfSgHIMo5RFyk6ontW532deXkW6zfBR7cK CstUF2nSegmcPh1CNzWaI6S7nT+zEkS2aP4LMBLo/b4QyfpfatBfhJxV94aHwPhndHSN 8NOTYqvbSeD2rEpqPAweDuf69zxXEaXEIumMA=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=s2chsiVRbRarY8t+aCtA1t+HuIAfVj2l7OLYJOUxpGLiOYvHnSQBKeiTa+d+SsA7TI Bq4Jq42H/xS6ZWQvE/s2TBE8sh93F+xwzXw5XCKQtBQ9NsPS5VJNZ3XStA7+wLSP+8db /LPW5xnDqf9+04lUZRIBqgqWLW9HZCqblTEr4=

Wow, this is very interesting, thanks for the link. Notice that even they call it a "ultimate goal" to generate optimized code automatically -- they're not there yet in general. But yes, it's very interesting. Once they finish working out the general theory, an implementation could theoretically be done by c++ metaprogramming, so why not in Eigen, although it remains to be seen what the compilation times would be. More stuff for eigen 3.0 in 2015 ;) Benoit 2009/4/18 Ilya Baran <baran37@xxxxxxxxx>: > Hello, > > Let me throw another library I stumbled on into the discussion pot: > > libFLAME: http://www.cs.utexas.edu/users/flame/ > > This is by the same group that employs Goto, I think. > > As far as I understand, the main idea behind this is that many LAPACK > algorithms have a similar block-based structure that allows efficient > use of BLAS 3. They build some generic operations that simplify the > common steps (partitioning, recursion, traversal), making efficient > code for a particular algorithm much smaller and easier to write. To > avoid the overhead of the recursion and bookkeeping, the algorithm > must still be implemented for a nontrivial size base case, but the > performance of that becomes less critical for large matrix sizes. > They also use this structure to do parallelization, but I don't know > much about that. > > It certainly doesn't make sense for Eigen to merge with them in any > way, but I'm wondering if the generic structure can be easily > reimplemented in Eigen (with its support for Block views) and simplify > coding high-level algorithms? > > Thanks, > > -Ilya > > On Fri, Apr 17, 2009 at 3:49 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >> 2009/4/17 Christian Mayer <mail@xxxxxxxxxxxxxxxxx>: >>> (Disclaimer: I'm not knowing FLENS) >>> >>> FLENS and EIGEN have totally different use cases: >>> - - EIGEN is a lib that gives you the best performance for small, fixed >>> size matrices and vectors that's possible (e.g. those that are typical >>> for 3D intensive applications) >>> - - BLAS/LAPACK gives you the best performance (using the right >>> implementation) for big, variable sized matrices and vectors (i.e. those >>> used in numerical applications). FLENS is adding a modern, object >>> orientated wrapper around this functionality. >>> >>> In this case both libs can peacefully coexist... >>> >>> As EIGEN is supporting variable sized matrices as well, both are >>> starting to compete in exactly the same field of use. EIGEN has the >>> advantage that the expression templates are the base and not something >>> built on top, i.e. EIGEN can optimize "between" BLAS function calls. >> >> That's an accurate summary :) >> >>> FLENS has the advantage that it can use extremely optimized BLAS >>> libraries (e.g. Intel MKL), something that EIGEN can't do (as it's cross >>> platform) and won't do (as it doesn't have the funding that MKL has as a >>> marketing platform for Intel...). >>> => it would be interesting to see a benchmark of a non trivial numerical >>> algorithm to see wich approach wins. >> >> Our (updated) benchmarks on the wiki clearly show that as long as you >> use only 1 thread, we have the same level of performance as Intel MKL >> for many important operations, suggesting that we could have the same >> level of performance for all operations given enough contributions. >> >> This is made possible by 2 facts: >> 1) we have much more generic code so that it takes us far less effort >> to optimize >> 2) For the rest, when generic code doesn't cut it (e.g. matrix >> product), Gael is an amazing coder :) >> >> So, in which area does Intel MKL still have a long-term lead? I would >> say parallelization. We haven't started that yet and it is probably a >> very, very tough one. It's what I have in mind when I say that a >> BLAS/LAPACK wrapper is still welcome. >> >>> But as EIGEN could include a BLAS/LAPACK lib as well, there shouldn't be >>> a way for FLENS to win... >>> Perhaps it's best to convince the FLENS author to join effords? >> >> It's hard to do without sounding offensive :) Also, adding a >> BLAS/LAPACK wrapper to Eigen wouldn't be really difficult, so he would >> feel that there doesnt survive much of FLENS in Eigen. >> >> While we're discussing other libraries, I think that an interesting one is NT2: >> >> http://nt2.sourceforge.net/ >> >> I had a email conversation with its author, so here's what I know. >> It's a c++ template library offering only very basic functionality, >> and wrapping around LAPACK for advanced stuff. So in that respect, it >> is similar to FLENS. The difference is that NT2 is extremely >> aggressive on the expression-templates front. It is based on >> Boost::proto which gives it a very high-up view of expression >> templates, performing a lot of impressive global transformations on >> expressions. He gets "for free" stuff that were hard to implement by >> hand in Eigen such as the automatic introduction of temporaries where >> appropriate. The downside is very long compilation times -- 3 seconds >> for a trivial program and 10 seconds for a typical file, and remember >> that this is only basic operations, since for the nontrivial stuff it >> relies on LAPACK. Extrapolating, this suggest the order of magnitude >> of 1 minute to compile any of our big linear algebra algorithms. >> Another critique i'd formulate is that like Boost::ublas, it only >> treats expr templates as an optimization that you can enable or >> disable, so it doesn't leverage xpr templates to achieve a better API >> like Eigen does. >> >> Still, this got me thinking. Relying on Boost::proto is a no-go in >> 2009 as it makes compilation times awful. But what in 5 years? If >> compilers improve enough until then, that could become very >> interesting. >> >> Cheers, >> Benoit >> >> >> > > >

**Follow-Ups**:

**References**:**[eigen] FLENS C++ expression template Library has excellent documentation***From:*Andre Krause

**Re: [eigen] FLENS C++ expression template Library has excellent documentation***From:*Benoit Jacob

**Re: [eigen] FLENS C++ expression template Library has excellent documentation***From:*Christian Mayer

**Re: [eigen] FLENS C++ expression template Library has excellent documentation***From:*Benoit Jacob

**Re: [eigen] FLENS C++ expression template Library has excellent documentation***From:*Ilya Baran

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Adapting code from OpenCV (a seemingly much faster SVD)** - Next by Date:
**Re: [eigen] Adapting code from OpenCV (a seemingly much faster SVD)** - Previous by thread:
**Re: [eigen] FLENS C++ expression template Library has excellent documentation** - Next by thread:
**Re: [eigen] FLENS C++ expression template Library has excellent documentation**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |