Re: [eigen] eigen short support: discussion thread |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] eigen short support: discussion thread
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sat, 29 Aug 2009 15:23:13 -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; bh=9UOQvO3w6NalShufjusqtdxPFupje8UYZGLn7zbbUHs=; b=I8+e5EdvsYu/ylSP89QCdnqX4nY/AJc1KAQN0vlZIaqqwBUK5vqIsa4wKQbKDoDE+N Us0z3ctsrX3eiJleUbDXBbnnFXzNOyIlhA6DKf1X/oIK+XaZutErj/x3jcN/nFIxD0nB jBgypEswK8bfUeqn2LaSBRJSpMBSI9gSXTy0Y=
- 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=YXgT0npDzNQ3bAI6sReSnUNqiKj5JHQQEtjBejfKTPPxwfbTTzPUDAL4FKAbxG+Jsu gui4OdXAhTVjMIKANvY5VsxY3O8mdSatUoZj+RHVL4dUssAIydR8l2Vsbmv5VjCQOzJK JPhXsknr3XaQTRNGenBtSobzhAqnRJW2I9UMM=
2009/8/29 Rohit Garg <rpg.314@xxxxxxxxx>:
> It wont be a complete integer types module without taking int32 there.
Is that a big deal? Is it better if we call it instead MoreIntegers?
Or stick to SmallIntegers?
another question is how we deal with int32 at all. Currently we
support int and while it's 32bit on most common platforms, it can also
be 64 bit. Or 16 bit, by the way. I wonder how the compiler deals with
collisions in template specializations.
For example, is this code legal C++?
template<typename T> void foo() {}
template<> void foo<int>() {}
template<> void foo<long long>() {}
or is this potentially ambiguous? I don't have access to a machine
where sizeof(int)==8 (or 2 for that matter) but they do exist...
> And that might break API/ABI. (Not sure, just guessing). How about
> making it a sub module of Core?
a sub module? How does that work? How is this different from putting
that into Core?
>>
>> That would be no less than 7 integer types (in addition to the int
>> that we have in Core) so having these 7 types in Core would more than
>> double the number of types handled in PacketMath.h ---> i think that
>> warrants the creation of a new module.
>>
>> I should have presented this as a "scalability" argument from the onset...
>>
>>>> When you do vectorization, add also packetmath.cpp. Keep all that
>>>> templated, so it can easily be extended to cover more new small
>>>> integer types. Just wipe what is not wanted / not applicable for small
>>>> integer types.
>>> Actually, I have looked at char and uchar support in SSE2 as well.
>>> Let's just say that we have a SNAFU (thank you, Intel, :P ) here.
>>
>> heh, i can believe it's not going to be easy!
> It isn't about it being easy.
>
> Let me try to list out the vector operations available in int8/uint8
>
> int8
>
> add,
> sub,
> saturated add, sub
> and,or,not
> ==, <, > comparison
>
> uint8
> add with saturation
> average
> min
> max
> saturated add, sub
> and, or, not
> ==, <, > comparison
>
> That's all what is there in SSE2. No multiplication, no division, no
> bit shifts. With these handicaps, is char/uchar even useful to
> _anyone_ ?
Hm, indeed I don't know, especially as Eigen isn't designed to expose
"add with saturation" and "average" in a useful way.
How about later SSE instruction sets?
Anyway, it's fine to leave uint8 non vectorized for now. Basic
support(no vectorization) would be cool though.
Benoit