std.simd

[Manu]

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

> On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120316/30a86c07/attachment-0001.html>