Guarantees about struct layout

[lsh]

When making a struct, are there any guarantees about struct layout? Will the struct pick the most efficient packing, or will it be C-style?

Personally, I would prefer something Rust-like, where it picks the best layout by default, but adding a decorator like @struct_layout("C") would force it to be C-like. I think it also makes sense for @value or @register_passable("trivial") to perhaps have the C-style layout, but I could be wrong.

[lattner]

We haven't discussed this, but I agree with you that an opt-in decorator that specifies layout is the right way to go. It seems good for the compiler to be able to reorder fields (e.g. eliminate internal padding) to allow programmers to not have to worry about this, but people putting bits on a wire or dealing with c compatibility should be able to get that. We will need to properly design this out

[soraros]

Maybe library evolution/ABI stability a la Swift?

[tiamiceli]

Is there an issue in the backlog I can watch to monitor when this capability is addressed? We have a proof-of-concept project that will not move forward until this is available. I would like to get a notification so our team can return this line of prototyping.

[guidorice]

Consider (also) adding an SOA / AOS data structure like Zig's MultiArrayList. I imagine it would be possible to port that from Zig to Mojo already.

https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-in-userland-40m0
https://github.com/ziglang/zig/blob/master/lib/std/multi_array_list.zig

[Brian-M-J]

Consider (also) adding an SOA / AOS data structure like Zig's MultiArrayList. I imagine it would be possible to port that from Zig to Mojo already.

A more generalized solution is provided by Kokkos:

A data parallel computational kernel’s data access pattern can have a significant impact on its performance. On a CPU a computational kernel should have blocked data access pattern; however, on a GPU the computational kernel should have a coalesced data access pattern. This conflicting data access pattern requirement is commonly referred to as the array of structures (AoS) versus structure of arrays (SoA) problem. We solve the AoS vs. SoA performance portability problem by controlling the data parallel execution of computational kernels on a device, providing a multidimensional array data structure for those kernels to use, and choosing the multidimensional array layout that results in the required memory access pattern.

Source - Kokkos: Enabling manycore performance portability through polymorphic memory access patterns

Basically, it automatically chooses what data layout to use depending on what is optimal for the given hardware. This sounds like something autotuning is meant for.

Kokkos' programming model makes programs generic over any hardware.

Another PL I hope Mojo takes inspiration from is Halide:

The dimensions of the storage layout for a function’s
results can similarly be reordered, allowing common transformations such as column- versus row-major layouts.

Source - Halide: Decoupling Algorithms from Schedules for High-Performance Image Processing

Separating algorithm from scheduling in all use cases (not just the 1 or 2 use cases of DSLs like Halide) would massively boost developer productivity.