i feel like for Vector3, using FPU operations in serial is still faster than doing all of this SIMD
i 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 math
Tnot 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. 
Ac-clangsharp?
also that is what the new buildtools is being designed to do
also that is what the new buildtools is being designed to do
Mnot what keenan meant
Aah
Aoh wait
literally something that transpiles c/c++ into c#?
literally something that transpiles c/c++ into c#?
Dyeah
Athere is something out there that exists
AI think it only works with C though
Ait's used in StbImageSharp
Mnot all C is transpilable to C#
TClangSharp handles basically everything it can. The stuff it can’t handle is stuff like templates, because there is no equivalent
TIt could try to do generics and type checks in some cases, but it doesn’t translate cleanly without interface constraints
And of course you can’t implement such interfaces on existing types you don’t own
And of course you can’t implement such interfaces on existing types you don’t own
Dcould you not pre "expand" the macros then translate that to C#?
Lthat wont work for the macros themselves
Lsure you can preprocess it
Lbut after you preprocess it then you can no longer try to turn those macros into function calls
La good amount of libs provide macros for end users to use
TRight. ClangSharp even handles many types of macros
But there’s plenty where it only works expanded directly inline
But there’s plenty where it only works expanded directly inline
Doh, so you were talking about macros that I as a consumer of an api would use
TYou can’t really make std::vector port to C# for example
Mdoes stack memory in c# behave like c
TYou can get something close manually, but it doesn’t work when done automatically
