Am 05.02.2012, 02:46 Uhr, schrieb Manu <[email protected]>:
On 5 February 2012 03:37, Martin Nowak <[email protected]> wrote:
Am 05.02.2012, 02:13 Uhr, schrieb Manu <[email protected]>:
On 5 February 2012 03:08, Martin Nowak <[email protected]> wrote:
Let me restate the main point.
Your approach to a higher level module wraps intrinsics with named
functions.
There is little gain in making simd(AND, f, f2) to and(f, f2) when you
can
easily take this to the level GLSL achieves.
What is missing to reach that level in your opinion? I think I
basically
offer that (with some more work)
It's not clear to me what you object to...
I'm not prohibiting the operators, just adding the explicit functions,
which may be more efficient in certain cases (they receive the
version).
Also the 'gains' of wrapping an intrinsic in an almost identical
function
are, portability, and potential optimisation for hardware versioning.
I'm
specifically trying to build something that's barely above the
intrinsics
here, although a lot of the more arcane intrinsics are being collated
into
their typically useful functionality.
Are you just focused on the primitive math ops, or something broader?
GLSL achieves very clear and simple to write construction and conversion
of values.
I think wrapping the core.simd vector types in an alias this struct
makes
it a snap
to define conversion through constructors and swizzling through
properties/opDispatch.
Then you can overload operands to do the implementation specific stuff
and
add named methods
for the rest.
So you are referring to the light wrapper class, that's what I thought.
I think that's overcooking it a bit. Also, you seem to have ignored the
reason I created the primitive operator functions twice now. They are
needed to take advantage of the hardware with respect to different
versions.
No, I do see you point, but you can do it in the private part
of you module as well as in a vector struct as well as in a different
module.
IMHO it's just a too shallow layer over intrinsics to make a useful phobos
module.
In fact it's more low level for arithmetic operations than what dmd can
already do for SSE vectors.
OTOH dot is very good as it is.
At the lowest level, I am generally favouring performance over usage (if
it
doesn't cause serious damage to the API).
You're suggesting exactly what I expected half the forum to suggest, and
I'm not against it in any way, but I think it's a layer above this. This
should remain pure, and performance orientated...
There must be a library that provides the opportunity for the best
performance, before sugary libs get all layered over the top, and it's as
I've said twice now, everyone will have a different idea of what that
sugar
API will look like, so I feel it should live above this... or perhaps
beside this (in the same file?), but I wouldn't want to remove this API
in
favour of a vector 'class'.
A lot of people will be happy to use off the shelf primitives.
