473,836 Members | 1,471 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

removing a loop cause it to go at half the speed?

Hi

I was doing a simple test of the speed of a "maths" operation and when I
tested it I found that removing the loop that initialises the data array
for the operation caused the whole program to spend twice the time to
complete. If the loop is included it takes about 7.48 seconds to
complete, but when removed it takes about 11.48 seconds.

Does anybody have a suggestion as to why this is so and whether I can
trust the results of the code as it is below?

/tom
The code was compiled on linux 2.6.3 with gcc 3.3.2 and glibc 2.2.3
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>

int main(int argc, char *argv[])
{
int total = 0;
int count = 65500;
signed int data[count];

/* Initialising array loop */
for(int c=0; c<count; c++) {
data[c]=1+(int) (2000000000.0*r and()/(RAND_MAX+1.0)) ;
}

struct timeval start_time;
struct timeval end_time;

gettimeofday(&s tart_time, NULL);

for(int d=0; d<50000; d++) {
for(int c=0; c<count; c++) {
total += data[c];
}
}
gettimeofday(&e nd_time, NULL);

double t1=(start_time. tv_sec*1000)+(s tart_time.tv_us ec/1000.0);
double t2=(end_time.tv _sec*1000)+(end _time.tv_usec/1000.0);

printf("Elapsed time (ms): %.6lf\n", t2-t1);
printf("Total: %u\n", total);

return(0);
}
Mar 15 '06
102 4575
Mark McIntyre <ma**********@s pamcop.net> writes:
On Sun, 19 Mar 2006 11:45:56 -0000, in comp.lang.c , "Robin Haigh"
<ec*****@leeds. ac.uk> wrote:
Behaviour is only undefined if it's not defined,


Yes. However you've missed off these important words "by the
standard".
Therefore, it's never possible to say that any code _always_ produces
undefined behaviour.


Thats incorrect. Undefined behaviour is, in the context of CLC,
behaviour "for which this international standard imposes no
requirements".

A given platform may indeed define the behaviour. That is however
nongermane to the point. Once you start relying on the behaviour of a
given platform, your code is no longer C.


Robin isn't ignoring those important words; he specifically accounted
for them by invoking implementation-specific definitions of behavior.
For example, the standard doesn't define the behavior on signed
integer overflow, but an implementation is free to do so.

However, I think that Mark is correct as far as the terminology is
concerned. A note on the definition of "undefined behavior" says:

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

(Yes, the note is non-normative, but I accept what it says unless it's
contradicted elsewhere.)

So even if an implementation defines the behavior of signed integer
overflow as the usual 2's-complement wraparound, the behavior is still
undefined. Strictly speaking, it's not even implementation-defined
behavior; "implementa tion-defined behavior" is a subset of
"unspecifie d behavior", and integer overflow doesn't meet that
definition.

--
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.
Mar 19 '06 #81
On 2006-03-19, Robin Haigh <ec*****@leeds. ac.uk> wrote:

"Mark McIntyre" <ma**********@s pamcop.net> wrote in message
news:df******** *************** *********@4ax.c om...
On Sat, 18 Mar 2006 00:18:58 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.or g> wrote:
>I'm not convinced that it can be inferred from the normative text, and
>I tentatively believe that it can't. If you can convince me
>otherwise, I'd be glad to see the evidence. (Of course, if you just
>don't want to take the time to do it, that's fine too.)


We can agree that the value is indeterminate from 6.2.4 (5) and 6.7.8
(10).

We can agree that indeterminate values include traps from 3.17.2(1)

We can agree that undefined behaviour is "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements" from
3.4.3 (1)
I assert that the value of something indeterminate is nonportable,
since what is a trap on one implementation could be valid on another.

I therefore assert that using an indeterminate value is nonportable,
and since the standard places no requirements on this action, its
undefined.

QED?

Behaviour is only undefined if it's not defined, and defined includes
implementation-defined.

A conforming implementation can define any behaviour it likes, within areas
not defined by the standard.


Yes, but only behavior that the standard SAYS is implementation-defined
"counts" for the purpose of "defined includes implementation-defined".
Mar 19 '06 #82
Keith Thompson wrote:
.... snip ...
For example, I believe the following program:

