Re: [eigen] Comparing notes on work by Igleberger et al. 2012 |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Comparing notes on work by Igleberger et al. 2012*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Tue, 28 Aug 2012 19:49:05 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=xyYF20cEMaw+xf/N8caR0hy6EG6AcbEIvhC7/CNflCU=; b=N4CiCWVMVWMarJChcFGPAPxbMZMIni8q6+bMa1fkv2QffKf8TK6/G7GiZBs29lw3kj AXPrhLHD5uZX8XbdxmueZPz0BXAvrqAu2r0kesi1RvJotXx5+GxjdviKNixhEWOmTQoJ OhS7rdVWxUVZaP8tOCxDu2ZCBkSJJG2bhosP4uuC89fc0raQf8g/+B9T+/Fy0TNDRJf3 GNe18oD0NI+s1K8SG9DGQCLC9lSKUs8Hvw3AItbVinFdoBRs+8tzcSR103dDHMh6j6Sd evA0kNbcef+f2Hj2BJoqc+kXsSbwXf1KJXfiqyJVVYbfmjT65ltB1hfydX/TEcwZ6yPc rGuQ==

On Tue, Aug 28, 2012 at 5:14 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 28.08.2012 16:39, Gael Guennebaud wrote: >> >> On Tue, Aug 28, 2012 at 4:24 PM, Rhys Ulerich <rhys.ulerich@xxxxxxxxx> >> wrote: >>> >>> [...] >> >> >> Partly. Blaze is also able to exploit AVX instruction (so a >> theoretical x2 compared to SSE), however Blaze suffers from a HUGE >> shortcoming: data are assumed to be perfectly aligned, including >> inside a matrix. For instance, a row-major matrix is padded with empty >> space such that each row is aligned. The extra space *must* be filled >> with zeros and nothing else because they are exploited during some >> computations... As a consequence, Blaze does not has any notion of >> sub-matrices or the like, cannot map external data, etc. One cannot >> even write a LU decomposition on top of Blaze. In other word, it is >> not usable at all. This is also unfair regarding the benchmarks >> because they are comparing Blaze with perfectly aligned matrices to >> Eigen or MKL with packed and unaligned matrices. I also realized that blaze::trans(A) * v is 5 times slower than A * v => trans(A) seems to be evaluated into a temporary. > Actually, it would be nice to optionally support padding in Eigen as well, > sth like padding to the next multiply of packet-size or so. > This would also have the benefit that e.g. col(i) expressions can actually > return an aligned map. yes, for small objects that can offer a real speedup. We could either extend Matrix, in which I'd rather add an option bit flag, or even add a new class. >>> 2) Blaze shows faster performance on A*B*v for A and B matrices >>> because they don't honor order of operations and their expression >>> templates treat it as A*(B*v). This is moot as I can simply write >>> A*(B*v) in Eigen. >> >> >> Exactly, though we plane to do the same (and more) once the evaluators >> finalized. > > > Hm, I wouldn't think it's a good idea to optimize this automatically without > warnings/special flags. I can't think of an example right now where it would > harm (of course, if v is a matrix as well, it's easy to find examples where > the first is better than the second), but I would like to be able to > distinguish between (A*B)*v and A*(B*v). That's the usual remark, and the usual answer is: (A*B).parenthesis() * v; (or .group(), or whatever...) Also note that any optimized math library like Eigen is already putting arbitrary parenthesis. For instance a simple v.sum() with vectorization is not computed as: v0 + v1 + v2 + v3 + ... but as (v0 + v2 + v4 + ...) + (v1 + v3 + ...) or even: ((v0+v1) + (v2+v3)) + ((v4+v5) + (v6+v7)) when unrolling occurs. Similar arbitrary parenthesis occur inside matrix products, so implicitly computing A*(B*v) instead of (A*B)*v should exceptionally be an issue. > And a completely different note, has anyone checked how they do their > "automatic alias detection"? If, as Gael says, they don't support > sub-matrices, do they just compare the data pointers, or can they actually > decide it at compile time somehow? > I wouldn't see how they can do it with methods like (Eigen syntax): > > void aliastest(VectorXd& res, const VectorXd &x){ > res = {some complex expression with x}; > } no clue. gael > > Christoph > > -- > ---------------------------------------------- > Dipl.-Inf. Christoph Hertzberg > Cartesium 0.049 > Universität Bremen > Enrique-Schmidt-Straße 5 > 28359 Bremen > > Tel: +49 (421) 218-64252 > ---------------------------------------------- > >

**Follow-Ups**:**Re: [eigen] Comparing notes on work by Igleberger et al. 2012***From:*Christoph Hertzberg

**References**:**[eigen] Comparing notes on work by Igleberger et al. 2012***From:*Rhys Ulerich

**Re: [eigen] Comparing notes on work by Igleberger et al. 2012***From:*Gael Guennebaud

**Re: [eigen] Comparing notes on work by Igleberger et al. 2012***From:*Christoph Hertzberg

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Eigen 3.1.1 and LGPL components** - Next by Date:
**Re: [eigen] Comparing notes on work by Igleberger et al. 2012** - Previous by thread:
**Re: [eigen] Comparing notes on work by Igleberger et al. 2012** - Next by thread:
**Re: [eigen] Comparing notes on work by Igleberger et al. 2012**

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