Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1355 > unrolled thread

Structure Packing.

Back to article view | Back to comp.std.c

Contents

  Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-06 17:27 -0700
    Re: Structure Packing. James Kuyper <jameskuyper@verizon.net> - 2012-06-06 21:19 -0400
      Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-11 22:39 -0400
        Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 09:21 -0400
          Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 11:51 -0400
            Re: Structure Packing. Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-06-12 18:37 +0200
              Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 15:06 -0400
                Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 16:22 -0400
                  Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 17:44 -0400
                    Re: Structure Packing. Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-06-13 15:53 +0200
                      Re: Structure Packing. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-06-18 12:37 +0300
          Re: Structure Packing. Martin Shobe <martin.shobe@yahoo.com> - 2012-06-12 16:22 +0000
            Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 15:24 -0400
              Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 16:33 -0400
                Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 17:17 -0400
    Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-06 18:35 -0700
      Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-06 21:58 -0700
        Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-06 23:54 -0700
          Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-07 07:47 -0700
            Re: Structure Packing. James Kuyper <jameskuyper@verizon.net> - 2012-06-07 12:39 -0400
      Re: Structure Packing. jacob navia <jacob@spamsink.net> - 2012-06-07 11:14 +0200
        Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-07 09:46 -0700
          Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-07 11:57 -0700

Page 2 of 2 — ← Prev page 1 [2]

#1360

Le 07/06/12 03:35, Keith Thompson a écrit :
> Given that the two members are of the same type, it's very likely that
> there will be no padding between them

Not true, for instance for the x86 with

struct s{
    double var1;
    double var2;
};

A compiler may align var2 to be 16 bytes after var1 so that accesses are 
always at a 16 byte boundary for performance reasons. The xmm registers 
(where all double data is stored in modern implementations) have a 
faster "aligned" access to double data instruction.

It can be argued that the comiler could store var1 and var2 in a single 
16 byte sequence so that they could be loaded into a single xmm register 
but maybe for internal code generation reasons that would be not desired 
(risk of polluting the high/low part, etc, necessity of
complex analysis to determine that the lower part and the higher part
aren't destroyed by some operation, etc).

[toc] | [prev] | [next] | [standalone]

#1363

jacob navia <jacob@spamsink.net> writes:
> Le 07/06/12 03:35, Keith Thompson a écrit :
>> Given that the two members are of the same type, it's very likely that
>> there will be no padding between them
>
> Not true, for instance for the x86 with
>
> struct s{
>    double var1;
>    double var2;
> };
>
> A compiler may align var2 to be 16 bytes after var1 so that accesses
> are always at a 16 byte boundary for performance reasons. The xmm
> registers (where all double data is stored in modern implementations)
> have a faster "aligned" access to double data instruction.

Hmm.  So the most efficient alignment for an 8-byte type is 16 bytes?
I find that odd.  (I'm not familiar with xmm.)

For what it's worth, gcc doesn't do this, at least by default. I know
that's just one data point.

> It can be argued that the comiler could store var1 and var2 in a
> single 16 byte sequence so that they could be loaded into a single xmm
> register but maybe for internal code generation reasons that would be
> not desired (risk of polluting the high/low part, etc, necessity of
> complex analysis to determine that the lower part and the higher part
> aren't destroyed by some operation, etc).

Do any C compilers actually do this?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1364

On Thursday, 7 June 2012 12:46:45 UTC-4, Keith Thompson  wrote:
> jacob navia <jacob@spamsink.net> writes:
> > Le 07/06/12 03:35, Keith Thompson a écrit :
> >> Given that the two members are of the same type, it's very likely that
> >> there will be no padding between them
> >
> > Not true, for instance for the x86 with
> >
> > struct s{
> >    double var1;
> >    double var2;
> > };
> >
> > A compiler may align var2 to be 16 bytes after var1 so that accesses
> > are always at a 16 byte boundary for performance reasons. The xmm
> > registers (where all double data is stored in modern implementations)
> > have a faster "aligned" access to double data instruction.
> 
> Hmm.  So the most efficient alignment for an 8-byte type is 16 bytes?
> I find that odd.  (I'm not familiar with xmm.)
> 
> For what it's worth, gcc doesn't do this, at least by default. I know
> that's just one data point.
> 
> > It can be argued that the comiler could store var1 and var2 in a
> > single 16 byte sequence so that they could be loaded into a single xmm
> > register but maybe for internal code generation reasons that would be
> > not desired (risk of polluting the high/low part, etc, necessity of
> > complex analysis to determine that the lower part and the higher part
> > aren't destroyed by some operation, etc).
> 
> Do any C compilers actually do this?
> 
> -- 
> Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"


SSE originally added eight new 128-bit registers known as XMM0 through XMM7. The AMD64 extensions from AMD (originally called x86-64) added a further eight registers XMM8 through XMM15, and this extension is duplicated in the Intel 64 architecture. There is also a new 32-bit control/status register, MXCSR. The registers XMM8 through XMM15 are accessible only in 64-bit operating mode.
 
its now optimized for 16byte aligned access and performs operation in 1 cylce. This is why memcpy etc are so much faster when src and target are 16byte aligned. youll see stuff like 
:loop
movdq xmmo, mem1; 
movdq mem2 xmm0; 
jump loop

so x64 compilers tend to 16byte align variables. or pass variables in xmm0 registers. x64 has its own calling conventions etc to take advantage of the new architecture.

So it is quicker to move 16bytes than say 9bytes, maybe even quicker than 8 bytes unless its aligned on a 16byte boundary. The cache prefetchers have also been optimized for this. 
AFAIK



On Thursday, 7 June 2012 12:46:45 UTC-4, Keith Thompson  wrote:
> jacob navia <jacob@spamsink.net> writes:
> > Le 07/06/12 03:35, Keith Thompson a écrit :
> >> Given that the two members are of the same type, it's very likely that
> >> there will be no padding between them
> >
> > Not true, for instance for the x86 with
> >
> > struct s{
> >    double var1;
> >    double var2;
> > };
> >
> > A compiler may align var2 to be 16 bytes after var1 so that accesses
> > are always at a 16 byte boundary for performance reasons. The xmm
> > registers (where all double data is stored in modern implementations)
> > have a faster "aligned" access to double data instruction.
> 
> Hmm.  So the most efficient alignment for an 8-byte type is 16 bytes?
> I find that odd.  (I'm not familiar with xmm.)
> 
> For what it's worth, gcc doesn't do this, at least by default. I know
> that's just one data point.
> 
> > It can be argued that the comiler could store var1 and var2 in a
> > single 16 byte sequence so that they could be loaded into a single xmm
> > register but maybe for internal code generation reasons that would be
> > not desired (risk of polluting the high/low part, etc, necessity of
> > complex analysis to determine that the lower part and the higher part
> > aren't destroyed by some operation, etc).
> 
> Do any C compilers actually do this?
> 
> -- 
> Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.std.c

csiph-web