#include <limits.h>
#include <stdio.h>
int main(void)
{
printf("In this implementation, ");
if ( CHAR_BIT * sizeof(unsigned short) == 16 &&
USHRT_MAX == 65535)
{
printf("unsigne d short has no padding bits\n");
}
else {
printf("unsigne d short may or may not have padding bits\n");
}
return 0;
}

wll always print a statement that's true for the implementation
it's running on. (I could have dropped the "may or may not",
and even reported the number of padding bits, if I had taken the
time to test for sizes other than 16 bits.)


As long as ULONG_MAX > USHRT_MAX you can easily compute the count
of active bits in an unsigned short. Comparing that with CHAR_BIT
* sizeof(unsigned short) will expose any padding bits and possible
trap values. In fact you don't even need the ULONG_MAX condition,
since:

for (i = 0, n = USHRT_MAX; n; i++) n = n >> 1;

should give you the bit count in i.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>
Also see <http://www.safalra.com/special/googlegroupsrep ly/>
Mar 19 '06 #83

"Mark McIntyre" <ma**********@s pamcop.net> wrote in message
news:vl******** *************** *********@4ax.c om...
On Sun, 19 Mar 2006 11:45:56 -0000, in comp.lang.c , "Robin Haigh"
<ec*****@leeds. ac.uk> wrote:

Behaviour is only undefined if it's not defined,


Yes. However you've missed off these important words "by the
standard".
Therefore, it's never possible to say that any code _always_ produces
undefined behaviour.


Thats incorrect. Undefined behaviour is, in the context of CLC,
behaviour "for which this international standard imposes no
requirements".

A given platform may indeed define the behaviour. That is however
nongermane to the point. Once you start relying on the behaviour of a
given platform, your code is no longer C.

In the context of the standard, "undefined behaviour" means undefined by the
standard, i.e. the standard imposes no requirements.

But the standard deals with everything piecemeal, one little situation at a
time. Always, the meaning is "if this situation arises, during the
translation or execution of the program, the standard imposes no
requirements". Never in discussing run-time behaviour, e.g. expression
evaluation, does it just say "this is bad code". Never does it say "the
possibility of this bad situation arising in some circumstances makes the
standard inapplicable in all circumstances".

Whether or not a UB situation (where the standard imposes no requirements)
is actually reached during execution is in general conditional, not
determined by the standard, maybe not determinable by the compiler. For
instance, this is strictly conforming

int main (void) {
int i = 0;
if (0)
(void)(i++ + i++);
return 0;
}

notwithstanding that 6.5/2 (undefined behaviour) would apply to the
execution of one of its statements, if that statement occurred in a
different program where it actually did get executed.

Whereas this is non-portable and not strictly conforming:

#include <limits.h>
int main (void) {
int i = 0;
if (CHAR_BIT == 9)
(void)(i++ + i++);
return 0;
}

Because clearly there can be conforming implementations on which a situation
can arise, during execution, where the standard imposes no requirements.

But yet the behaviour is completely defined by the standard (what else?) on
a platform where CHAR_BIT != 9. Having specified CHAR_BIT as 8, say, the
implementation then gets no further say in the matter of how the program
behaves. So is this "not C"?

Or, suppose I put something dodgy in an exit handler. Will the program ever
exit? Who knows? Is the program's behaviour completely determined by the
standard? We might never know. Is it C?

In general, you can't use the run-time behaviour of a program as a
code-validity criterion. In fact you can't discuss behaviour at all without
bringing in suppositions about the implementation. I know there's an
abstract machine, but what's the value of CHAR_BIT in the abstract machine?

