On 16 March 2012 01:32, Robert Jacques <sandford@jhu.edu> wrote:

> On Thu, 15 Mar 2012 14:02:15 -0500, Manu <turkeyman@gmail.com> wrote:
>
>> On 15 March 2012 20:35, Robert Jacques <sandford@jhu.edu> wrote:
>>
>>> On Thu, 15 Mar 2012 12:09:58 -0500, Manu <turkeyman@gmail.com> wrote:
>>>
>> [snip]
>
>> This sounds reasonable. However, please realize that if you wish to use
>>> the short vector names (i.e. float4, float3, float2, etc) you should
>>> support the full set with a decent range of operations and methods.
>>> Several
>>> people (myself included) have written similar short vector libraries; I
>>> think having having short vectors in phobos is important, but having one
>>> library provide float4 and another float2 is less than ideal, even if not
>>> all of the types could leverage the SMID backend. For myself, the killer
>>> feature for such a library would be have the CUDA compatible alignments
>>> for
>>> the types. (or an equivalent enum to the effect)
>>>
>>>
>> I can see how you come to that conclusion, but I generally feel that
>> that's
>> a problem for a higher layer of library.
>>
>
> Then you should to leave namespace room for that higher level library.
>

I haven't stolen any names that aren't already taken by core.simd. I just want to claim those primitive types already aliased in std.simd to enhance them with some more useful base-level functionality.

On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
> Then you should to leave namespace room for that higher level library.

What makes you thing that there would be only one such high-level library wanting to define a floatN type?

There is no such thing as a global namespace in D (well, one could probably argue that the things defined in object are). Thus, I don't see a problem with re-using a name in a third-party library, if its a good fit in both places – and you'll probably have a hard time coming up with a better name for SIMD stuff than float4.

If at some point you want to mix types from both modules, you could always use static or renamed imports. For example, »import lowlevel = std.simd« would give you »lowlevel.float4 upVector;«, which might be clearer in the context of your application than any longer, pre-defined name could ever be.

True, we shouldn't generally pick very likely-to-collide names by default just because we can so, but denying the existence of the D module system altogether is going to set us back to using library name prefixes everywhere, like in C (and sometimes C++) code.

David

On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see@klickverbot.at> wrote:

> On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
>> Then you should to leave namespace room for that higher level library.
>
> What makes you thing that there would be only one such high-level library wanting to define a floatN type?

The fact that several people have proposed unifying the existing libraries any putting them into phobos :)

>
> There is no such thing as a global namespace in D (well, one could probably argue that the things defined in object are). Thus, I don't see a problem with re-using a name in a third-party library, if its a good fit in both places – and you'll probably have a hard time coming up with a better name for SIMD stuff than float4.
>
> If at some point you want to mix types from both modules, you could always use static or renamed imports. For example, »import lowlevel = std.simd« would give you »lowlevel.float4 upVector;«, which might be clearer in the context of your application than any longer, pre-defined name could ever be.
>
> True, we shouldn't generally pick very likely-to-collide names by default just because we can so, but denying the existence of the D module system altogether is going to set us back to using library name prefixes everywhere, like in C (and sometimes C++) code.
>
> David

Unrelated libraries using the same name is relatively painless. Highly related libraries that conflict, on the other hand, are generally painful. Yes, there are a lot of mechanisms available to work around this, but selective imports and renaming all add to the cognitive load of using and writing the code.

To me float4 isn't a SIMD name; its a vector name and if it's implemented using SIMD, great, but that's an implementation detail. I can understand a close to the metal SIMD library and encourage the work. But if it isn't also going to be a vector library, if possible, it shouldn't use the vector names.

On 16 March 2012 22:39, Robert Jacques <sandford@jhu.edu> wrote:

> On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see@klickverbot.at> wrote:
>
>  On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
>>
>>> Then you should to leave namespace room for that higher level library.
>>>
>>
>> What makes you thing that there would be only one such high-level library wanting to define a floatN type?
>>
>
> The fact that several people have proposed unifying the existing libraries any putting them into phobos :)


I personally can't see it happening. Above the most primitive level that
I've tried to cover with std.simd, I think it'll be very hard to find
agreement on what that API should look like.
If you can invent a proposal that everyone agrees on, I'd be very
interested to see it. Perhaps if you extend the fairly raw and D-ish API
that I've tried to use in std.simd it could work, but I don't think many
people will like using that in their code. I anticipate std.simd will be
wrapped in some big bloated class by almost everyone that uses it, so why
bother to add the emulation at that level?


There is no such thing as a global namespace in D (well, one could probably
>> argue that the things defined in object are). Thus, I don't see a problem with re-using a name in a third-party library, if its a good fit in both places – and you'll probably have a hard time coming up with a better name for SIMD stuff than float4.
>>
>> If at some point you want to mix types from both modules, you could always use static or renamed imports. For example, »import lowlevel = std.simd« would give you »lowlevel.float4 upVector;«, which might be clearer in the context of your application than any longer, pre-defined name could ever be.
>>
>> True, we shouldn't generally pick very likely-to-collide names by default just because we can so, but denying the existence of the D module system altogether is going to set us back to using library name prefixes everywhere, like in C (and sometimes C++) code.
>>
>> David
>>
>
> Unrelated libraries using the same name is relatively painless. Highly related libraries that conflict, on the other hand, are generally painful. Yes, there are a lot of mechanisms available to work around this, but selective imports and renaming all add to the cognitive load of using and writing the code.
>
> To me float4 isn't a SIMD name; its a vector name and if it's implemented using SIMD, great, but that's an implementation detail. I can understand a close to the metal SIMD library and encourage the work. But if it isn't also going to be a vector library, if possible, it shouldn't use the vector names.
>

