Re: [eigen] eigen short support: discussion thread

[Rohit Garg <rpg.314@xxxxxxxxx>]

On Sun, Aug 30, 2009 at 12:53 AM, Benoit Jacob<jacob.benoit.1@xxxxxxxxx> wrote:
> 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>() {}
Yeah, on 16, 32, 64 platforms, long long is differently sized compared
to int, so should be ok.
>
> 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...
int is 16 bits on 16 bit machines, those we can safely ignore. on 64
bit machines, the conventions is to have the int 32 bits and long as
64 bits. (Stevens's network programing book)
>
>> 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?
SSE3 has no integer instructions. SSSE3 and SSE4.1 have some integer
instructions, but they are pretty non-orthogonal. As for, bare bones
non vector support, I think that can be easily done.
>
> Anyway, it's fine to leave uint8 non vectorized for now. Basic
> support(no vectorization) would be cool though.
>
> Benoit
>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay