2 ms·

> There is no single "zip". Which means you can implement yours to fit your needs. > I don't know any language other than Python that shares Python's iterator

> There is no single "zip". Which means you can implement yours to fit your needs. > I don't know any language other than Python that shares Python's iterator zip() implementation. https://docs.rs/itertools/latest/itertools/macro.izip.html https://docs.rs/itertools/latest/itertools/macro.izip.html > In implementation Which is hardly relevant. Python's entire implementation has aims, means, and purpose with no relation to Zig's. > I also disagree that you don't need more than 3. Which is not what I wrote. > As the article states, if you leverage array-of-structs rather than struct-of-arrays you can use this to "deconstruct" objects without paying the memory usage penalty of struct padding. Sure? And the article uses an example with 3 values. > The 15% wasted RAM in this example is relatively small compared to some real use scenarios; something as common as a 3D vector will often have a whopping 25% space waste. It also could hardly be less relevant: it's an issue in an AoS structure because all your objects have that overhead, therefore that's your total overhead. Here it's 15 or 25% padding in a single value within a stackframe. You're probably wasting more stackframe space due to the compiler not bothering reusing temporally dead locations. And that's if the compiler reifies the tuple instead of eliding the entire thing. > Other languages allow this as well OK? > (and often using such iterations are much faster than zip()ing lists together) Until they are not.

jeroenhd 4y ago
> Which means you can implement yours to fit your needs. Which this doesn't, as zip is an expression and multi-sequence loops aren't. > https://docs.rs/itertools/latest/itertools/macro.izip.html https://docs.rs/itertools/latest/itertools/macro.izip.html External libraries aren't part of a language. > Which is not what I wrote. I admit, I read over the "almost" in "you almost never need more than 3". > It also could hardly be less relevant: it's an issue in an AoS structure because all your objects have that overhead, therefore that's your total overhead. > Here it's 15 or 25% padding in a single value within a stackframe. You're probably wasting more stackframe space due to the compiler not bothering reusing temporally dead locations. That's not true: arrays are byte-addressable so inside an array the alignment can be shorter. An array of 121 33-byte values is 3993 bytes in size, an array of 121 usizes is 968 bytes in size, and assuming enums resolve to 32-bit values an array of 121 enums is also 484 bytes in size. There is no overhead here. This has advantages and disadvantages. Unaligned access is slower in general but in many cases and unaligned array can be faster because of how many of its entries can be loaded into the CPU cache. There's no definite advantage here in terms of CPU performance, but in terms of RAM usage there is. > Until they are not. When does a for loop ever become faster than a generator? The values being mapped over are already evaluated, there is no lazy loading+early stopping to take advantage of the generator.

jeroenhd 4y ago

> Which means you can implement yours to fit your needs. Which this doesn't, as zip is an expression and multi-sequence loops aren't. > https://docs.rs/itertools/latest/itertools/macro.izip.html https://docs.rs/itertools/latest/itertools/macro.izip.html External libraries aren't part of a language. > Which is not what I wrote. I admit, I read over the "almost" in "you almost never need more than 3". > It also could hardly be less relevant: it's an issue in an AoS structure because all your objects have that overhead, therefore that's your total overhead. > Here it's 15 or 25% padding in a single value within a stackframe. You're probably wasting more stackframe space due to the compiler not bothering reusing temporally dead locations. That's not true: arrays are byte-addressable so inside an array the alignment can be shorter. An array of 121 33-byte values is 3993 bytes in size, an array of 121 usizes is 968 bytes in size, and assuming enums resolve to 32-bit values an array of 121 enums is also 484 bytes in size. There is no overhead here. This has advantages and disadvantages. Unaligned access is slower in general but in many cases and unaligned array can be faster because of how many of its entries can be loaded into the CPU cache. There's no definite advantage here in terms of CPU performance, but in terms of RAM usage there is. > Until they are not. When does a for loop ever become faster than a generator? The values being mapped over are already evaluated, there is no lazy loading+early stopping to take advantage of the generator.