Can you give me an example of a non-simd context where this is the case?
Don't say shaders, because that is supported in hardware, and that's my
point.
Also there's nothing stopping a secondary library adding/emulating the
additional types. They could work seamlessly together. flaot4 may come from
std.simd, float3/float2 may be added by a further lib that simply extends
std.simd.

On Fri, 16 Mar 2012 16:45:05 -0500, Manu <turkeyman@gmail.com> wrote:
> On 16 March 2012 22:39, Robert Jacques <sandford@jhu.edu> wrote:
>> On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see@klickverbot.at>
>> wrote:
>>  On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:

[snip]

>> Unrelated libraries using the same name is relatively painless. Highly
>> related libraries that conflict, on the other hand, are generally painful.
>> Yes, there are a lot of mechanisms available to work around this, but
>> selective imports and renaming all add to the cognitive load of using and
>> writing the code.
>>
>> To me float4 isn't a SIMD name; its a vector name and if it's implemented
>> using SIMD, great, but that's an implementation detail. I can understand a
>> close to the metal SIMD library and encourage the work. But if it isn't
>> also going to be a vector library, if possible, it shouldn't use the vector
>> names.
>>
>
> Can you give me an example of a non-simd context where this is the case?
> Don't say shaders, because that is supported in hardware, and that's my
> point.
> Also there's nothing stopping a secondary library adding/emulating the
> additional types. They could work seamlessly together. flaot4 may come from
> std.simd, float3/float2 may be added by a further lib that simply extends
> std.simd.

Shaders. :) Actually, float4 isn't supported in hardware if you're on NVIDIA. And IIRC ATI/AMD is moving away from hardware support as well. I'm not sure what Intel or the embedded GPUs do. On the CPU side SIMD support on both ARM and PowerPC is optional. As for examples, pretty much every graphics, vision, imaging and robotics library has a small vector library attached to it; were you looking for something else?

Also, clean support for float3 / float2 / etc. has shown up in Intel's Larrabee and its Knight's derivatives; so, maybe we'll see it in a desktop processor someday. To say nothing of the 245-bit and 512-bit SIMD units on some machines.

My concern is that std.simd is (for good reason) leaking the underlying hardware implementation (std.simd seems to be very x86 centric), while vectors, in my mind, are a higher level abstraction.

On 17 March 2012 20:42, Robert Jacques <sandford@jhu.edu> wrote:

> On Fri, 16 Mar 2012 16:45:05 -0500, Manu <turkeyman@gmail.com> wrote:
>
>> Can you give me an example of a non-simd context where this is the case?
>>
> Don't say shaders, because that is supported in hardware, and that's my
>> point.
>> Also there's nothing stopping a secondary library adding/emulating the
>> additional types. They could work seamlessly together. flaot4 may come
>> from
>> std.simd, float3/float2 may be added by a further lib that simply extends
>> std.simd.
>>
>
> Shaders. :) Actually, float4 isn't supported in hardware if you're on NVIDIA. And IIRC ATI/AMD is moving away from hardware support as well. I'm not sure what Intel or the embedded GPUs do. On the CPU side SIMD support on both ARM and PowerPC is optional. As for examples, pretty much every graphics, vision, imaging and robotics library has a small vector library attached to it; were you looking for something else?
>

GPU hardware is fundamentally different than CPU vector extensions. The goal is not to imitate shaders on the CPU. There are already other possibilities for that anyway.

Also, clean support for float3 / float2 / etc. has shown up in Intel's
> Larrabee and its Knight's derivatives; so, maybe we'll see it in a desktop processor someday. To say nothing of the 245-bit and 512-bit SIMD units on some machines.
>

Well when that day comes, we'll add hardware abstraction for it. There are 2 that do currently exist, 3DNow, but that's so antiquated, I see no reason to support it. The other is the Gamecube, Wii, WiiU line of consoles; all have 2D vector hardware. I'll gladly add support for that the very moment anyone threatens to use D on a Nintendo system, but no point right now.

float3 on the other hand is not supported on any machine, and it's very inefficient. Use of float3 should be discouraged at all costs. People should be encouraged to use float4's and pack something useful in W if they can. And if not, they should be aware that they are wasting 25% of their flops.

I don't recall ever dismissing 256bit vector units. Infact I've suggested
support for AVX is mandatory on plenty of occasions. I'm also familiar with
a few 512bit vector architectures, but I don't think they warrant a
language level implementation yet. Let's just work through what we have,
and what will be used to start with. I'd be keen to see how it tends to be
used, and make any fundamental changes before blowing it way out
of proportion.


> My concern is that std.simd is (for good reason) leaking the underlying
> hardware implementation (std.simd seems to be very x86 centric), while
> vectors, in my mind, are a higher level abstraction.
>

It's certainly not SSE centric. Actually, if you can legitimately criticise me of anything, it's being biased AGAINST x86 based processors. I'm critically aware of VMX, NEON, SPU, and many architectures that came before. What parts of my current work in progress do you suggest is biased to x86 hardware implementation? From my experience, I'm fairly happy with how it looks at this point being an efficiency-first architecture-abstracted interface.

As I've said, I'm still confident that people will just come along and wrap it up with what they feel is a simple/user-friendly interface anyway. If I try to make this higher-level/more-user-friendly, I still won't please everyone, and I'll sacrifice raw efficiency in the process, which defeats the purpose.

How do you define vectors in your mind?