with "extension everything", you might be able to define an implicit conversion that works like that

with "extension everything", you might be able to define an implicit conversion that works like that
but I'm not sure if that's on the table or not

Maxine•10/20/23, 11:56 PM

yeah that'll be awesome when it comes out in 2036

tannergoodingOP•10/20/23, 11:57 PM

I think its in the working set for C# 13, so maybe sooner
but who knows, stuff gets pushed out all the time

Maxine•10/20/23, 11:57 PM

ooh

Ttannergooding with "extension everything", you might be able to define an implicit conversion ...

Aqua•10/20/23, 11:57 PM

i do have a question - is there any plan for built-in integer vector/point types in system.numerics? i assume not but doesn't hurt to ask

Perksey•10/20/23, 11:57 PM

who needs it when you have System.Drawing.Point when

Aqua•10/20/23, 11:58 PM

lol

AAqua i do have a question - is there any plan for built-in integer vector/point types...

tannergoodingOP•10/21/23, 12:01 AM

I still plan on pushing through

Vector2<T> where T : IFloatingPointIeee754<T>

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>

Point2<T> where T : INumber<T>

is appropriate won't be as easy

I 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>

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>

Vector2<T>

in December
and that will also come alongside

Vector3/4<T>

Vector3/4<T>

Quaternion<T>

Quaternion<T>

Plane<T>

Plane<T>

Matrix4x4<T>

Matrix4x4<T>

and

Complex<T>

Complex<T>

plus the general

TensorPrimitives

TensorPrimitives

work

Maxine•10/21/23, 12:01 AM

@grifon.petre can you send over your generic math lib, just for me to look

PPerksey who needs it when you have System.Drawing.Point <:when:712347014456672438>

Perksey•10/21/23, 12:01 AM

(this is what Silk.NET.Windowing used before Silk.NET.Maths existed)

Maxine•10/21/23, 12:02 AM

no 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

tannergoodingOP•10/21/23, 12:03 AM

There 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

TensorPrimitives

TensorPrimitives

MMaxine @grifon.petre can you send over your generic math lib, just for me to look

Aqua•10/21/23, 12:04 AM

https://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

Maxine•10/21/23, 12:04 AM

thanks, tanner, i'll look into it

Aqua•10/21/23, 12:04 AM

i'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

Maxine•10/21/23, 12:04 AM

i won't copy your code, just your ideas :^)

Ttannergooding I still plan on pushing through `Vector2<T> where T : IFloatingPointIeee754<T>` ...

Aqua•10/21/23, 12:04 AM

oh right cool, that would be awesome to have in base .net

tannergoodingOP•10/21/23, 12:05 AM

yep! The

TensorPrimitives

TensorPrimitives

are all nice too, since its going to be the full set of math functions
but over

Span<T>

Span<T>

rather than fixed size vectors

tannergoodingOP•10/21/23, 12:05 AM

and then expanded to basic BLAS/LAPACK functions as well

Maxine•10/21/23, 12:11 AM

if the goal is to vectorize all of the implementations, i'm going to be here for the rest of my life

MMaxine if the goal is to vectorize all of the implementations, i'm going to be here for...

tannergoodingOP•10/21/23, 12:12 AM

https://github.com/dotnet/runtime/blob/main/src/libraries/System.Numerics.Tensors/src/System/Numerics/Tensors/TensorPrimitives.netcore.cs#L10876-L10926
>.>

tannergoodingOP•10/21/23, 12:13 AM

(doesn't have acosh, asinh, or atanh atm; but has the other 3 + exp + log + a few others)

Aqua•10/21/23, 12:13 AM

what is a tensor primitive

Ttannergooding <https://github.com/dotnet/runtime/blob/main/src/libraries/System.Numerics.Tenso...

Maxine•10/21/23, 12:13 AM

holy cow, is this actually fast?

tannergoodingOP•10/21/23, 12:13 AM

it's "tensor operations" but directly over a

Span<T>

Span<T>

Aqua•10/21/23, 12:14 AM

i see

Maxine•10/21/23, 12:14 AM

i feel like for Vector3, using FPU operations in serial is still faster than doing all of this SIMD stuff

tannergoodingOP•10/21/23, 12:14 AM

tensors being just the abstract terminology encompassing scalar + vector + dense matrix + sparse matrix

Aqua•10/21/23, 12:14 AM

In mathematics, a tensor is an algebraic object that describes a multilinear relationship between sets of algebraic objects related to a vector space.

why is math

MMaxine i feel like for Vector3, using FPU operations in serial is still faster than doi...

tannergoodingOP•10/21/23, 12:14 AM

not even close

Ttannergooding not even close 😄

Maxine•10/21/23, 12:14 AM

really?

Maxine•10/21/23, 12:14 AM

for 3 components?

tannergoodingOP•10/21/23, 12:15 AM

yeah, the x87 FPU (assuming you're referring to

fsin

fsin

and friends) has been effectively deprecated for 20 years
and SSE/SSE2 has been faster for nearly 25

for the scalar implementation, you're doing SIMD operations anyways, just scalar ones (so

addss

addss

rather than

addps

addps

)

Maxine•10/21/23, 12:16 AM

i hate computers

tannergoodingOP•10/21/23, 12:16 AM

so the SIMD algorithm is basically the scalar one, just doing 3 at once
so it takes the same amount of time

Maxine•10/21/23, 12:16 AM

does this apply for all operators?

Maxine•10/21/23, 12:17 AM

i would think serial divide vs SIMD divide would not make a difference

tannergoodingOP•10/21/23, 12:17 AM

the one exception is you replace branching with ConditionalSelect
and so you still relegate the exceptional cases

for example, with

Log

Log

we have the fast path which is the normal scalar algorithm
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

Maxine•10/21/23, 12:18 AM

hmm interesting

tannergoodingOP•10/21/23, 12:18 AM

the 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

MMaxine i would think serial divide vs SIMD divide would not make a difference

tannergoodingOP•10/21/23, 12:20 AM

think about it this way, a scalar floating-point dividescalar floating-point divide is [11; 12] cycles[11; 12] cycles
3 of them is then [33; 36] cycles[33; 36] cycles

where-as a packed floating-point dividepacked floating-point divide is also [11; 12] cycles[11; 12] cycles
because SIMD is implemented by having countcount parallel units

tannergoodingOP•10/21/23, 12:21 AM

but 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)

Maxine•10/21/23, 12:21 AM

hm.

tannergoodingOP•10/21/23, 12:22 AM

so 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

Maxine•10/21/23, 12:22 AM

that's wild

Maxine•10/21/23, 12:22 AM

thank you!

tannergoodingOP•10/21/23, 12:23 AM

sure 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)

tannergoodingOP•10/21/23, 12:23 AM

(although I think we tend to be a couple iterations behind)

tannergoodingOP•10/21/23, 12:24 AM

https://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

Maxine•10/21/23, 12:25 AM

inchresting

tannergoodingOP•10/21/23, 12:25 AM

the 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

with "extension everything", you might be able to define an implicit conversion that works like that

Similar Threads