who needs it when you have System.Drawing.Point <:when:712347014456672438>
who needs it when you have System.Drawing.Point 
Alol
TI still plan on pushing through
I'd really like to also support integers, but convincing API review that a
I don't have enough time to do everything of course, so I'm not sure what will get done in 9 vs not
and the Arm64 has SVE work that will likely happen in .NET 9
I'm going to try and finish the design proposal for
and that will also come alongside
and
plus the general
Vector2<T> where T : IFloatingPointIeee754<T>I'd really like to also support integers, but convincing API review that a
Point2<T> where T : INumber<T> is appropriate won't be as easyI don't have enough time to do everything of course, so I'm not sure what will get done in 9 vs not
ISimdVector<TSelf, T> is the thing I really want to finish next (might be internal only until language features come along)and the Arm64 has SVE work that will likely happen in .NET 9
I'm going to try and finish the design proposal for
Vector2<T> in Decemberand that will also come alongside
Vector3/4<T>, Quaternion<T>, Plane<T>, Matrix4x4<T>and
Complex<T>plus the general
TensorPrimitives work
M@grifon.petre can you send over your generic math lib, just for me to look
P(this is what Silk.NET.Windowing used before Silk.NET.Maths existed)
Mno proposal yet, but i wonder if it'd be worth it to implement more methods on the Vector3<T> (like what Unity does) or just do the System.Numerics ones
TThere is a proposal up already (via xoofx, from unity) for expanding Vector2/3/4 and Vector64/128/256/512<T> with the rest of the missing IFloatingPointIeee754<T> functions
and that will likely happen in .NET 9, since we're implementing them anyways for
and that will likely happen in .NET 9, since we're implementing them anyways for
TensorPrimitives
Ahttps://github.com/piegfx/Warp/tree/main/src/Warp.Math matrix and quaternion have varying levels of implementation (and a generic quaternion supporting int sounds frankly stupid so i'm not even sure i'll bother supporting it), but the rest i'm pretty sure is good
Mthanks, tanner, i'll look into it
Ai'm currently reworking my engine from scratch as i've changed the way i do things a bit, so this code will soon officially be MIT
Mi won't copy your code, just your ideas :^)
Aoh right cool, that would be awesome to have in base .net
Tyep! The
but over
TensorPrimitives are all nice too, since its going to be the full set of math functionsbut over
Span<T> rather than fixed size vectorsTand then expanded to basic BLAS/LAPACK functions as well
Mif the goal is to vectorize all of the implementations, i'm going to be here for the rest of my life
T(doesn't have acosh, asinh, or atanh atm; but has the other 3 + exp + log + a few others)
Awhat is a tensor primitive 
Mholy cow, is this actually fast?
Tit's "tensor operations" but directly over a
Span<T>Ai see
Mi feel like for Vector3, using FPU operations in serial is still faster than doing all of this SIMD stuff
Ttensors being just the abstract terminology encompassing scalar + vector + dense matrix + sparse matrix
AIn mathematics, a tensor is an algebraic object that describes a multilinear relationship between sets of algebraic objects related to a vector space.
why is mathTnot even close 
Mreally?
Mfor 3 components?
Tyeah, the x87 FPU (assuming you're referring to
and SSE/SSE2 has been faster for nearly 25
for the scalar implementation, you're doing SIMD operations anyways, just scalar ones (so
fsin and friends) has been effectively deprecated for 20 yearsand SSE/SSE2 has been faster for nearly 25
for the scalar implementation, you're doing SIMD operations anyways, just scalar ones (so
addss rather than addps)Mi hate computers
Tso the SIMD algorithm is basically the scalar one, just doing 3 at once
so it takes the same amount of time
so it takes the same amount of time
Mdoes this apply for all operators?
Mi would think serial divide vs SIMD divide would not make a difference
Tthe one exception is you replace branching with ConditionalSelect
and so you still relegate the exceptional cases
for example, with
and only if we have a special case (zero, infinity, nan, subnormal) do we do the extra computation
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Numerics.Tensors/src/System/Numerics/Tensors/TensorPrimitives.netcore.cs#L11004-L11047
and so you still relegate the exceptional cases
for example, with
Log we have the fast path which is the normal scalar algorithmand only if we have a special case (zero, infinity, nan, subnormal) do we do the extra computation
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Numerics.Tensors/src/System/Numerics/Tensors/TensorPrimitives.netcore.cs#L11004-L11047
Mhmm interesting
Tthe exceptional cases are expected to be exceptional, so the branch is fine for the majority case where we don't encounter them
and no worse than we'd have for scalar anyways
and no worse than we'd have for scalar anyways
Tthink about it this way, a
3 of them is then
where-as a
because SIMD is implemented by having
scalar floating-point divide is [11; 12] cycles3 of them is then
[33; 36] cycleswhere-as a
packed floating-point divide is also [11; 12] cyclesbecause SIMD is implemented by having
count parallel unitsTbut those units aren't separate ports; and so you can't dispatch count scalar instructions to them at the same time
because they logically execute together, so you can't have two cores trying to compete for them (how hyperthreading works)
because they logically execute together, so you can't have two cores trying to compete for them (how hyperthreading works)
Mhm.
Tso using SIMD is almost always worth it; especially if you don't need to branch or conditional select
if you do need to branch or conditional select, then you often need to tweak it a bit
but it tends to be no worse than the equivalent scalar code
if you do need to branch or conditional select, then you often need to tweak it a bit
but it tends to be no worse than the equivalent scalar code
Mthat's wild
Mthank you!
Tsure thing!
in general most of the C based math functions are available under the MIT license from AMD here: https://github.com/amd/aocl-libm-ose/tree/aocl-4.1
so it's a solid place to port things from
AMD's libm is the current implementation used by Windows and MSVC internally (and has been for years)
in general most of the C based math functions are available under the MIT license from AMD here: https://github.com/amd/aocl-libm-ose/tree/aocl-4.1
so it's a solid place to port things from
AMD's libm is the current implementation used by Windows and MSVC internally (and has been for years)
T(although I think we tend to be a couple iterations behind)
Thttps://github.com/amd/aocl-libm-ose/tree/aocl-4.1/src/optimized tends to be the most up to date
and the vectorized sometimes isn't as optimal as possible, I took some liberties on improving it for .NET, since we can take advantage of having a JIT and compiling for the current hardware, as an example
and the vectorized sometimes isn't as optimal as possible, I took some liberties on improving it for .NET, since we can take advantage of having a JIT and compiling for the current hardware, as an example
Minchresting
Tthe vectorized is also often slightly faster and allows slightly more error than the scalar version
since the domains it gets used (like games) often allow and like that
but, you can always port the scalar for extra precision if you want that
since the domains it gets used (like games) often allow and like that
but, you can always port the scalar for extra precision if you want that
DOk, maybe not. i have so many things on the go already
Mi saw it was all one source file, and then closed the tab
Mgiven my success porting blender's triangulation alg, i don't trust myself to do a better job here
Dwhat we need is a tool that can take c/c++ and convert it to C# using the silk bindings. 