3 ms·

Zig has a builtin @Vector type that might come in handy for most cases where in C++ a math library with operator overloading would be used: https://www.godbolt

Zig has a builtin @Vector type that might come in handy for most cases where in C++ a math library with operator overloading would be used: https://www.godbolt.org/z/7zbxnncv6 https://www.godbolt.org/z/7zbxnncv6 ...maybe one day there will also be a @Matrix builtin.

jsheard 3y ago
That still breaks if you layer any abstractions on top, for example if you wanted to build an AoSoA packet of Vec3s you'd have to define an addition of those in terms of a function. https://www.godbolt.org/z/v8Ta8hEbv https://www.godbolt.org/z/v8Ta8hEbv Zig is exactly the kind of language where you'd want to build a performance-oriented primitive like that, but AFAICT the language doesn't let you do it ergonomically.
- flohofwoe 3y ago
  That's true, but OTH that's already getting into territory where operator overloading might start to become detrimental because it hides important implementation details which might not be expected from a simple '+'.
throwawaymaths 3y ago
Probably not. @Vector is not a mathematical vector, it's SIMD. it makes sense because there are times when those live in registers and a poly fill for stack memory isn't burdensome. @Matrix makes less sense because when it gets big, where are you getting memory from?
- flohofwoe 3y ago
  For 'game-ey' math code, a matrix is at most 4x4 floats (64 bytes), that's fine for a value type that might live on the stack. vec2..4 and matching matrix types up to 4x4 is basically also what's provided in GPU shading languages as primitive types, and personally I would prefer such a set of "SIMD-y" primitive types for Zig (maybe a bit more luxurious than @Vector, e.g. with things like component swizzling syntax - basically what this Clang extension offers: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...).
  - cmbothwell 3y ago
    You might like Odin, it has a similar philosophy to Zig and supports swizzling: https://odin-lang.org/docs/overview/#swizzle-operations https://odin-lang.org/docs/overview/#swizzle-operations Matrix types are also built in: https://odin-lang.org/docs/overview/#matrix-type https://odin-lang.org/docs/overview/#matrix-type I’ve thought for a little while that Odin could be a secret weapon for game dev and similar pieces of software.
    - flohofwoe 3y ago
      I'm actually dabbling with Odin a bit in the scope of language bindings for the sokol headers: https://github.com/floooh/sokol-odin https://github.com/floooh/sokol-odin It's a very enjoyable language!
  - throwawaymaths 3y ago
    Sure, but people are going to want to use operator overloading for, e.g. dl/ml
Conscat 3y ago
It's a LOT worse than C++ SIMD libraries. In C++ (EVE, Vc, Highway, xsimd, stdlib), you can specify the ABI of a vector, which allows you to make platform specific optimizations in multifunctions. Or you can write vector code of a lowest-common-denominator width (like 16 bytes, rather than specifying the number of lanes), which runs the same on NEON and SSE2. Or you can write SIMD that is automatically natively optimized for just a single platform. These features are available on every notable C++ SIMD library, and they're basically indispensable for serious performance code.

jsheard 3y ago

That still breaks if you layer any abstractions on top, for example if you wanted to build an AoSoA packet of Vec3s you'd have to define an addition of those in terms of a function. https://www.godbolt.org/z/v8Ta8hEbv https://www.godbolt.org/z/v8Ta8hEbv Zig is exactly the kind of language where you'd want to build a performance-oriented primitive like that, but AFAICT the language doesn't let you do it ergonomically.

flohofwoe 3y ago
That's true, but OTH that's already getting into territory where operator overloading might start to become detrimental because it hides important implementation details which might not be expected from a simple '+'.

throwawaymaths 3y ago

Probably not. @Vector is not a mathematical vector, it's SIMD. it makes sense because there are times when those live in registers and a poly fill for stack memory isn't burdensome. @Matrix makes less sense because when it gets big, where are you getting memory from?

flohofwoe 3y ago
For 'game-ey' math code, a matrix is at most 4x4 floats (64 bytes), that's fine for a value type that might live on the stack. vec2..4 and matching matrix types up to 4x4 is basically also what's provided in GPU shading languages as primitive types, and personally I would prefer such a set of "SIMD-y" primitive types for Zig (maybe a bit more luxurious than @Vector, e.g. with things like component swizzling syntax - basically what this Clang extension offers: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...).
- cmbothwell 3y ago
  You might like Odin, it has a similar philosophy to Zig and supports swizzling: https://odin-lang.org/docs/overview/#swizzle-operations https://odin-lang.org/docs/overview/#swizzle-operations Matrix types are also built in: https://odin-lang.org/docs/overview/#matrix-type https://odin-lang.org/docs/overview/#matrix-type I’ve thought for a little while that Odin could be a secret weapon for game dev and similar pieces of software.
  - flohofwoe 3y ago
    I'm actually dabbling with Odin a bit in the scope of language bindings for the sokol headers: https://github.com/floooh/sokol-odin https://github.com/floooh/sokol-odin It's a very enjoyable language!
- throwawaymaths 3y ago
  Sure, but people are going to want to use operator overloading for, e.g. dl/ml

Conscat 3y ago

It's a LOT worse than C++ SIMD libraries. In C++ (EVE, Vc, Highway, xsimd, stdlib), you can specify the ABI of a vector, which allows you to make platform specific optimizations in multifunctions. Or you can write vector code of a lowest-common-denominator width (like 16 bytes, rather than specifying the number of lanes), which runs the same on NEON and SSE2. Or you can write SIMD that is automatically natively optimized for just a single platform. These features are available on every notable C++ SIMD library, and they're basically indispensable for serious performance code.