Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Optimizing structure memory allocation

Reply
Thread Tools

Optimizing structure memory allocation

 
 
rahul
Guest
Posts: n/a
 
      05-27-2008
How is the memory allocated for structures? I need to optimize the
memory usage and bit fields are not doing the trick.

Any details about the memory allocation for the structures would be a
great help.

PS - I already have asked this in gcc group. Please refrain from
directing me towards other groups.
 
Reply With Quote
 
 
 
 
Richard Tobin
Guest
Posts: n/a
 
      05-27-2008
In article <(E-Mail Removed)>,
rahul <(E-Mail Removed)> wrote:

>How is the memory allocated for structures? I need to optimize the
>memory usage and bit fields are not doing the trick.
>
>Any details about the memory allocation for the structures would be a
>great help.


You'll probably get better help if you ask a more specific question.
Show us what you want to put in the structure.

The members of a struct are stored in the order you specify. Some
members may have types that require a particular alignment, typically
equal to their size. For example, while chars can go anywhere you may
find that if ints are 4 bytes long then they are always placed on
4-byte boundaries. This is common even if the processor allows
arbitrary alignment, because it's usually faster to access
suitably-aligned data.

Suppose shorts are 2 bytes and ints are 4, with corresponding
alignment requirements, and you want to store 2 chars, a short, and an
int in your struct. These could fit in 8 bytes, and will if you order
them correctly, for example

struct foo {
int a;
short b;
char c, d;
};

but if you do

struct foo2 {
char c;
int a;
char d;
short b;
};

it will take 12 bytes, because the 3 bytes after c and the byte after d
are wasted.

If you use bitfields, then you have to consider similar issues at the
bit level. Adjacent bitfields that fit within a "unit" (probably an
int) will be packed together, so don't spread them out amongst other
members of the struct, and try to order them so that they don't go
over too many int boundaries.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)
 
Reply With Quote
 
 
 
 
Antoninus Twink
Guest
Posts: n/a
 
      05-27-2008
On 27 May 2008 at 12:25, rahul wrote:
> How is the memory allocated for structures? I need to optimize the
> memory usage and bit fields are not doing the trick.
>
> PS - I already have asked this in gcc group. Please refrain from
> directing me towards other groups.


You might want to look at gcc's packed attribute, which "specifies that
a variable or structure field should have the smallest possible
alignment - one byte for a variable, and one bit for a field, unless you
specify a larger value with the aligned attribute."

You can either pack specific fields, e.g.

struct foo {
char a;
int b __attribute__((packed));
};

or whole structs at once, e.g.

struct bar {
int a;
char b;
int c;
char d;
int e;
} __attribute__((packed));

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-27-2008
Antoninus Twink <(E-Mail Removed)> writes:
> On 27 May 2008 at 12:25, rahul wrote:
>> How is the memory allocated for structures? I need to optimize the
>> memory usage and bit fields are not doing the trick.
>>
>> PS - I already have asked this in gcc group. Please refrain from
>> directing me towards other groups.

>
> You might want to look at gcc's packed attribute,

[...]

which is, of course, off-topic in comp.lang.c.

rahul, you asked us not to direct you to other groups. Why?
Questions about gcc-specific features are appropriate in gnu.gcc.help;
they are not appropriate in comp.lang.c.

Or you can consult the extensive documentation that comes with gcc.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      05-27-2008
In article <g1h08r$1c9f$(E-Mail Removed)>,
Richard Tobin <(E-Mail Removed)> wrote:
>In article <(E-Mail Removed)>,
>rahul <(E-Mail Removed)> wrote:


>>How is the memory allocated for structures? I need to optimize the
>>memory usage and bit fields are not doing the trick.


>The members of a struct are stored in the order you specify.


Expanding slightly on Richard's answer for emphasis:

C *requires* that structure members be placed in the order given,
and in increasing address order in memory. Storing the members in
the order coded is not just a matter of convention: it is part
of the language definition. As is the fact that alignment restrictions
exist and are adhered to by the compiler by adding unnamed padding
between structure members if needed (or advised) by the target machine.
--
"All is vanity." -- Ecclesiastes
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-27-2008
http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
> In article <g1h08r$1c9f$(E-Mail Removed)>,
> Richard Tobin <(E-Mail Removed)> wrote:
>>In article <(E-Mail Removed)>,
>>rahul <(E-Mail Removed)> wrote:

