Storage of char in 64 bit machine

[aruna.mysore]

Hi all,

I have a simple definitioin in a C file something like this.

main()
{
char a;
.......
int k;
}

Since character is 8 bit, how is it stored in the machine in a 64 bit
machine. If it is word aligned, what about the rest of the bytes. What
about the retrievel of the char c, will it be expensive. Is it
expensive w.r.t read or write.

Thanx and Regards,
Aruna

[websnarf]

Mikhail Teterin wrote:

Stephen Sprunk wrote:

The implementation is likely to have a very, very clever strcmp() that
will perform at least as well as your code (possibly doing the same thing
internally, if it's known to be safe) and likely even better if the
compiler is reasonably modern due special knowledge and treatment of
common functions/idioms.

Well, here are some benchmarks comparing the use of strcmp() to compare
short character strings (4 characters).

You shouldn't fall for the "strawman" argument, especially when its
clearly wrong. Obviously int32_t comparison will annihilate strcmp()
in real world code regardless of how good the compiler is. The only
chance the compiler has is to support cross-file inlining, constant
propagation, and a kind of global string analysis that just isn't going
to yeild fruitful optimizations in general. And that would be just to
try to pull even with integer comparison. If you used memcmp() instead
of strcmp(), things *might* be different.

Benching this is unnecessary. *Any* inner loop that contains a str*
function is always going to be way slower than any reasonably
reconsidered alternative. That's a rule of thumb people should just
always be aware of. In many cases, the std C library is actually
behind by actual orders of complexity. Here its slower because of the
poor not really parallizable str* function design (it ends up
pointlessly scanning for 4 '\0' characters no matter what).

[...] It seems, that for the limited cases like this -- when the strings are of
the same length and fit nicely into an integer type -- treating them as such
is hugely beneficial. And, contrary to authoritative assertions posted in
this thread, compiler is NOT able to detect such cases.

These "authoritie s" are overstepping their bounds. They have decided
that this is a newsgroup just about the C standard. Practical C
programming is way beyond both the scope of this newsgroup and those so
called authorities. Their brains have, over the years, become
hardwired in a very specific way -- if you ask the question "how do I
improve the performance of some C code" they will definitively answer
"you can't; C is not characterizable in terms of performance and
furthermore your efforts will always be made irrelevant because of how
good your compiler is, and besides you are premature in your attempts
to optimize". It doesn't matter *how* you ask the question, they will
always answer the question that way. So you should not take their
naysaying too seriously, they are just replaying a
keyboard/brain-macro.

The issue with your "trick" is that its not portable. But that's
typical of anything useful that most people do in the C language.
Otherwise, yes of course it will lead to an enormous performance
improvement (after all you are removing a str* from an inner loop.)

To make it portable, you probably want to try to isolate the *system*
through ifdef's. The reason is that you need to isolate *systems* that
align things on at most 32-bit boundaries. The exceptions will be
characterized by system. Then there's the whole sizeof(int32_t) issue
-- you probably just want to deal with 3 cases of 1, 2, 4 and forget
the other ones. Then, since you know that these strings are exactly 3
characters, you should use *memcmp()*, not strcmp() (its a little
faster) on the fallback cases.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[websnarf]

Eric Sosman wrote:

we******@gmail. com wrote:

Mikhail Teterin wrote:

>So, comparing, say, 4-char arrays (like currency codes) can NOT be done in
the following way?

typedef union {
char acCUR[4];
int32_t iCUR;
} xCUR;
[...]

Having to call a strcmp() in such cases seems like a bad waste to me, but I
don't see, how the compiler could possibly optimize such a code without the
trick above...

The compiler cannot do that optimization because its not correct.
strcmp() stops executing its inner loop once it reads a '\0'. I.e.,
its possible for the strcmp()'s to be equal where the int32_t's are not
equal. Also the compiler is allowed to align struct entries as they
like. So on a 64 bit big endian system, the int32_t might not
intersect with any of the 4 acCur[] characters.

Agree with the first part but not with the second. Look
again: it's not a struct, but a union.

If the system is a 64 bit one, then it might force all entries to be
aligned to 64 bit boundaries. Then if its big-endian, it might throw
the relevant bits of the int32_t entry into the high 4 bytes of the 8
byte word. I.e., the acCUR contents might just be overlapping the
*padding* that's put in front of the 32-bit entry. So what exactly do
I have to look again at?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Eric Sosman]

we******@gmail. com wrote:

Eric Sosman wrote:

>>we******@gmai l.com wrote:

>>>Mikhail Teterin wrote:

So, comparing, say, 4-char arrays (like currency codes) can NOT be done in
the following way?

typedef union {
char acCUR[4];
int32_t iCUR;
} xCUR;
[...]

[...] Also the compiler is allowed to align struct entries as they
like. So on a 64 bit big endian system, the int32_t might not
intersect with any of the 4 acCur[] characters.

Agree with the first part but not with the second. Look
again: it's not a struct, but a union.

If the system is a 64 bit one, then it might force all entries to be
aligned to 64 bit boundaries. Then if its big-endian, it might throw
the relevant bits of the int32_t entry into the high 4 bytes of the 8
byte word. I.e., the acCUR contents might just be overlapping the
*padding* that's put in front of the 32-bit entry. So what exactly do
I have to look again at?

You could look at 6.5.8/5:

"[...] All pointers to members of the same union
object compare equal."

.... and at 6.7.2.1/14:

"[...] A pointer to a union object, suitably converted,
points to each of its members [...] and vice versa."