This is precisely why they had to invent the term "undefined behaviour"
instead of just saying "invalid code" or "an error". It was never supposed
to be a synonym for "invalid", it was specifically contrived to deal with
the fact that almost all C programs (sources) are capable of exhibiting
undefined behaviour on some platform (on which they aren't intended to run)
and/or under some circumstances (excluded by the spec). To say that the
standard and the newsgroup have nothing to say about such programs is to
make the standard and the newsgroup useless.

--
RSH


Mar 19 '06 #84
On 2006-03-19, Robin Haigh <ec*****@leeds. ac.uk> wrote:

Or, suppose I put something dodgy in an exit handler. Will the program ever
exit?
This is a perfect example - I suspect that determining, in general,
whether a given line of a program is reached is equivalent to the
halting problem. (the halting problem itself being a special case of
_that_, of course.)
Who knows? Is the program's behaviour completely determined by the
standard? We might never know. Is it C?

Mar 19 '06 #85
On Sun, 19 Mar 2006 16:58:24 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.or g> wrote:
Mark McIntyre <ma**********@s pamcop.net> writes:
On Sat, 18 Mar 2006 22:23:47 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.or g> wrote:

[...]
For other integer types, if the size of the type in bits and the
limits of the type specified in <limits.h> are such that the number of
bits is exactly enough to represent all the valid values, we can
conclude that there are no padding bits, and therefore no trap
representati ons.


This may well be true, on any given implementation. However its not
guaranteed by the Standard, and hence still leads to UB.


I think you may have missed the point.


I didn't actually. I understood that *if* all bit patterns could
represent values, then there could be no traps. I merely pointed out
that it wasn't relevant to the undefinedness in question since the
Standard doesn't require that behaviour.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 19 '06 #86
On Sun, 19 Mar 2006 17:07:36 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.or g> wrote:
Mark McIntyre <ma**********@s pamcop.net> writes:
On Sun, 19 Mar 2006 11:45:56 -0000, in comp.lang.c , "Robin Haigh"
<ec*****@leeds. ac.uk> wrote:
Behaviour is only undefined if it's not defined,
Yes. However you've missed off these important words "by the
standard".

Robin isn't ignoring those important words; he specifically accounted
for them by invoking implementation-specific definitions of behavior.


Perhaps, but I interpreted the balance of his remark as implying that
it wasn't undefined if an implementation defined it. This is wrong.
So even if an implementation defines the behavior of signed integer
overflow as the usual 2's-complement wraparound, the behavior is still
undefined. Strictly speaking, it's not even implementation-defined
behavior; "implementa tion-defined behavior" is a subset of
"unspecifie d behavior", and integer overflow doesn't meet that
definition.


The areas of doubt and uncertainty around implementation defined are
even more rigdly defined than those around UB.

Was Douglas a committe member by the way? :-)

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 19 '06 #87
On Sun, 19 Mar 2006 19:15:41 -0000, in comp.lang.c , "Robin Haigh"
<ec*****@leeds. ac.uk> wrote:
In general, you can't use the run-time behaviour of a program as a
code-validity criterion.
Absolutely. I can't see the point in any of this posting, except this
bit.
and/or under some circumstances (excluded by the spec). To say that the
standard and the newsgroup have nothing to say about such programs is to
make the standard and the newsgroup useless.


You're mistaken.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 19 '06 #88

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...
Mark McIntyre <ma**********@s pamcop.net> writes:
On Sun, 19 Mar 2006 11:45:56 -0000, in comp.lang.c , "Robin Haigh"
<ec*****@leeds. ac.uk> wrote:
Behaviour is only undefined if it's not defined,


Yes. However you've missed off these important words "by the
standard".
Therefore, it's never possible to say that any code _always_ produces
undefined behaviour.


Thats incorrect. Undefined behaviour is, in the context of CLC,
behaviour "for which this international standard imposes no
requirements".

A given platform may indeed define the behaviour. That is however
nongermane to the point. Once you start relying on the behaviour of a
given platform, your code is no longer C.


Robin isn't ignoring those important words; he specifically accounted
for them by invoking implementation-specific definitions of behavior.
For example, the standard doesn't define the behavior on signed
integer overflow, but an implementation is free to do so.

However, I think that Mark is correct as far as the terminology is
concerned. A note on the definition of "undefined behavior" says:

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

(Yes, the note is non-normative, but I accept what it says unless it's
contradicted elsewhere.)

So even if an implementation defines the behavior of signed integer
overflow as the usual 2's-complement wraparound, the behavior is still
undefined. Strictly speaking, it's not even implementation-defined
behavior; "implementa tion-defined behavior" is a subset of
"unspecifie d behavior", and integer overflow doesn't meet that
definition.

Bad example, sorry. All the same, I don't see the point of "behaving.. . in
a documented manner..." unless it means "... and things will then continue
normally."

