| Re: [eigen] Indexes: why signed instead of unsigned? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Indexes: why signed instead of unsigned?
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Mon, 17 May 2010 11:44:55 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Bk2wU184JGIidkEzLIkeuyICSsOaBEqhFaUwVpH0K5A=; b=JI6BbzYN7l5Z94x1C2AXRzwVAmZqmiNZytL9hcPWlTBaGQrP+um8m23XkfIv3XCSfW Y1pAkl76tVo3Wo4oWkRKXt1a+xrLnGWPUjnIZlgiTAcrFUPWdG5RTz3WYNoqDDnKuNUX WGcXdm1CrS+y3BkXtL0/g1eG5KXyKGjUyAYxc=
- 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=EmKpYxFi7na9LP05IIYhXh3+tq2AP4eSahUOpcCbBFRYp4U10MRgIWQWQAY+ThgBEP x2eRyNfojAAKVabpT6EJQ+q3oKF/lIV6qlFu/EI3OnID+/zUCGsqD+jPHvDF4WH9xBVN tIBl9htQnib+8BCjSCtufWwzqxwlpL3ZfBMBc=
2010/5/17 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>
>
> On Mon, May 17, 2010 at 1:39 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> > c.block(1,12,50,89) += a.block(7,3,50,89) + b.block(70,35,50,89);
>> >
>> > it seems that GCC fails at generating good code and issue 3 imull in the
>> > most inner vectorized loop. The non vectorized loops (to deal with
>> > boundaries or when vectorization is disabled) are fine though... ahhhh
>> > compiler weirdnesses....
>
>
> this is past :)
>
> The fix is to cache the outer size in Block just like we cache the address
> of the fist coeff. Actually, it seems it does not like when m_xpr.whatever()
> is used to compute the address since it does not detect the returned value
> is constant trough the loop... So for each memory access, it read the actual
> number of rows of the nested matrix from memory, and multiplied it to the
> outer index, etc.... just like Matrix::rows was volatile. As a result, 0.58s
> versus 0.9s for the above expression (repeated a large number of time of
> course !)
>
> Of course, the same might appear in some other contexts...
Amazing benchmarking & fixing job Gael as usual!!
Benoit
>
> gael
>