Padding structs


(Alexandre Lopoukhine) #1

Hello everyone,

I have a question about structs in Swift. Is there a reason for the padding? Is there a plan to remove it, to make a more compact representation, making them similar to structs in C?

Thank you,

— Sasha


(Joe Groff) #2

What are you referring to in particular? We do plan to change Swift's default layout strategy to minimize padding, but it's surprising that there are cases today where Swift structs have more padding than equivalent C structs.

-Joe

···

On Jan 19, 2016, at 10:51 AM, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> wrote:

Hello everyone,

I have a question about structs in Swift. Is there a reason for the padding? Is there a plan to remove it, to make a more compact representation, making them similar to structs in C?


(Joe Groff) #3

Also, this is probably a better topic for swift-users than swift-evolution.

-Joe

···

On Jan 19, 2016, at 10:53 AM, Joe Groff <jgroff@apple.com> wrote:

On Jan 19, 2016, at 10:51 AM, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> wrote:

Hello everyone,

I have a question about structs in Swift. Is there a reason for the padding? Is there a plan to remove it, to make a more compact representation, making them similar to structs in C?

What are you referring to in particular? We do plan to change Swift's default layout strategy to minimize padding, but it's surprising that there are cases today where Swift structs have more padding than equivalent C structs.


(Alexandre Lopoukhine) #4

Thanks Joe,

I was wondering which group I should write to, but I decided that part of the question was related to the evolution of swift.

The part related to current usage stems from trying to encode a struct containing a UInt8 and UInt32, and it taking up 8 bytes, unexpectedly to me.

The same happens with a tuple containing the same values.

— Sasha

···

On 19 Jan 2016, at 19:54, Joe Groff <jgroff@apple.com> wrote:

On Jan 19, 2016, at 10:53 AM, Joe Groff <jgroff@apple.com> wrote:

On Jan 19, 2016, at 10:51 AM, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> wrote:

Hello everyone,

I have a question about structs in Swift. Is there a reason for the padding? Is there a plan to remove it, to make a more compact representation, making them similar to structs in C?

What are you referring to in particular? We do plan to change Swift's default layout strategy to minimize padding, but it's surprising that there are cases today where Swift structs have more padding than equivalent C structs.

Also, this is probably a better topic for swift-users than swift-evolution.

-Joe


(Joe Groff) #5

A C struct would be the same size by default, since UInt32's natural alignment is to 4 bytes. Aligned accesses are generally much more efficient (though less so on recent Intel and ARM microarchitectures, I hear).

-Joe

···

On Jan 19, 2016, at 11:00 AM, Alexandre Lopoukhine <superlopuh@gmail.com> wrote:

Thanks Joe,

I was wondering which group I should write to, but I decided that part of the question was related to the evolution of swift.

The part related to current usage stems from trying to encode a struct containing a UInt8 and UInt32, and it taking up 8 bytes, unexpectedly to me.

The same happens with a tuple containing the same values.


(Alexandre Lopoukhine) #6

That makes sense. Thank you.

···

On 19 Jan 2016, at 20:02, Joe Groff <jgroff@apple.com> wrote:

On Jan 19, 2016, at 11:00 AM, Alexandre Lopoukhine <superlopuh@gmail.com> wrote:

Thanks Joe,

I was wondering which group I should write to, but I decided that part of the question was related to the evolution of swift.

The part related to current usage stems from trying to encode a struct containing a UInt8 and UInt32, and it taking up 8 bytes, unexpectedly to me.

The same happens with a tuple containing the same values.

A C struct would be the same size by default, since UInt32's natural alignment is to 4 bytes. Aligned accesses are generally much more efficient (though less so on recent Intel and ARM microarchitectures, I hear).

-Joe