Does Casting Slow a Program Down?

[PeterOut]

If I had code like this.

unsigned short usLimit=10
int a[10], i;

for (i=0; i<(int)usLimit ; ++i)
{
a[i]=(int)usLimit;
}

would it run slower than this?

int a[10], i, iLimit=10;

for (i=0; i<iLimit; ++i)
{
a[i]=iLimit;
}

Thanks,
Peter.

[Zara]

On 31 Jan 2007 06:50:47 -0800, "PeterOut" <Ma**********@e xcite.com>
wrote:

>If I had code like this.

unsigned short usLimit=10

<<<<< Missing semicolon

>int a[10], i;

for (i=0; i<(int)usLimit ; ++i)
{
a[i]=(int)usLimit;
}

would it run slower than this?

int a[10], i, iLimit=10;

for (i=0; i<iLimit; ++i)
{
a[i]=iLimit;
}

It depends on the compiler, but the answer should usually be 'No'

If the compiler detectes tha usLimit and iLimit are constants, then it
may detect that (int)usLimit is also constant and it would probably
generate the exact same machine code for both samples.

But this behaviour depends on the optimizations capabilities an
settings of the compiler, and of the code surrounding the snippet you
have shown us.

You may help the compiler declaring either
const unsigned short usLimit=10;
or
const int iLimit=10;
Best regards,

Zara

[Richard Heathfield]

PeterOut said:

If I had code like this.

unsigned short usLimit=10
int a[10], i;

for (i=0; i<(int)usLimit ; ++i)
{
a[i]=(int)usLimit;
}

would it run slower than this?

int a[10], i, iLimit=10;

for (i=0; i<iLimit; ++i)
{
a[i]=iLimit;
}

To find out, code both versions, put them in separate functions, and call
them each a zillion times. Then check the profiler's output.

Repeat on each relevant implementation. (Don't expect A to be faster than B
on implementation Y just because it was faster on implementation X.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Dollin]

PeterOut wrote:

If I had code like this.

unsigned short usLimit=10
int a[10], i;

for (i=0; i<(int)usLimit ; ++i)
{
a[i]=(int)usLimit;
}

would it run slower than this?

int a[10], i, iLimit=10;

for (i=0; i<iLimit; ++i)
{
a[i]=iLimit;
}

It might, but it would have nothing to do with the casts,
since they're both unnecessary -- `usLimit` is
converted from `unsigned short` to `int` regardless.

In any case, the Standard is silent on the issue.

--
Chris "electric hedgehog" Dollin
The "good old days" used to be much better.

[santosh]

PeterOut wrote:

If I had code like this.

unsigned short usLimit=10
int a[10], i;

for (i=0; i<(int)usLimit ; ++i)
{
a[i]=(int)usLimit;
}

would it run slower than this?

int a[10], i, iLimit=10;

for (i=0; i<iLimit; ++i)
{
a[i]=iLimit;
}

Quality of code generation is implementation defined. A good optimiser
might be able to figure out that usLimit is not changed and hence, use
a single, cached value. On some hardware, short and int might be of
the same size and representation. In such cases, the cast never takes
up any object code. But speed of execution is not specified by the
standard and no guarantees are made. An assignent statement that takes
ten days to complete is perfectly legal, as per the standard, as long
as all the side effects are resolved before the next sequence point.

[PeterOut]

On Jan 31, 10:01 am, Zara <[e-mail] amcon.orgwrote:

>
If the compiler detectes tha usLimit and iLimit are constants, then it
may detect that (int)usLimit is also constant and it would probably
generate the exact same machine code for both samples.

But this behaviour depends on the optimizations capabilities an
settings of the compiler, and of the code surrounding the snippet you
have shown us.

You may help the compiler declaring either
const unsigned short usLimit=10;
or
const int iLimit=10;

Thanks very much for your fast reply. I was thinking in general
terms. usLimit/iLimit are given a constant value in the example that
I posted but I was thinking in terms of their being variables that are
determined by input data and/or passed as arguments to a function.
Also, what about casting a (single precision) float to a double or
vice versa? Would that impact the run time or would it depend on the
compiler?

Thanks again,
Peter.

[Christopher Layne]

PeterOut wrote:

Thanks very much for your fast reply. I was thinking in general
terms. usLimit/iLimit are given a constant value in the example that
I posted but I was thinking in terms of their being variables that are
determined by input data and/or passed as arguments to a function.
Also, what about casting a (single precision) float to a double or
vice versa? Would that impact the run time or would it depend on the
compiler?

Thanks again,
Peter.

If you're using gcc, use the -s option and check the assembler output of both
versions. If you're using another compiler - lookup how to produce the
intermediate assembler output (if it has that functionality).

[santosh]

PeterOut wrote:

On Jan 31, 10:01 am, Zara <[e-mail] amcon.orgwrote:

If the compiler detectes tha usLimit and iLimit are constants, then it
may detect that (int)usLimit is also constant and it would probably
generate the exact same machine code for both samples.

But this behaviour depends on the optimizations capabilities an
settings of the compiler, and of the code surrounding the snippet you
have shown us.

You may help the compiler declaring either
const unsigned short usLimit=10;
or
const int iLimit=10;

Thanks very much for your fast reply. I was thinking in general
terms. usLimit/iLimit are given a constant value in the example that
I posted but I was thinking in terms of their being variables that are
determined by input data and/or passed as arguments to a function.
Also, what about casting a (single precision) float to a double or
vice versa? Would that impact the run time or would it depend on the
compiler?

Casting is an operation in C. It may or may not translate to actual
hardware instructions, depending on the size and bit representation of
the various types. Optimisers can also effect the final object code.
So, the only way to find out if casting is incurring runtime penalty,
on a particular implementation, compiled under a particular
optimisation level, is to test and compare the results. On most modern
systems and compilers, it unlikely to make a difference.

It more important to ask yourself if the cast is really needed, rather
than it's runtime performance.

[Serve Laurijssen]

"santosh" <sa*********@gm ail.comwrote in message
news:11******** *************@v 33g2000cwv.goog legroups.com...

Quality of code generation is implementation defined. A good optimiser
might be able to figure out that usLimit is not changed and hence, use
a single, cached value. On some hardware, short and int might be of
the same size and representation. In such cases, the cast never takes
up any object code. But speed of execution is not specified by the
standard and no guarantees are made. An assignent statement that takes
ten days to complete is perfectly legal, as per the standard, as long
as all the side effects are resolved before the next sequence point.

I find the general question which (I think) hes asking interesting.

Can integer casts generate extra instructions?
How about floating point casts?

[Ben Pfaff]

"Serve Laurijssen" <se*@n.tkwrites :

Can integer casts generate extra instructions?

Yes; for example, to zero a register or to move data from a
register used for one size of data to a register used for a
different size of data.

How about floating point casts?

Yes.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt