|Re: [eigen] Indexes: why signed instead of unsigned?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Indexes: why signed instead of unsigned?
- From: leon zadorin <leonleon77@xxxxxxxxx>
- Date: Tue, 18 May 2010 14:40:54 +1000
- 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; bh=Fv78G2zQkom2iU07HQZT7vOk9xORT1GygbYhaM3MW9Q=; b=mSL0hNejuEBmsGsh8mAzww30ncLscRggVEYHyDsY8zpWF71NjsrXNuRZrWEdIiZBlg a8JspE97++C+0vglNdTfcCQ+hJQoQhFIa+rkh5vv8AyjFAC/VhsjrRqbE+BTJsySSJOp kqjyuHMEG8R344WtDia861ecbLdkIWSkxgRJU=
- 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; b=JbifsnrVSwi99cg/6RhA971wSR4h72RGDOsSw5MekN2fWU1T9XisF5pg+sFNMWwDti VQxScmtWWXhCmYIT9RvwUaBO5MlNWgfOGBQtjCZUKbDrZzZuwbnGO4D2y+7rVA0dFdyu SYHB6bCHlMWkQcrtY2k1BmjOv7ioUUgNXsWp0=
On 5/17/10, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/5/17 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> On Mon, May 17, 2010 at 5:07 AM, leon zadorin <leonleon77@xxxxxxxxx>
>>> 'mul' being magnitude of times slower for 64 bits ints
>> same here. I believe Benoit did not notice any speed difference because
>> CPU is more recent that ours.
> Oh right, this is on a Core i7.
> *starts up big motorbike*
:-) :-) :-)
Harley is it?
>> Anyway this benchmark does not represent
>> typical use cases of sizes & indexes. In theory the compiler should not
>> to issue integer multiplication inside inner loops but simply increments
>> some registers. I verified that for simple expressions. Unfortunately for
>> more complex one involving more complex addressing like:
>> 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....
> argh, this is pretty bad! Hm though... for large enough blocks, this
> operation is totally memory-bound anyway. But then I guess the same
> phenomenon will happens in CPU-bound loops, bad bad bad...!
> One more reason why the LinearAccessBit is important, when it's present.
> If nothing else works, we could specialize the loops also in the
> DirectAccessBit case and write them by manually incrementing pointers.
>> Anyway, the change Benoit is doing is the necessary step to offer more
>> flexibility, then we can bench real world expressions, and finally make a
>> decision for the default index/size type of Matrix. According to the
>> of the benchs, I see two options:
>> 1) always use ptrdiff_t
>> 2) default is int + one Matrix's Option to use int64
> I was going to do:
> 3) Default is ptrdiff_t
> + make it easy to override this global default by a macro e.g.
> + later if you want we can add a Matrix option to use int.