sizeof...

[thushianthan15]

Greetings!!
Currently i am learning C from K&R.I have DOS & Linux in my
system.When i used sizeof() keyword to compute the size of integer , it
shows different results in DOS and Linux.In DOS it shows integer
occupies 2 bytes , but in Linux it shows 4 bytes.Is sizeof operator
"really" shows the machine data or register size ?
Please help
me!!

[Paul Mesken]

On Tue, 31 May 2005 22:06:52 +0000 (UTC), "Malcolm"
<re*******@btin ternet.com> wrote:

"Paul Mesken" <us*****@eurone t.nl> wrote

But that doesn't disproof my assertion. Everyone with a tiny bit of
knowledge about how divisions and additions are implemented in
hardware will realize that additions are quicker (implementing an
addition with boolean primitives is about the very first excercise one
does when learning hardware implementation) .
But replacing a division with an addition is a micro-optimisation. Only
rarely will it make any real difference to a program's running time.

This is true. The first optimization should, of course, be the
algorithm itself. However, there might be cases in which micro
optimizations make a big difference. In such a case it is handy to
know that not all arithmetical operations are created equally,
performance wise.

As things are now (in general) :

+ - & | ~ ^ >> << are the quick ones
* is mediocre
/ % are the slow ones

Also, I didn't say that divisions should be replaced by additions
(although, if it can be done in an obvious way, like dividing by a
half, then by all means one should). I said that divisions are slower
than additions.
As for the single counterexample, consider this.

I've got a weighing factor I've got to apply to some variables. If I didn't
have to worry about running time at all I would implement it like this.

double weight = loadweightfacto r();
...
x[i] /= weight;

However let's say that the array x consists of integers, and the weight is
usually 5/16. (ie 3.2)

So let's optimise our code

if( weight == 5/16)
{
/* in loop */

x[i] = ((x[i] << 2) + x[i]) >> 4;
y += strlen(str);
}
Note that I, in another post in this thread, opposed to this kind of
optimization :

"In general, I think that a single operation should not be replaced by
two or more operations which just happen to be faster at the
_present_. It also tends to hurt readability.".

Also, using an "if" as an optimization is hardly an optimization in
pipelined architectures.

For example :

Nowadays' x86s suffer a lot from penalties by mispredicted branches
and the static branch prediction will favor a fall through in your
optimization (and in most cases it actually will _not_ fall through so
static branch prediction will mispredict most of the time).

Even if the branch is predicted correctly most of the time (in some
loop with dynamic branch prediction, for example) there's still some
overhead involved by using if's. And then there is the condition
itself as well, of course, which is an extra operation.

But this single x[i] /= weight; operation can be replaced by another
single operation.

I would use the simple (and still readable) optimization of using a
multiplication instead of a division. So the function
loadweightfacto r() should not return something like 5/16 but 16/5 and
x[i] will not be divided by weight but multiplied by it.

So :

double weight = loadweightfacto r();
x[i] *= weight;

Of course, assuming that this course of action will not cause
performance penalties in the function loadweightfacto r().

As a side note :

x[i] = ((x[i] << 2) + x[i]) >> 4;

is not equivalent to :

x[i] /= 5/16;

But the intention was clear :-)
So we've got rid of our division and replaced it with a addition and two
shifts.

And an if statement, that's the expensive one :-)

As I said : one typically shouldn't replace a single operation by 2 or
more (in your example, it was replaced by 4, probably even more
operations in the generated machinecode). It will hurt readability and
it might not be much of an optimization in the future.

[Paul Mesken]

On Tue, 31 May 2005 23:47:40 +0100, Mark McIntyre
<ma**********@s pamcop.net> wrote:

On Tue, 31 May 2005 01:42:19 +0200, in comp.lang.c , Paul Mesken
<us*****@euron et.nl> wrote:

It's completely logical that a division will always be slower than an
addition, given the algorithms that are used to implement it.
And I say again, you can prove this to be completely true, for all
hardware, including specially optimised hardware? Imagine a system
that does addition on an 8080 and division on a Pentium. Which
operation is faster?

Well, if the 8080 is wildly overclocked (Z80s, which is code
compatible with the 8080, can go as fast as 32 MHz, last time I
checked) and the division is one by zero on a Pentium then the 8080
might still be faster ;-)

Also, remember (I hope) that a Pentium works with a relatively long
pipeline and there will be a distinct difference between throughput
and latency.

My statement doesn't provide for such hypothetical systems. I work
with real systems and I'm confident enough (armed with the knowledge
about how divisions and additions are carried out in hardware) to
state that divisions will not be quicker than additions.

I will grant you that my statements are not universally valid (what
statement is?).
This may sound daft.
Agreed :-)
But its perfectly possible to build hardware with
a FP unit which runs at higher clock speeds than the main cpu (in fact
it probably makes sense, FP operations often take more clock cycles).
So I can easily envisage hardware on which addition and division were
of comparable speeds, or better.
I can envision such hardware as well. But I haven't actually _seen_
such hardware.

You're trying to undermine a solid programming practice by coming up
with counter examples that rely on hypothetical machines. I dare to
say that most programmers don't program for hypothetical machines but
real ones.
Or consider for instance floating point addition, and integer division
by two. Which is faster?
If the integer division is replaced by a single shift to the right
then it might be very close. But a shift is not a division.

