Bartc wrote:

>

"James Kuyper" <ja*********@verizon.netwrote in message

news:rxVnk.739$7N1.719@trnddc06...
>daniel wrote:
>>Hello ,

I always had the feeling that is better to have char arrays with the

size equal to a power of two.

For example:

char a_str[128]; // feels ok

char b_str[100]; //feels not ok.

Is that true , and if is true then what is the reason behind this? ( I

suppose that is something related to memory alignment but it's not

very clear in my mind ).

A detailed explanation would be very useful.

>In that case, a length that is a power of 2 does indeed provide a

minor benefit. Many computer systems push around data more efficiently

when it has a size which is a multiple of a certain number of bytes.

I don't quite understand how having an unused 28 bytes on the end of a

100-byte array is going to help.

It won't. The only case where you should ever use this criterion for

deciding for deciding the length of the array, is if you're still at the

point of deciding whether to design the program to work with a maximum

of 100 bytes, or a maximum of 128 bytes. I'm assuming that, regardless

of what decision is made, there will be cases which use the remaining 28

bytes; cases which, at that point of the design cycle, you're still free

to decide whether or not the program should handle those cases as

normal, or as exceptions to be handled by some other method.

Prime example: fields meant to hold people's names. There's no

reasonable fixed length that can deal with every possible name. If

variable-length fields are not acceptable (which is often the case),

then the exact length you should use is fairly arbitrary, and might as

well be chosen based in part upon the minor efficiencies of power-of-2.

If a machine can do 8-byte moves then there might be a case for a

104-byte array size instead of 100, because of the fiddly 4 bytes at the

end, but no need for 128.

You're assuming 8-bytes is the special number, and for some systems, for

some purposes, it is. However, there's many different sizes that carry

special advantages, for different purposes. I've known the technical

details of systems where sizes of 16 bytes, 128 bytes, 256 bytes and

1024 bytes have been relevant, for a variety of different reasons. When

I consider the small number of machines which I'm personally familiar

with, compared to the huge variety of real-world machines for which C

code is written, I wouldn't recommend ignoring the possibility that any

particular power of 2 might be relevant on some system, somewhere. On

the flip side, I wouldn't recommend attaching any great significance to

that possibility, either.

That's assuming C can move around entire

arrays, which it can't directly.

I'm not sure what you mean by that comment. I use memcpy() frequently

for that purpose. Some versions of memcpy() do work more efficiently on

objects which have particular alignments, and a size which is a multiple

of that alignment, which is usually a power of 2.

... And anyway this is a matter for the

compiler to worry about.

The issue I'm thinking about cannot be decided by the compiler; it is

inherently exclusively in the domain of the designer of a program. You

may be thinking of a different issue than I am.

>Since every power of 2 is a multiple of all smaller powers of 2,

rounding an array size up to the next power of 2 is a choice that in

general won't hurt, an on many systems will slightly improve the

efficiency of your code.

Rounding a 1048577-byte array up to 2097152 bytes I think would

definitely hurt.

If you know that 1048577 bytes is guaranteed to be sufficient, that's

the size you should use. The requirements for reasonable use of this

reason for selecting the size of an array to be pow(2,N) are as follows:

the chance that a size greater than 'n' will be needed is unacceptably

high for n==pow(2,N-1), and is acceptably low at n==pow(2,N+1), and the

transition point between "unacceptably high" and "acceptably low" is

sufficiently poorly known to justify estimating it as pow(2,N).

To use my example above; if I had a complete list of every name that

might ever be entered in my database, or at least a statistical summary

of the characteristics of such a list, and sufficient knowledge of how

those names might be used, I could put together a mathematical model

that calculates the costs and benefits of using different lengths for

the name field, and solve that model to determine the optimal length. If

the issue was sufficiently important, that is precisely what I would do,

and I would set the field length to that optimum. However, it's

relatively rare to have that kind of information available for free-form

text fields, and it's not unusual to have a similar lack of information

for other kinds of arrays. Even if it is technically feasible to collect

the relevant information, it might be unacceptably expensive. Under such

circumstances, rounding a rough estimate of the space needed to the next

power of 2 is entirely reasonable.