>
>>>How is the memory allocated for structures? I need to optimize the
>>>memory usage and bit fields are not doing the trick.

>
>>The members of a struct are stored in the order you specify.

>
> Expanding slightly on Richard's answer for emphasis:
>
> C *requires* that structure members be placed in the order given,
> and in increasing address order in memory. Storing the members in
> the order coded is not just a matter of convention: it is part
> of the language definition. As is the fact that alignment restrictions
> exist and are adhered to by the compiler by adding unnamed padding
> between structure members if needed (or advised) by the target machine.


Right, but it's perfectly legal for the alignment restriction to be
"any alignment is ok". It's also legal (but silly) for the compiler
to insert padding whether it's required for alignment or not.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      05-27-2008
On Tue, 27 May 2008 13:02:33 -0700, Keith Thompson wrote:
> Right, but it's perfectly legal for the alignment restriction to be "any
> alignment is ok". It's also legal (but silly) for the compiler to
> insert padding whether it's required for alignment or not.


It's not silly if older systems required a particular alignment, newer
systems don't, but the compiler still inserts padding to maintain binary
compatibility with those older systems. It's good that implementors are
given a lot of freedom in choosing what works best for their systems.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-27-2008
Eric Sosman <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> (E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
>>> C *requires* that structure members be placed in the order given,
>>> and in increasing address order in memory. Storing the members in
>>> the order coded is not just a matter of convention: it is part
>>> of the language definition. As is the fact that alignment restrictions
>>> exist and are adhered to by the compiler by adding unnamed padding
>>> between structure members if needed (or advised) by the target machine.

>> Right, but it's perfectly legal for the alignment restriction to be
>> "any alignment is ok". It's also legal (but silly) for the compiler
>> to insert padding whether it's required for alignment or not.

>
> The ambiguity lies in "requirement." On one popular
> platform, for example, a `double' can be accessed at any
> address divisible by four, but can be accessed more quickly
> if the address is also divisible by eight. Should the
> alignment "requirement" be taken as four or as eight?


Could be either. My point is that the compiler is allowed to insert,
say, 16 bytes of padding, even if it doesn't help performance at all.

It's just an example of the kind of assumption that shouldn't be made
in portable code.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      05-27-2008
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:

>Could be either. My point is that the compiler is allowed to insert,
>say, 16 bytes of padding, even if it doesn't help performance at all.
>
>It's just an example of the kind of assumption that shouldn't be made
>in portable code.


I disagree (though obviously only up to a point). It's perfectly
legal for a compiler to insert pointless alignment, but it's also
reasonable to assume that it won't. For example, given any sensible
alignment scheme you will get good packing by ordering members by
decreasing size (int then short then char for example). A portable
program can quite reasonably order structure members on this
assumption, and if it turns out to be false then the blame should be
assigned to the implementation, not the programmer.

We aren't obliged to ignore common sense in our programs, even if
conforming compilers can defeat it.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-28-2008
Eric Sosman <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> Eric Sosman <(E-Mail Removed)> writes:
>>> Keith Thompson wrote:
>>>> [...] It's also legal (but silly) for the compiler
>>>> to insert padding whether it's required for alignment or not.
>>> The ambiguity lies in "requirement." On one popular
>>> platform, for example, a `double' can be accessed at any
>>> address divisible by four, but can be accessed more quickly
>>> if the address is also divisible by eight. Should the
>>> alignment "requirement" be taken as four or as eight?

>> Could be either. My point is that the compiler is allowed to insert,
>> say, 16 bytes of padding, even if it doesn't help performance at all.

>
> ... and my point was about the word "silly:" Until you
> can nail down "requirement" you can't assess the silliness
> of the padding scheme.


Ok, good point.

To re-state my point more precisely, a compiler is allowed to insert
padding between struct members even if doing so has no benefit
whatsoever. (I don't know of any compilers that actually do so.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
memory allocation for structure array jvax C Programming 4 11-24-2010 11:43 PM
static memory allocation versus dynamic memory allocation Ken C Programming 24 11-30-2006 12:37 AM
Memory allocation in Structure to Structure pra_ramli@rediffmail.com C++ 2 03-09-2006 05:51 AM
What is the difference between dynamic memory allocation,and stack allocation ? chris C++ 6 10-28-2005 05:27 AM
Memory Allocation for Structure / Class akshay4friend@yahoo.com C++ 2 02-16-2005 04:08 PM



Advertisments