If I write c = a + b and a + b overflows, I'm prepared for alarm bells, but
if the behaviour takes the form of yielding some valid value for a + b, I
would expect that value and not some different value to be assigned to c,
and so on, and I wouldn't expect some expression to be misevaluated 3000
lines later on the grounds that the standard is imposing no requirements.

Otherwise, all extensions become impossible. In practice, an extension
defines some behaviour not defined by the standard and then execution
continues according to the standard.

As I said elsethread, source is polymorphic across implementations , but
behaviour can only be discussed in the context of an implementation. There
is no pure "implementa tion-free" environment. You can of course discuss a
minimal conforming implementation, one that does nothing it doesn't have to.
The standard says what it must do. But that's not all the standard is for,
it also forms a large part of the description of real-life implementations .

--
RSH
Mar 19 '06 #89
Mark McIntyre <ma**********@s pamcop.net> writes:
On Sun, 19 Mar 2006 16:58:24 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.or g> wrote:
Mark McIntyre <ma**********@s pamcop.net> writes:
On Sat, 18 Mar 2006 22:23:47 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.or g> wrote:

[...]
For other integer types, if the size of the type in bits and the
limits of the type specified in <limits.h> are such that the number of
bits is exactly enough to represent all the valid values, we can
conclude that there are no padding bits, and therefore no trap
representat ions.

This may well be true, on any given implementation. However its not
guaranteed by the Standard, and hence still leads to UB.


I think you may have missed the point.


I didn't actually. I understood that *if* all bit patterns could
represent values, then there could be no traps. I merely pointed out
that it wasn't relevant to the undefinedness in question since the
Standard doesn't require that behaviour.


The question, I suppose, is whether it makes sense to talk about
conditional undefined behavior. Is undefined behavior an absolute
attribute, or can a program exhibit undefined behavior on one
implementation but not on another? In my opinion, conditional
undefined behavior is possible.

First, here's a program that *unconditionall y* exhibits undefined
behavior:

#include <limits.h>
#include <stdio.h>
int main(void)
{
int x = INT_MAX;
x ++;
printf("x = %d\n", x);
return 0;
}

Even if an implementation happens to define the behavior of signed
integer overflow, the program still exhibits UB; whatever behavior the
implementation defines is just one particular manifestation of UB.

But consider this program:

#include <stdio.h>
int main(void)
{
int x = 32767;
x ++;
printf("x = %d\n", x);
return 0;
}

On an implementation with INT_MAX == 32767, this program exhibits UB,
just like the previous one. On an implementation with INT_MAX > 32767,
though, there is no undefined behavior. In fact, on such an
implementation, the standard specifically requires the program to
print "x = 32768".

Similarly, this program:

#include <stdio.h>
#include <limits.h>
int main(void)
{
if (INT_MAX > 32767) {
int x = 32767;
x ++;
printf("x = %d\n", x);
}
else {
puts("x = 32768");
}
return 0;
}

never exhibits undefined behavior. Even though the "x ++;"
would exhibit UB if it were executed on an implementation with
INT_MAX == 32767, it never will be, so it's not an issue. (In fact,
I think this program is even strictly conforming, though in a rather
roundabout way.)

Going back to the trap representation issue, a program that accesses
an uninitialized auto unsigned short object exhibits undefined
behavior if it's executed on an implementation where unsigned short
has one or more trap representations . It *doesn't* exhibit UB if it's
executed on an implementation where unsigned short has no trap
representations .

(Or maybe it does; see comp.std.c for discussion of whether accessing
an an unspecified value that's known not to be a trap representation
can still exhibit UB.)

As a practical matter, though, there's little difference between
unconditional and conditional UB. Both are most likely programming
bugs, unless you're depending on non-portable assumptions.

--
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.
Mar 19 '06 #90

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

24
8645
by: Kunal | last post by:
Hello, I need help in removing if ..else conditions inside for loops. I have used the following method but I am not sure whether it has actually helped. Below is an example to illustrate what I have used. Original code : c= 0 ; for (i=0; i<999; i++)
0
10546
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10588
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9371
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7790
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
6978
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5647
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5823
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4448
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4013
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.