5 ms·

And what's funny about that stance is mathematical operators aren't actually O(1). https://en.wikipedia.org/wiki/Computational_complexity_of_mathematical_opera

And what's funny about that stance is mathematical operators aren't actually O(1). https://en.wikipedia.org/wiki/Computational_complexity_of_mathematical_operations https://en.wikipedia.org/wiki/Computational_complexity_of_ma... You don't want to know what the innocent-looking `*` in this function compiles to: fn square(num: u10000) u10000 { return num * num; }

pixelpoet 3y ago
It's mildly offensive that u10000 is a builtin type but vec2f is not (also note that I am not asking for general operator overloading!). Which has dedicated CPU instructions across all modern architectures, what's the relative usage frequency, what's the cost/benefit of each, etc etc... :( And we all know why u10000 is in there: because you have to have arbitrary-width integers when writing a compiler, so they figured eh, we'll just expose that because we have it already. Absolutely transparent compiler-programming (cf. rendering-programming) bias, almost nobody else needs that. And yeah, I get that Add(Add(Add(a, b), Mul(c, 3)), d) is possible, but come on... imagine if you had to write your normal "a + b + c * 3 + d" with ints/floats like that! What's that, suddenly people care, but nobody cares if it's not their field... Whatever, I will continue to look longingly at Zig for all the bits of C/C++ (and apparently Go, to try bring it back to the original topic) it solves, but missing the trivial and absolutely critical single feature to enable an entire class of performance-critical programming.
- defen 3y ago
  > And we all know why u10000 is in there: because you have to have arbitrary-width integers when writing a compiler You don't need them as a built-in type to write a compiler. They're there because LLVM was the original backend and you essentially get them for free (in the sense that the backend code generation is already handled for you, so why not include them).
- bsder 3y ago
  > It's mildly offensive that u10000 is a builtin type but vec2f is not u10000 exists only because we want u3, u7, and u13 as builtin types. u3, u7, and u13 are useful for embedded and systems programming.
- tuhats 3y ago
  > It's mildly offensive that u10000 is a builtin type but vec2f Zig does have builtin vec2f, it is spelt @Vector(2, f32).
  - ForkMeOnTinder 3y ago
    @Vector is counterproductive for cases like vec2f, since it tries to force data into SIMD registers even when it would be more efficient to leave it in normal registers. In fact I've wondered in the past if Zig might end up slower than C for graphics code, if people misuse @Vector to get normal math operators back. For that reason I never use @Vector unless I already know what SIMD intrinsics I'd be writing in C.
throwawaymaths 3y ago
Is the underlying algo not O(1)? Under what pairs of two u10000 numbers would you get different execution time?
- ForkMeOnTinder 3y ago
  Sure, if you ignore the n in n=10000, multiplication is O(1). But the same is true for e.g. heapsort--all lists of 10000 items take asymptotically the same amount of time to sort. But that's a strained interpretation of complexity, and not very useful.
  - throwawaymaths 3y ago
    A heapsort is designed to take a variable number of items at runtime for given code. The n is fixed at compile time in the multiplication examples and is invariant at comptime (in zig).

pixelpoet 3y ago

It's mildly offensive that u10000 is a builtin type but vec2f is not (also note that I am not asking for general operator overloading!). Which has dedicated CPU instructions across all modern architectures, what's the relative usage frequency, what's the cost/benefit of each, etc etc... :( And we all know why u10000 is in there: because you have to have arbitrary-width integers when writing a compiler, so they figured eh, we'll just expose that because we have it already. Absolutely transparent compiler-programming (cf. rendering-programming) bias, almost nobody else needs that. And yeah, I get that Add(Add(Add(a, b), Mul(c, 3)), d) is possible, but come on... imagine if you had to write your normal "a + b + c * 3 + d" with ints/floats like that! What's that, suddenly people care, but nobody cares if it's not their field... Whatever, I will continue to look longingly at Zig for all the bits of C/C++ (and apparently Go, to try bring it back to the original topic) it solves, but missing the trivial and absolutely critical single feature to enable an entire class of performance-critical programming.

defen 3y ago
> And we all know why u10000 is in there: because you have to have arbitrary-width integers when writing a compiler You don't need them as a built-in type to write a compiler. They're there because LLVM was the original backend and you essentially get them for free (in the sense that the backend code generation is already handled for you, so why not include them).
bsder 3y ago
> It's mildly offensive that u10000 is a builtin type but vec2f is not u10000 exists only because we want u3, u7, and u13 as builtin types. u3, u7, and u13 are useful for embedded and systems programming.
tuhats 3y ago
> It's mildly offensive that u10000 is a builtin type but vec2f Zig does have builtin vec2f, it is spelt @Vector(2, f32).
- ForkMeOnTinder 3y ago
  @Vector is counterproductive for cases like vec2f, since it tries to force data into SIMD registers even when it would be more efficient to leave it in normal registers. In fact I've wondered in the past if Zig might end up slower than C for graphics code, if people misuse @Vector to get normal math operators back. For that reason I never use @Vector unless I already know what SIMD intrinsics I'd be writing in C.

throwawaymaths 3y ago

Is the underlying algo not O(1)? Under what pairs of two u10000 numbers would you get different execution time?

ForkMeOnTinder 3y ago
Sure, if you ignore the n in n=10000, multiplication is O(1). But the same is true for e.g. heapsort--all lists of 10000 items take asymptotically the same amount of time to sort. But that's a strained interpretation of complexity, and not very useful.
- throwawaymaths 3y ago
  A heapsort is designed to take a variable number of items at runtime for given code. The n is fixed at compile time in the multiplication examples and is invariant at comptime (in zig).