https://github.com/ZigaSajovic/optimizing-the-memory-layout-of-std-tuple

Would be interesting to adapt it for std.tuple.

On Saturday, 13 June 2020 at 19:11:33 UTC, Andrei Alexandrescu wrote:
> https://github.com/ZigaSajovic/optimizing-the-memory-layout-of-std-tuple
>
> Would be interesting to adapt it for std.tuple.

Look possible. At first glance, staticSort on the template variadic argument based on a predicate template that looks at alignment of element maybe.

  struct Tuple(A...)
  {
      staticsort!(pred, A) members;
  }

although with the possibility to name each member this will be in practice more complicated

On 13.06.20 21:11, Andrei Alexandrescu wrote:
> https://github.com/ZigaSajovic/optimizing-the-memory-layout-of-std-tuple
> 
> Would be interesting to adapt it for std.tuple.
> 

That's likely to run into the following arbitrary language limitation:

---
alias Seq(T...)=T;
struct T{
    int a,b;
    alias expand=Seq!(b,a);
}
void main(){
    import std.stdio;
    writeln(T(1,2).expand);
}
---
Error: need `this` for `b` of type `int`
Error: need `this` for `a` of type `int`
---

Another question is if automatic packing is worth making the layout harder to predict.

On 6/13/20 7:30 PM, Timon Gehr wrote:
> Another question is if automatic packing is worth making the layout harder to predict.

I think so. Size does matter.

On Sunday, 14 June 2020 at 03:08:48 UTC, Andrei Alexandrescu wrote:
> On 6/13/20 7:30 PM, Timon Gehr wrote:
>> Another question is if automatic packing is worth making the layout harder to predict.
>
> I think so. Size does matter.

If you are talking about implementing a tuple type into the language, and that the *default* behavior should be that it stores the elements in a tuple in memory to be as efficiently as it can be. That would be more limiting. If implemented correctly then a tuple that store it in memory the way it is specified in order. Then you could implement the storing one on top of it with a library implementation. This will allow the user to customize how it is stored. What is efficient or not could differ from person to person and what they are doing. If it was implemented in the language with it changing the storage to be organized for size. Then you couldn't implement anything any other way, you are stuck with what is forced on you.

On 6/13/20 11:55 PM, Avrina wrote:
> On Sunday, 14 June 2020 at 03:08:48 UTC, Andrei Alexandrescu wrote:
>> On 6/13/20 7:30 PM, Timon Gehr wrote:
>>> Another question is if automatic packing is worth making the layout harder to predict.
>>
>> I think so. Size does matter.
> 
> If you are talking about implementing a tuple type into the language, 

negative

On Sunday, 14 June 2020 at 03:57:40 UTC, Andrei Alexandrescu wrote:
> On 6/13/20 11:55 PM, Avrina wrote:
>> On Sunday, 14 June 2020 at 03:08:48 UTC, Andrei Alexandrescu wrote:
>>> On 6/13/20 7:30 PM, Timon Gehr wrote:
>>>> Another question is if automatic packing is worth making the layout harder to predict.
>>>
>>> I think so. Size does matter.
>> 
>> If you are talking about implementing a tuple type into the language,
>
> negative

The situation also applies to the only tuple implementation in D. If you are proposing a new type with emphasis on reducing the footprint of the tuple then I don't see a problem with that. Changing the existing tuple implementation would be problematic.

On Sunday, 14 June 2020 at 16:26:17 UTC, Avrina wrote:
>
> The situation also applies to the only tuple implementation in D. If you are proposing a new type with emphasis on reducing the footprint of the tuple then I don't see a problem with that. Changing the existing tuple implementation would be problematic.

Presumably any such change would be made backwards-compatible. So Tuple.opIndex and Tuple.expand would still return elements in the order specified by the user, even if that order is different from the internal storage order.

On 14.06.20 20:25, Paul Backus wrote:
> On Sunday, 14 June 2020 at 16:26:17 UTC, Avrina wrote:
>>
>> The situation also applies to the only tuple implementation in D. If you are proposing a new type with emphasis on reducing the footprint of the tuple then I don't see a problem with that. Changing the existing tuple implementation would be problematic.
> 
> Presumably any such change would be made backwards-compatible. So Tuple.opIndex and Tuple.expand would still return elements in the order specified by the user, even if that order is different from the internal storage order.

Indeed, that's why I noted that the obvious way to achieve that does not work. Although some assumptions will break, for example, there might be code that assumes that tupleof does the same thing as expand.

I was thinking about e.g., manual cache optimization, but reducing size in the common case where such considerations are not made may well be more important. If it can be done at all; I am not currently aware of a workaround.

On 6/14/20 12:26 PM, Avrina wrote:
> On Sunday, 14 June 2020 at 03:57:40 UTC, Andrei Alexandrescu wrote:
>> On 6/13/20 11:55 PM, Avrina wrote:
>>> On Sunday, 14 June 2020 at 03:08:48 UTC, Andrei Alexandrescu wrote:
>>>> On 6/13/20 7:30 PM, Timon Gehr wrote:
>>>>> Another question is if automatic packing is worth making the layout harder to predict.
>>>>
>>>> I think so. Size does matter.
>>>
>>> If you are talking about implementing a tuple type into the language,
>>
>> negative
> 
> The situation also applies to the only tuple implementation in D. If you are proposing a new type with emphasis on reducing the footprint of the tuple then I don't see a problem with that. Changing the existing tuple implementation would be problematic.

No. There's no guarantee made by std.tuple as to layout. We can't be overly conservative for the sake of supporting code that assumes too much.