Of course, I don't have such proof since I don't know all conceivable
hardware

Indeed. But no need to invoke magic. Today's hardware could do it.

But that doesn't disproof my assertion.

The thing about assertions is, to make them into facts, you have to
prove them to be true.

Take Newton's F = M * A

It's good enough for "daily use" even though QM and relativety theory
have shown it to be not precise enough for the very fast or the very
small.

But that doesn't make it less helpfull, for "daily use".

On most real machines my statement about divisions and additions will
hold, but there might be some exceptions (although I believe most such
exceptions to be hypothetical).
Or you can program as if thats something you should not be worrying
about yet. Do you recall the three laws of optimisation?

There are many such sets but you're probably refering to the one which
starts with "law #1 Don't do it" :-)

[pete]

Paul Mesken wrote:

On Tue, 31 May 2005 23:47:40 +0100, Mark McIntyre
<ma**********@s pamcop.net> wrote:

Which operation is faster?

Well, if the 8080 is wildly overclocked

I think what Mark McIntyre meant, is that you're off topic.
Which code is faster,
isn't part of the definition of the language.

--
pete

[Keith Thompson]

"Malcolm" <re*******@btin ternet.com> writes:

"Jack Klein" <ja*******@spam cop.net> wrote

In C, there is no way to know the size of an object or type without
using the sizeof operator, with one exception.

size_t sizeof(int)
{
int *mem = malloc(1024);
unsigned char *ptr = (unsigned char *) mem;
size_t answer = 0;
memset(mem, 0, 1024);
*mem = ~0;
while(ptr[answer] != 0)
answer++;

return answer;
}

(OK maybe we've got padding bytes. So write to mem[1] and check.)

<quibble>
If your C compiler allows you to name a function "sizeof", send it
back.
</quibble>

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Paul Mesken]

On Wed, 01 Jun 2005 01:46:28 +0200, Paul Mesken <us*****@eurone t.nl>
wrote:

Nowadays' x86s suffer a lot from penalties by mispredicted branches
and the static branch prediction will favor a fall through in your
optimization (and in most cases it actually will _not_ fall through so
static branch prediction will mispredict most of the time).

I must have been half asleep. Of course, your code example _will_ fall
through most of the time. But then again : the code example still
needs an "else" and that will result in possible two branches.

[Mark McIntyre]

On Wed, 01 Jun 2005 02:11:58 +0200, in comp.lang.c , Paul Mesken
<us*****@eurone t.nl> wrote:

On Tue, 31 May 2005 23:47:40 +0100, Mark McIntyre
<ma**********@ spamcop.net> wrote:

But its perfectly possible to build hardware with
a FP unit which runs at higher clock speeds than the main cpu
I can envision such hardware as well. But I haven't actually _seen_
such hardware.

The point is, you're making generalisations which aren't true, and you
don't even bother to caveat them. You're misleading people. I dislike
that.
You're trying to undermine a solid programming practice
but its /not/ solid programming practice! Leave the microoptimisati ons
to the compiler writer, the hardware and the OS, until you actually
know you need to optimise. Crivens, this is practically a Law. In
fact, its three Laws.

Or consider for instance floating point addition, and integer division
by two. Which is faster?

If the integer division is replaced by a single shift to the right
then it might be very close. But a shift is not a division.

If you're allowed to move the goalposts by excluding some classes of
operation which inconveniently (for you) can be optimised in hardware
or software to act as counterexamples , then you can of course prove
your theorem. Where I come from, thats called "cheating". ..
Take Newton's F = M * A
Why? Is it relevant to whether division is invariably slower than
addition?
On most real machines my statement about divisions and additions will
hold,

Again, you make an unfounded assertion which isn't even generally
true. I've given a real-world counterexample but you deny its
existence. Thats ok, I';m sure others will have spotted by now that
you're in a hole.

Or you can program as if thats something you should not be worrying
about yet. Do you recall the three laws of optimisation?

There are many such sets but you're probably refering to the one which
starts with "law #1 Don't do it" :-)

Thats the set. You remember the 2nd and 3rd laws?

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[Mark McIntyre]

On Wed, 01 Jun 2005 00:59:15 GMT, in comp.lang.c , pete
<pf*****@mindsp ring.com> wrote:

Paul Mesken wrote:

On Tue, 31 May 2005 23:47:40 +0100, Mark McIntyre
<ma**********@s pamcop.net> wrote:

> Which operation is faster?

Well, if the 8080 is wildly overclocked

I think what Mark McIntyre meant, is that you're off topic.

Thats one of the things I meant.
Which code is faster, isn't part of the definition of the language.

Absolutely. Asserting something about which code is faster is wildly
offtopic in CLC, even if correct. Which it isn't. :-)


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[Paul Mesken]

On Wed, 01 Jun 2005 20:30:28 +0100, Mark McIntyre
<ma**********@s pamcop.net> wrote:

On Wed, 01 Jun 2005 00:59:15 GMT, in comp.lang.c , pete
<pf*****@minds pring.com> wrote:

Which code is faster, isn't part of the definition of the language.

Absolutely. Asserting something about which code is faster is wildly
offtopic in CLC, even if correct. Which it isn't. :-)

Ooowww, you slipped up there Mark. Now _you_ are asserting things and
need to come up with universal proofs ;-)