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:

These abstraction concepts allow the formulation of generic algorithms and data structures which can then be mapped to different types of architectures. Effectively, they allow for compile time transformation of algorithms to allow for adaptions of varying degrees of hardware parallelism as well as of the memory hierarchy.

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

[This approach] produces schedules which are on average almost twice as fast as the existing Halide autoscheduler without autotuning, or more than twice as fast with, and is the first automatic scheduling algorithm to significantly outperform human experts on average.

Source - Learning to Optimize Halide with Tree Search and Random Programs

Using existing programming tools, writing high-performance image processing code requires sacrificing readability, portability, and modularity. We argue that this is a consequence of conflating what computations define the algorithm, with decisions about storage and the order of computation. We refer to these latter two concerns as the schedule, including choices of tiling, fusion, recomputation vs. storage, vectorization, and parallelism.

Source - decoupling algorithms from schedules for easy optimization of image processing pipelines

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.