That is, there is no padding at the start of a union. The
four bytes (assuming CHAR_BIT==8) of the int32_t must occupy
the same four bytes as the char[4] array. If the union as a
whole is padded to eight bytes, the extra four are after the
int32_t and after the char[4], never before them.

Things would be different if he'd used int_least32_t or
int_fast32_t. With the exact-width int32_t he's on solid
ground (still assuming CHAR_BIT==8) as far as the overlap is
concerned, although he's on quicksand in other respects.

--
Eric Sosman
es*****@acm-dot-org.invalid

[CBFalconer]

Mikhail Teterin wrote:

Keith Thompson wrote:

>Didn't we just go over this? Is there some reason you couldn't
have posted the C code as part of your article?

We did. And I ended up convinced, that only inertia (and the desire
to force a newcomer to obey the rules of the club), are what makes
this an issue in the first place.

People with news-readers, that are not MIME-aware will just see
these textual attachments as part of the article.

MIME-aware news-readers will be able to handle them better this way...

Sorry, if it were one file, I would've inlined it, but three --
that's just too much trouble.

I am restraining myself. Don't you realize there are good reasons
for these rules? Many systems will automatically strip any
attachments from news articles, or even destroy the article
altogether.

No, we don't automatically get together and harass all newbies for
the pure unadulterated pleasure of plaguing them. Yes, you are
suffering from paranoia.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

[Mikhail Teterin]

we******@gmail. com wrote:

>I know. Currencies, however, are all 3-character strings (plus the
terminating '\0'). Thus they are perfectly suited to be treated as
int32_t, when convenient.

If that is true, then in fact this is a useful performance boost, but
its platform specific. Personally, I would just capture it like this:
*((int32_t *) &currency) rather than bothering with the union.

A plain string would not neccessarily allign the way an int32_t would
allign, would it? This can cause nasty SIGBUS-es...

>That it is not 100% portable is already rammed into me by the friendly
folks on this board. I'd like to know an example of the actual
hardware/compiler combo, where it would not work, though...

I am pretty sure there are real 64 bit systems (though likely they are
marginal) that will fail to do your trick correctly. Not AMD64, but
some old Crays or Sparc64s might in fact fail (they need to be big
Endian, and align struct/union entries to 64 bits).

That's why I used the union -- does not it ensure correctness even on these
8-byte alligning platforms? I thought, my only problem is with finding the
correct integer type to cover exactly the 4 characters.

And obviously those silly DSPs that don't support int32_t's would just
fail to compile your code.

Compile-time failure is acceptable -- it is the run-time, that worries me.

-mi

[Mikhail Teterin]

Eric Sosman wrote:

Elsethread you have posted an attempt to quantify HOW MUCH,
and your results suggest that the particular "cool" trick you
favor will save ...

0.0000000071303 7 seconds per comparison.

It is 4-6 times faster -- that, the relative, rather than absolute
difference -- is what counts.

A human being can not distinguish a millisecond from a microsecond.

Until the operation needs to be repeated a million time, that is. Because
millisecond becomes 16 minutes, while microsecond -- only a second.

An EOD (End-of-Day) process in a big bank/hedge fund makes (sometimes) many
millions of such currency comparisions as well as assignments (which don't
_really_ require a memcpy/strcpy), etc.

Using pessimal code for the sake of maintaining portability to Digital
Signal Processing boards is even more wasteful than owning an SUV for the
sake of an imaginary (but possible) once-in-a-lifetime off-road ride.

Mikhail, I can see your error and understand it and sympathize

Thank you, thank you. Agreeing to disagree.

-mi

[ena8t8si]

Mikhail Teterin wrote:

Keith Thompson wrote:

Didn't we just go over this? Is there some reason you couldn't have
posted the C code as part of your article?

We did. And I ended up convinced, that only inertia (and the desire to force
a newcomer to obey the rules of the club), are what makes this an issue in
the first place.

What sort of response would have convinced you otherwise?

If the answer is, "There isn't one," then there doesn't
seem to be much point in talking to you, does there?

[Walter Roberson]

In article <16************ ****@aldan.alge bra.com>,
Mikhail Teterin <us*********@al dan.algebra.com wrote:

>An EOD (End-of-Day) process in a big bank/hedge fund makes (sometimes) many
millions of such currency comparisions as well as assignments (which don't
_really_ require a memcpy/strcpy), etc.

>Using pessimal code for the sake of maintaining portability to Digital
Signal Processing boards is even more wasteful than owning an SUV for the
sake of an imaginary (but possible) once-in-a-lifetime off-road ride.

In that End-of-Day processing, is the bank/fund doing nothing when
the currencies do not match, or is the bank/fund doing a currency
conversion? If it is doing a conversion, then eliminate the check
by simply setting the conversion rate for all currencies to themselves
to be 1, and then unconditionally using the conversion routine
with the conversion factor indexed by both conversions.

But the point is moot, because we know that in the OP's code, the
OP is not primarily concerned with speed: the primary concern for
the OP is ease of debugging, and the code is intended by the OP to
be as fast as practical provided the ease of debugging is preserved.
If speed were the primary concern, then the OP's code would have
converted to an arbitrary currency index and then would compare the
indices "millions of times".
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

[Default User]

Mikhail Teterin wrote:

Keith Thompson wrote:

I, for one, will ignore any attachments posted to this newsgroup.

I have not spent much time on this group, but, so far, I have not seen
anything that would make me truly saddened by your decision...

Then you are a fool.

Brian

[Mikhail Teterin]

We went from "don't do this, you idiot, the compiler is much better
optimizing, than you will ever be" to "yeah, it is 4-6 times faster to do
things your way, but it is still not worth the effort".

I think, this is a considerable progress for one thread and will shut up for
a while...

-mi