I started programming with c. Lot of projects are being done in C++. We
have to move in THE C++.
I read around 3 - 4 books (including Faqs, stroustrup) on c++. What i
found in most of the book is that they criticize c language and c
programmer. And they silently run away from good feature of C.
They have sentence like , "you have to unlearn c to learn C++".
is it the end of C era ?
Stroustrup and writers of Faqs are gurus of technologies. These people
are commenting on C language.
should we believe them?
somewhere it is demoralizing for c programmer.
I just wanted to know what other people thinks on this .
Dec 26 '06
167  5426 
Richard Heathfield wrote:
jacob navia said:
<snip>
The main advantages of my own string library are:
1) it caches string lengths, thus allowing fast len, cat and cpy operations;
2) it resizes buffers when necessary, without troubling the user, and keeps
extra space around so that it doesn't need to go to the well every time;
3) it contains several useful string functions not provided by the standard
library;
4) it is written in ISO C and doesn't depend on any particular compiler
features.
The first of these has genuine and significant time complexity reduction
benefits. The second takes a load off the programmer's shoulders. The third
is basically a sack of nice toys. And the fourth is essential if the code
is to remain viable in the long term.
Number two doesn't imply non-reentrancy, does it?
Richard Heathfield a écrit :
>> ptr=start=strchr(sentence,'$');
-------
(jn)
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
(heathfield)
Whilst that *is* an improvement, it's a micro-optimisation, since each
character in turn is being examined anyway.
Surely not.
memchr can be implemented with a hardware memory scan since processors
like the x86 have a hardware byte scan feature. This allows for
scanning for a single byte, but not for a byte OR zero byte.
This can make quite a difference.
[snip]
>
The main advantages of my own string library are:
1) it caches string lengths, thus allowing fast len, cat and cpy operations;
What a surprise. You have written a counted string
library. And after all this polemic ... you need it too.
Well lcc-win32's library caches string lengths too. :-)
2) it resizes buffers when necessary, without troubling the user, and keeps
extra space around so that it doesn't need to go to the well every time;
The same for lcc-win32's library
3) it contains several useful string functions not provided by the standard
library;
The same: file to string, string to file, find first/last.
Lcc-win32's is roughly patterned after the C++ one.
4) it is written in ISO C and doesn't depend on any particular compiler
features.
Well, the library uses operator overloading, wht allows you
to write:
String s = "abc";
s[12] = 'h';
etc. It has the same feeling as the old C library.
The first of these has genuine and significant time complexity reduction
benefits. The second takes a load off the programmer's shoulders. The third
is basically a sack of nice toys.
I can say the same of lcc-wiN32's library
And the fourth is essential if the code
is to remain viable in the long term.
The purpose of lcc-win32's library is to demonstrate that a single
modification to the compiler allows to build a general container
library. The same feature has been used to build a resizable
strings/vector package, a list package, a bitstring
package and I am doing the hash table package.
It is interesting to note that after all deprecating of
counted strings, heathfield has written one of his own!!!
jacob navia <ja***@jacob.remcomp.frwrites:
Dave Vandervies a écrit :
>If knowing the length of strings is that important, can you explain
how counted strings would have made this code easier to write, clearer,
or less error-prone?
/* -8<--Code starts here--8<- */
[snip]
> ptr=start=strchr(sentence,'$');
-------
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
---------
strchr() has to check for '\0' on each iteration of the loop. A
counted strings implementation has to check whether the index exceeds
the length on each iteration of the loop. My guess is that strchr()
is going to be slightly faster -- but that's only a guess, and it's
likely to vary on different implementations.
[...]
> while(*ptr && *ptr!='*' && *ptr!='\r')
{
--------
Here the string library provides
Strfind_firstof(String, setOfChars);
--------
I presume you're referring to *your* string library, not really to
"the" string library. But I'm not convinced that a call to
Strfind_firstof is significantly better, in any sense, than the
existing code.
[...]
> ptr+=strcspn(ptr,",*\r");
---------
The counted strcspn version needs NOT to test for a terminating zero
but just for the pattern being searched
---------
But again, it needs to check whether it's reached the end of the
string. Whether that check is done by comparing a character (that
we're already looking at anyway) against '\0', or by comparing an
index (that doesn't otherwise need to be computed) to a stored bound.
[...]
As you can see, the main advantages are the obviating for the tests
for the zero byte.
I don't believe you've demonstrated that this is an advantage in this
case.
--
Keith Thompson (The_Other_Keith) 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.
Keith Thompson a écrit :
jacob navia <ja***@jacob.remcomp.frwrites:
>>Dave Vandervies a écrit :
>>>If knowing the length of strings is that important, can you explain
how counted strings would have made this code easier to write, clearer,
or less error-prone?
/* -8<--Code starts here--8<- */
[snip]
>> ptr=start=strchr(sentence,'$');
-------
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
---------
strchr() has to check for '\0' on each iteration of the loop. A
counted strings implementation has to check whether the index exceeds
the length on each iteration of the loop. My guess is that strchr()
is going to be slightly faster -- but that's only a guess, and it's
likely to vary on different implementations.
No. The big difference is that byte scan is hardwired in some
processors, what makes it considerably FASTER than
searching for a zero byte OR the searched character
santosh said:
Richard Heathfield wrote:
>jacob navia said:
<snip>
>The main advantages of my own string library are:
1) it caches string lengths, thus allowing fast len, cat and cpy
operations; 2) it resizes buffers when necessary, without troubling the
user, and keeps extra space around so that it doesn't need to go to the
well every time; 3) it contains several useful string functions not
provided by the standard library;
4) it is written in ISO C and doesn't depend on any particular compiler
features.
The first of these has genuine and significant time complexity reduction
benefits. The second takes a load off the programmer's shoulders. The
third is basically a sack of nice toys. And the fourth is essential if
the code is to remain viable in the long term.
Number two doesn't imply non-reentrancy, does it?
No, not at all. The string information is wrapped up in an aggregate object
to which the user-programmer has a pointer.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
jacob navia said:
Richard Heathfield a écrit :
>>> ptr=start=strchr(sentence,'$');
-------
>(jn)
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
(heathfield)
Whilst that *is* an improvement, it's a micro-optimisation, since each
character in turn is being examined anyway.
Surely not.
memchr can be implemented with a hardware memory scan since processors
like the x86 have a hardware byte scan feature. This allows for
scanning for a single byte, but not for a byte OR zero byte.
This can make quite a difference.
It's likely to be a tiny difference.
[snip]
>>
The main advantages of my own string library are:
1) it caches string lengths, thus allowing fast len, cat and cpy
operations;
What a surprise. You have written a counted string
library.
Well, I don't call it a "counted string" library, but yes, I've written one.
And after all this polemic ...
What polemic? I have said all along that there's nothing wrong with using
third-party string libraries - feel free to check the history if you don't
believe me.
you need it too.
I find it convenient, sometimes. And sometimes I don't. It's good to have
the choice.
<snip>
>4) it is written in ISO C and doesn't depend on any particular compiler
features.
Well, the library uses operator overloading, wht allows you
to write:
String s = "abc";
s[12] = 'h';
....which is non-standard syntax (unless String is just a typedef for an
array of a given, hard-coded size, which would defeat the point). It's a
fine idea for people who want to use it, but it ain't C, and it should be
discussed in a newsgroup where it's topical, e.g. your own.
etc. It has the same feeling as the old C library.
But if I use your syntax, my program *won't compile*.
<snip>
The purpose of lcc-win32's library is to demonstrate that a single
modification to the compiler allows to build a general container
library.
This can be done without modifying the compiler, too.
It is interesting to note that after all deprecating of
counted strings, heathfield has written one of his own!!!
I haven't deprecated "counted strings" at all. What makes you think I have
done so?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
jacob navia said:
Keith Thompson a écrit :
<snip>
>strchr() has to check for '\0' on each iteration of the loop. A
counted strings implementation has to check whether the index exceeds
the length on each iteration of the loop. My guess is that strchr()
is going to be slightly faster -- but that's only a guess, and it's
likely to vary on different implementations.
No. The big difference is that byte scan is hardwired in some
processors, what makes it considerably FASTER than
searching for a zero byte OR the searched character
What is true for some processors is not true for all, and what is faster on
Machine A may turn out to be slower on Machine B. And even if that turns
out not to be the case, it's still microoptimisation. If this is truly the
program's bottleneck, the programmer is skilled indeed!
In such cases, write the clearest code you can.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>Dave Vandervies a écrit :
>>
If knowing the length of strings is that important, can you explain
how counted strings would have made this code easier to write, clearer,
or less error-prone?
(Most of code snipped.)
> ptr=start=strchr(sentence,'$');
-------
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
The main use of this code will be processing data that has already come
through a serial port at 4800 bits per second. (It's part of a program
I'm playing with to display GPS data in a useful manner.) Can the amount
of time this micro-optimization would save on a modern system be expressed
as a percentage of the time taken to send the string through the serial
link with fewer than five zeros to the right of the decimal point?
In the common case (correct and well-formed input), the '$' will come
through the input port immediately following the end of the last input
sentence and therefore be the first character in the input buffer.
Can the amount of time saved in this case be expressed as a strictly
positive value?
One of the entries on my would-be-nice-to-do-sometime list is to port
this program (once I'm finished with it, which might take a while)
to a handheld device. Can the probability that such a device would
both have support for this micro-optimization and be slow enough that
it would help be expressed as a strictly positive value?
> while(*ptr && *ptr!='*' && *ptr!='\r')
{
--------
Here the string library provides
Strfind_firstof(String, setOfChars);
--------
> if(*ptr==',')
{
needed++;
}
cksum^=*ptr;
ptr++;
}
If a simple find-first-of was what I wanted, I'd've used strcspn or
strpbrk, which have the advantage of being supported on any hosted C
implementation. Does your Strfind_firstof also calculate the xor of
the values of the characters it skips over?
> /*Now we can check whether the input is well-formed...*/
if(*ptr=='0')
-------
Are you sure you are testing for the character zero ('0') and
not for the terminating zero ( 0 ) ?????????
That should've been '\0'. Good catch.
> ptr+=strcspn(ptr,",*\r");
---------
The counted strcspn version needs NOT to test for a terminating zero
but just for the pattern being searched
Is that actually an improvement over just including '\0' in the set of
characters it searches for? It seems odd that doing the same check for
one more character would be slower than adding a different test.
>But I may disappoint you since in the implementation of lcc-win32 the
strings are probably much slower than they ought to be since the
main thrust of the package is to provide more security and not speed.
I will start a faster version soon.
As you can see, the main advantages are the obviating for the tests
for the zero byte.
So basically you're saying that if I were to use your counted string
library I could get the benefits of some microoptimizations that avoided
looking for a terminating '\0', at the expense of using a library that's
much slower than it ought to be because speed wasn't a main design goal?
Somehow that seems kind of incongruous.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
I later told my sister (23 years old) that I had got a personal reply from
Dennis Ritchie. She said she didn't believe it. What is funny is that my sister
... probably doesn't even know who Dennis Ritchie is. --Joona Palaste in CLC
Dave Vandervies a écrit :
>> ptr=start=strchr(sentence,'$');
-------
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
The main use of this code will be processing data that has already come
through a serial port at 4800 bits per second. (It's part of a program
I'm playing with to display GPS data in a useful manner.) Can the amount
of time this micro-optimization would save on a modern system be expressed
as a percentage of the time taken to send the string through the serial
link with fewer than five zeros to the right of the decimal point?
If you are connecting a modern PC at 4800 bauds...
the main bottleneck is anyway outsiode string handling.
You change the rules after the fact, excuse me.
You asked:
< quote >
If knowing the length of strings is that important, can you explain
how counted strings would have made this code easier to write, clearer,
or less error-prone?
< end quote>
In the common case (correct and well-formed input), the '$' will come
through the input port immediately following the end of the last input
sentence and therefore be the first character in the input buffer.
Can the amount of time saved in this case be expressed as a strictly
positive value?
Again, you change the rules. You did NOT say that in the first
post!
Now it is obvious that you should do:
if (*sentence != '$') {
ptr = strchr(sentence,'$');
}
else ptr = sentence;
>
One of the entries on my would-be-nice-to-do-sometime list is to port
this program (once I'm finished with it, which might take a while)
to a handheld device. Can the probability that such a device would
both have support for this micro-optimization and be slow enough that
it would help be expressed as a strictly positive value?
If the processor belongs to the x86 family definitely yes.
>
>> /*Now we can check whether the input is well-formed...*/
if(*ptr=='0')
-------
Are you sure you are testing for the character zero ('0') and
not for the terminating zero ( 0 ) ?????????
That should've been '\0'. Good catch.
This is a common problem with zero terminated strings :-)
I have done this error several times too.
>
>>But I may disappoint you since in the implementation of lcc-win32 the
strings are probably much slower than they ought to be since the
main thrust of the package is to provide more security and not speed.
I will start a faster version soon.
As you can see, the main advantages are the obviating for the tests
for the zero byte.
So basically you're saying that if I were to use your counted string
library I could get the benefits of some microoptimizations that avoided
looking for a terminating '\0', at the expense of using a library that's
much slower than it ought to be because speed wasn't a main design goal?
Somehow that seems kind of incongruous.
Well, counted strings are more secure by design. It is not
much their intrinsic efficiency but the fact that they allow for
programs that do not start unbounded memory scans...
No, I haven't optimized it yet. And I am not trying to sell you
something. The main thrust in my work was to demonstrate the far
reaching implications of a small change to the language itself to
encourage other people and implementers to do the same.
In article <45**********@jacob.remcomp.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>Dave Vandervies a écrit :
>>>In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
The main use of this code will be processing data that has already come
through a serial port at 4800 bits per second. (It's part of a program
I'm playing with to display GPS data in a useful manner.) Can the amount
of time this micro-optimization would save on a modern system be expressed
as a percentage of the time taken to send the string through the serial
link with fewer than five zeros to the right of the decimal point?
If you are connecting a modern PC at 4800 bauds...
the main bottleneck is anyway outsiode string handling.
You change the rules after the fact, excuse me.
You asked:
< quote >
If knowing the length of strings is that important, can you explain
how counted strings would have made this code easier to write, clearer,
or less error-prone?
< end quote>
I don't see "faster" in my list. Is code that calls a library routine
that does a fixed-length memory scan easier to write, clearer, or less
error-prone than code that calls a library routine that stops at the
'\0' that terminates a string?
If you're going to complain about changing the rules after the fact,
a better place to start complaining might be with the comment about
replacing a terminating-character check with a size-bounded memory scan
(both wrapped inside a library routine) for, as far as I can tell,
no reason except that some processors might be able to run it a little
bit faster.
>In the common case (correct and well-formed input), the '$' will come
through the input port immediately following the end of the last input
sentence and therefore be the first character in the input buffer.
Can the amount of time saved in this case be expressed as a strictly
positive value?
Again, you change the rules. You did NOT say that in the first
post!
Now it is obvious that you should do:
if (*sentence != '$') {
ptr = strchr(sentence,'$');
}
else ptr = sentence;
Why should I do that? It's neither easier to write, nor clearer,
nor less error-prone than letting strchr check the first character
for me. It's also quite unlikely to save a noticeable (or probably even
measurable) amount of time.
>One of the entries on my would-be-nice-to-do-sometime list is to port
this program (once I'm finished with it, which might take a while)
to a handheld device. Can the probability that such a device would
both have support for this micro-optimization and be slow enough that
it would help be expressed as a strictly positive value?
If the processor belongs to the x86 family definitely yes.
How many handheld devices that I would be able to get my hands on at
some point in the not-too-distant future are likely to be built around
an x86 processor that's slow enough that it might have trouble keeping
up with a 4800bps input stream?
I don't pay a whole lot of attention to what goes in embedded systems,
but it seems to me that the only way it would be short on CPU cycles
for this kind of operation is if it's been optimized for insanely low
cost and power consumption, and I'm not sure the x86 family is a major
player in that market.
>So basically you're saying that if I were to use your counted string
library I could get the benefits of some microoptimizations that avoided
looking for a terminating '\0', at the expense of using a library that's
much slower than it ought to be because speed wasn't a main design goal?
Somehow that seems kind of incongruous.
Well, counted strings are more secure by design. It is not
much their intrinsic efficiency but the fact that they allow for
programs that do not start unbounded memory scans...
Secure by design, or just with a different set of potential
security-related bugs to watch out for? (Do your counted strings keep
track of the available space and make sure it's not exceeded? Does a
set of bytes with a random length field make a valid counted string?
Can a programmer write safe code without knowledge about how to use them
and a fanatical (or at least not-nonexistent) dedication to correctness?
Why should the answers be any different for code that uses null-terminated
strings?)
I've never written string code that starts unbounded memory scans;
they're just bounded by a condition other than "have I gotten to N
characters past the beginning?". If my sets of bytes don't have a '\0'
at the end, I don't call them strings and don't treat them as strings -
it's that easy.
(It's worth noting that even the end-of-string check bug in the code I
posted wouldn't've resulted in walking off the end of the string; giving
it carefully crafted bad data (rather than putting it downstream of an
input handler that only passed on complete lines) would have caused the
assert farther down to fail (immediately giving a clue that Something
Isn't Right, after which a brief examination of the execution on that
data would have turned up the error), or with NDEBUG defined would have
resulted in a deterministic failure to correctly report some types of
badly-formatted data - not exactly a terribly security flaw.)
>No, I haven't optimized it yet. And I am not trying to sell you
something. The main thrust in my work was to demonstrate the far
reaching implications of a small change to the language itself to
encourage other people and implementers to do the same.
It seems to me that you've yet to convince anybody that these "far
reaching implications" are all that far-reaching, or for that matter
relevant at all.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Attempts to replace it by blunter tools weren't particularly successful:
instead of writing fast and incorrect applications, incompetents wrote
slower and incorrect applications. --Dan Pop in comp.arch
Dave Vandervies a écrit :
Secure by design, or just with a different set of potential
security-related bugs to watch out for? (Do your counted strings keep
track of the available space and make sure it's not exceeded?
Yes
Does a
set of bytes with a random length field make a valid counted string?
No. I test that at the end of the length field there is a ZERO byte,
i.e. the length must point to a zero byte. Maybe I will change that
for a longer signature.
Can a programmer write safe code without knowledge about how to use them
and a fanatical (or at least not-nonexistent) dedication to correctness?
It is designed to port the code of existing string library code without
many modifications, That's the whole point.
Instead of strcat Strcat, etc. That's why operator overloading comes
handy since it allows to replace
char *a = "A string";
by
String a = "A string";
WITHOUT having to write:
String a = newString("A string"); // or whatever
Why should the answers be any different for code that uses null-terminated
strings?)
They are
jacob navia said:
<snip>
Instead of strcat Strcat, etc. That's why operator overloading comes
handy since it allows to replace
char *a = "A string";
by
String a = "A string";
Not in C, it doesn't.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
jacob navia <ja***@jacob.remcomp.frwrites:
Keith Thompson a écrit :
>jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>>>-------
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
---------
strchr() has to check for '\0' on each iteration of the loop. A
counted strings implementation has to check whether the index exceeds
the length on each iteration of the loop. My guess is that strchr()
is going to be slightly faster -- but that's only a guess, and it's
likely to vary on different implementations.
No. The big difference is that byte scan is hardwired in some
processors, what makes it considerably FASTER than
searching for a zero byte OR the searched character
Have you measured it? More importantly, have you measured it on
multiple platforms? Do you have any actual performance numbers to
share with us? Or are you just guessing?
--
Keith Thompson (The_Other_Keith) 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.
In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>No. The big difference is that byte scan is hardwired in some
processors, what makes it considerably FASTER than
searching for a zero byte OR the searched character
I would have expected that on modern machines such things were limited
by memory access (even for data in the cache).
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Richard Heathfield a écrit :
jacob navia said:
<snip>
>>Instead of strcat Strcat, etc. That's why operator overloading comes
handy since it allows to replace
char *a = "A string";
by
String a = "A string";
Not in C, it doesn't.
BRAVO heathfield!
Bravo!
What an answer. I am really impressed by it.
So many arguments!
I am sure that is the best answer your
mind can give :-)
Keith Thompson a écrit :
jacob navia <ja***@jacob.remcomp.frwrites:
>>Keith Thompson a écrit :
>>>jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>>>>-------
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
---------
strchr() has to check for '\0' on each iteration of the loop. A
counted strings implementation has to check whether the index exceeds
the length on each iteration of the loop. My guess is that strchr()
is going to be slightly faster -- but that's only a guess, and it's
likely to vary on different implementations.
No. The big difference is that byte scan is hardwired in some
processors, what makes it considerably FASTER than
searching for a zero byte OR the searched character
Have you measured it? More importantly, have you measured it on
multiple platforms? Do you have any actual performance numbers to
share with us? Or are you just guessing?
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void)
{
char s[4096];
int i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
}
Time for strchr=84
Time for memchr=41
Machine: Amd64 2GHZ
Compiler: lcc-win32, no optimizations
With 64 bits MSVC the difference is:
Time for strchr=63
Time for memchr=62
In the same machine! This is because the memchr routine is probably
not optimized at all. When I stop the program under the debugger I see
routines written in C. In the 32 bit versions they were written in
assembler...
Measurements depend on the CPU of course but as I said before
this is for x86 Cpus or similar. They are quite popular
though.
In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>Keith Thompson a écrit :
>Have you measured it? More importantly, have you measured it on
multiple platforms? Do you have any actual performance numbers to
share with us? Or are you just guessing?
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void)
{
char s[4096];
int i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
}
Time for strchr=84
Time for memchr=41
Machine: Amd64 2GHZ
Compiler: lcc-win32, no optimizations
With 64 bits MSVC the difference is:
Time for strchr=63
Time for memchr=62
Are you sure of your numbers? Here's what I got:
--------
dave@buttons:~/clc (0) $ cat jn_memchr-strchr-compare.c
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void)
{
char s[4096];
int i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
}
dave@buttons:~/clc (0) $ gcc -W -Wall -ansi -pedantic jn_memchr-strchr-compare.c
jn_memchr-strchr-compare.c: In function `main':
jn_memchr-strchr-compare.c:11: warning: comparison between signed and unsigned
jn_memchr-strchr-compare.c:20: warning: int format, time_t arg (arg 2)
jn_memchr-strchr-compare.c:26: warning: int format, time_t arg (arg 2)
jn_memchr-strchr-compare.c:27: warning: control reaches end of non-void function
dave@buttons:~/clc (0) $ cp jn_memchr-strchr-compare.c jn_memchr-strchr-compare-fixed.c
dave@buttons:~/clc (0) $ vi jn_memchr-strchr-compare-fixed.c
dave@buttons:~/clc (0) $ cat jn_memchr-strchr-compare-fixed.c
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void)
{
char s[4096];
size_t i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL);
printf("Time for strchr=%f\n",difftime(tStrchr,t));
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL);
printf("Time for memchr=%f\n",difftime(tMemchr,t));
return 0;
}
dave@buttons:~/clc (0) $ gcc -W -Wall -ansi -pedantic jn_memchr-strchr-compare-fixed.c
dave@buttons:~/clc (0) $ ./a.out
Time for strchr=0.000000
Time for memchr=0.000000
dave@buttons:~/clc (0) $ gcc --version
gcc (GCC) 3.3.6
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
dave@buttons:~/clc (0) $ uname -a
Linux buttons 2.6.15.3 #12 Sun Nov 26 16:55:30 EST 2006 i686 unknown unknown GNU/Linux
dave@buttons:~/clc (0) $ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.73GHz
stepping : 8
cpu MHz : 800.219
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips : 1601.62
dave@buttons:~/clc (0) $
--------
So whatever microoptimization you've been doing deep inside memchr,
gcc and libc are still smart enough to do it Rather Faster even without
being asked for optimization.
dave
(completely ignoring the question of what proportion of the running time
a typical program spends inside strchr)
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Isn't it amazing what those slobs at Bell Labs managed to do? ... Imagine
what effect they would have had on programming today if they'd been competent.
--P.J. Plaugher in comp.lang.c
jacob navia <ja***@jacob.remcomp.frwrites:
Richard Heathfield a écrit :
>jacob navia said:
<snip>
>>>Instead of strcat Strcat, etc. That's why operator overloading comes
handy since it allows to replace
char *a = "A string";
by
String a = "A string";
Not in C, it doesn't.
BRAVO heathfield!
Bravo!
What an answer. I am really impressed by it.
So many arguments!
I am sure that is the best answer your
mind can give :-)
C does not support operator overloading. Any features you've
implemented that require operator overloading are therefore off-topic
in this newsgroup, and you should discuss them somewhere else. Any
such features that are implemented only in your own lcc-win32 are
useless (and not particularly interesting) to those of us who need to
use other compilers.
Do you understand that? Or are you going to repeat your standard line
that most of us are opposed to progress?
What better argument is needed?
--
Keith Thompson (The_Other_Keith) 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.
Dave Vandervies a écrit :
In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>>Keith Thompson a écrit :
>>>Have you measured it? More importantly, have you measured it on
multiple platforms? Do you have any actual performance numbers to
share with us? Or are you just guessing?
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void)
{
char s[4096];
int i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
}
Time for strchr=84
Time for memchr=41
Machine: Amd64 2GHZ
Compiler: lcc-win32, no optimizations
With 64 bits MSVC the difference is:
Time for strchr=63
Time for memchr=62
Are you sure of your numbers? Here's what I got:
--------
dave@buttons:~/clc (0) $ cat jn_memchr-strchr-compare.c
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void)
{
char s[4096];
int i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
}
dave@buttons:~/clc (0) $ gcc -W -Wall -ansi -pedantic jn_memchr-strchr-compare.c
jn_memchr-strchr-compare.c: In function `main':
jn_memchr-strchr-compare.c:11: warning: comparison between signed and unsigned
jn_memchr-strchr-compare.c:20: warning: int format, time_t arg (arg 2)
jn_memchr-strchr-compare.c:26: warning: int format, time_t arg (arg 2)
jn_memchr-strchr-compare.c:27: warning: control reaches end of non-void function
dave@buttons:~/clc (0) $ cp jn_memchr-strchr-compare.c jn_memchr-strchr-compare-fixed.c
dave@buttons:~/clc (0) $ vi jn_memchr-strchr-compare-fixed.c
dave@buttons:~/clc (0) $ cat jn_memchr-strchr-compare-fixed.c
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void)
{
char s[4096];
size_t i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL);
printf("Time for strchr=%f\n",difftime(tStrchr,t));
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL);
printf("Time for memchr=%f\n",difftime(tMemchr,t));
return 0;
}
dave@buttons:~/clc (0) $ gcc -W -Wall -ansi -pedantic jn_memchr-strchr-compare-fixed.c
dave@buttons:~/clc (0) $ ./a.out
Time for strchr=0.000000
Time for memchr=0.000000
dave@buttons:~/clc (0) $ gcc --version
gcc (GCC) 3.3.6
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
dave@buttons:~/clc (0) $ uname -a
Linux buttons 2.6.15.3 #12 Sun Nov 26 16:55:30 EST 2006 i686 unknown unknown GNU/Linux
dave@buttons:~/clc (0) $ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.73GHz
stepping : 8
cpu MHz : 800.219
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips : 1601.62
dave@buttons:~/clc (0) $
--------
So whatever microoptimization you've been doing deep inside memchr,
gcc and libc are still smart enough to do it Rather Faster even without
being asked for optimization.
dave
(completely ignoring the question of what proportion of the running time
a typical program spends inside strchr)
GREAT DAVE!!!
1) You are a genius. You can even correct warnings that you yourself
provoked! Impressing.
2) I explicitely disabled optimizations. Apparently you don't. Then,
you got waht you want. ASTOUNDING.
1) thompson asks me if I have data for any difference between strchr and
memchr.
2) I take the effort to do it. I provide the data.
3) You start by correcting pedantic warnings. Sure being a pedant like
your mentors you stop there.
NICE.
Stay there
jacob navia said:
<snip>
GREAT DAVE!!!
1) You are a genius.
Well, he's pretty clever.
Sarcasm might work for Dan Pop, but it doesn't work for Bozo the Clown, and
it doesn't work for you.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On Sun, 31 Dec 2006 08:11:08 +0100, jacob navia wrote:
>cpu MHz : 800.219
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
what is f00f_bug? it seems my pentium pc has it
>coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips : 1601.62
dave@buttons:~/clc (0) $
--------
av a écrit :
On Sun, 31 Dec 2006 08:11:08 +0100, jacob navia wrote:
>>>cpu MHz : 800.219
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
what is f00f_bug? it seems my pentium pc has it
>>>coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2
bogomips : 1601.62
dave@buttons:~/clc (0) $
--------
http://www.x86.org/errata/dec97/f00fbug.htm
In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>GREAT DAVE!!!
1) You are a genius.
No, I'm just somebody who cares about correctness and knows how to drive
a compiler[1].
You can even correct warnings that you yourself
provoked! Impressing.
I corrected warnings that the compiler gave me when I asked it to warn
me about departures from correct C and constructs that were likely to
cause trouble; this is not impressive or even noteworthy. The habit of
cleaning up these problems (or, better, writing code that doesn't have
them in the first place) should be part of every programmer's toolkit.
>2) I explicitely disabled optimizations. Apparently you don't. Then,
you got waht you want. ASTOUNDING.
The command I used to compile it was:
>dave@buttons:~/clc (0) $ gcc -W -Wall -ansi -pedantic jn_memchr-strchr-compare-fixed.c
I don't see any optimization in there. If you do, please tell me where
it is so I can take it out and try again.
>1) thompson asks me if I have data for any difference between strchr and
memchr.
2) I take the effort to do it. I provide the data.
3) You start by correcting pedantic warnings. Sure being a pedant like
your mentors you stop there.
I started by making sure I was working with a correct C program.
If you consider this inappropriate, you're posting to the wrong newsgroup.
dave
[1] The obvious comment about frames of reference is Left As An Exercise
For The Reader.
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Acme Klein Bottles are made on a planet rich in silicon dioxide -- we never
clearcut rainforests, stripmine Kentucky towns, or smash oil tankers into
arctic shores. -http://www.kleinbottle.com/why_acme.htm
Dave Vandervies a écrit :
[snip]
I started by making sure I was working with a correct C program.
If you consider this inappropriate, you're posting to the wrong newsgroup.
dave
[1] The obvious comment about frames of reference is Left As An Exercise
For The Reader.
root@ubuntu:/tmp# gcc tmemchr.c
root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
root@ubuntu:/tmp# uname -a
Linux ubuntu 2.6.12-10-386 #1 Fri Sep 15 16:31:49 UTC 2006 i686 GNU/Linux
root@ubuntu:/tmp# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Sempron(tm) 2500+
stepping : 1
cpu MHz : 1756.400
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 3489.79
How I did that?
This is Left As An Exercise For The Reader.
In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**********************@news.orange.fr...
Instead of strcat Strcat, etc. That's why operator overloading comes
handy since it allows ...
C does not have operator (or any other type of) overloading. You appear
to have, yet again, gotten lost on your way to comp.lang.c++.
<OTC++ even has a standard "string" object, which does all of the nice
things you're advocating here, and is typically implemented with counted
strings. </OT>
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com
Stephen Sprunk a écrit :
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**********************@news.orange.fr...
>Instead of strcat Strcat, etc. That's why operator overloading comes
handy since it allows ...
C does not have operator (or any other type of) overloading. You appear
to have, yet again, gotten lost on your way to comp.lang.c++.
<OTC++ even has a standard "string" object, which does all of the nice
things you're advocating here, and is typically implemented with counted
strings. </OT>
S
I have implemented operator overloading in the lcc-win32
coimpiler system. I think it is an improvement to C, without
incurring with all the associated costs of C++.
jacob navia <ja***@jacob.remcomp.frwrites:
Dave Vandervies a écrit :
[snip]
>I started by making sure I was working with a correct C program.
If you consider this inappropriate, you're posting to the wrong newsgroup.
dave
[1] The obvious comment about frames of reference is Left As An
Exercise
For The Reader.
root@ubuntu:/tmp# gcc tmemchr.c
By default, gcc doesn't bother to complain about a lot of things that
it probably should. Try compiling with "-ansi -pedantic -Wall -W".
root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
[snip]
In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux
On an x86 platform. I asked whether you had tested it on multiple
platforms. Optimizations that work only on x86 systems are only
slightly interesting.
--
Keith Thompson (The_Other_Keith) 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.
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
I have implemented operator overloading in the lcc-win32
coimpiler system. I think it is an improvement to C, without
incurring with all the associated costs of C++.
But it isn't C. Do you understand that?
--
Keith Thompson (The_Other_Keith) 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.
In article <45***********************@news.sunsite.dk>
João Jerónimo <j_*******@yahoo.com.brwrote:
>Ok, but apart from code that is explicitly non-reentrant (because it
allocates data with limited scoop in a statical fashion), C code will be
reentrant, meaning that any function can call any function, including
itself, without having the functions' "instances" conflicting with each
other...
Using that definition of "re-entrant", yes. That is not the meaning
I usually associate with the word, though. "My" meaning is more
general, and implies that the underlying system (which will use
languages other than C) can switch between processes and/or threads
that share the code, in ways that "see through" things the compiler
has done. For instance, a subroutine call in C is atomic -- nothing
can get between the call in the caller and the start of the callee[%]
-- but at the OS level, it generally is not atomic.
Using this version of "reentrant", C code need not be, and at least
historically often was, not reentrant. Specifically, code like:
struct foo func(struct bar x) {
struct foo val;
...
return val;
}
could, if you thread-switched out from the middle of a call or
return, corrupt the parameters and/or return value. The compilers
would emit "non-reentrant" code -- code that worked OK with
C-compiler-generated recursion, but not with general thread-style
re-entering at arbitrary instruction points -- for handling structure
arguments and/or return values.
[% The exception, sort of, to this claim has to do with signals.
But C's signals are (a) not guaranteed to really work like the
hardware interrupts, e.g., the C system could hold off signals
around subroutine calls, and (b) remove many of the guarantees that
C makes that give it the kind of "C level re-entrancy" you describe
above. In particular, a signal handler can only work with variables
of type "sig_atomic_t" if those variable are also accessed from
outside the handler.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>root@ubuntu:/tmp# gcc tmemchr.c
root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
[...]
>How I did that?
This is Left As An Exercise For The Reader.
I don't think I'll bother. Since you don't seem to be inclined to be
cooperative, it's Highly Unlikely to be worth my time and energy to
figure out why you're claiming results that can't be replicated here.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Also, I didnt use the ?: operator, as it would greatly improve upon the
readability of my code which is clearly not desired.
--Daniel Fischer in comp.lang.c
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>jacob navia <ja***@jacob.remcomp.frwrites:
>
>root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
[snip]
>In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux
On an x86 platform.
On his particular x86 system. I couldn't replicate his results on any
of the three x86 systems I tried it on (all run the entire test program
in no more than a few tenths of a second), and nobody else seems to have
though it was worth trying it and posting the results. (On the slowest
of the bunch (the only I tried to find an actual difference on rather
than just re-running the test that navia posted), four billion calls to
either function took a little bit over 200 seconds, with the differences
between them smaller than the error bound on the measurement.)
I asked whether you had tested it on multiple
platforms. Optimizations that work only on x86 systems are only
slightly interesting.
....and optimizations that work only on the x86 system used by the person
claiming the optimization is useful are even less interesting.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
If you can't line up embarrassing examples on both sides of the
argument, then you aren't thinking hard enough.
--Greg Lindahl in comp.arch
Dave Vandervies a écrit :
In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>>root@ubuntu:/tmp# gcc tmemchr.c
root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
[...]
>>How I did that?
This is Left As An Exercise For The Reader.
I don't think I'll bother. Since you don't seem to be inclined to be
cooperative, it's Highly Unlikely to be worth my time and energy to
figure out why you're claiming results that can't be replicated here.
dave
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i,c=0;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if (strchr(s,'1'))
c++;
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if (memchr(s,'1',sizeof(s)))
c++;
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
return c;
}
Dave Vandervies a écrit :
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>jacob navia <ja***@jacob.remcomp.frwrites:
>>>root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
[snip]
>>>In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux
On an x86 platform.
On his particular x86 system. I couldn't replicate his results on any
of the three x86 systems I tried it on (all run the entire test program
in no more than a few tenths of a second), and nobody else seems to have
though it was worth trying it and posting the results. (On the slowest
of the bunch (the only I tried to find an actual difference on rather
than just re-running the test that navia posted), four billion calls to
either function took a little bit over 200 seconds, with the differences
between them smaller than the error bound on the measurement.)
> I asked whether you had tested it on multiple
platforms. Optimizations that work only on x86 systems are only
slightly interesting.
...and optimizations that work only on the x86 system used by the person
claiming the optimization is useful are even less interesting.
dave
I have sent you elsethread the corrected program.
Since now gcc optimizes even when it is not told
to do that, you have to trick it into generating code
for the program you wrote, not for the program gcc
think you should have written.
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
}
DAMM!!!!!
I sent you the wrong one.
Here is the one with the necessary corrections for gcc.
1) new variable c, is incremented at
each function call. Then the compiler
cab't optimize the call away.
To avoid that the variable is discarded
main returns that value
jacob navia a écrit :
>
I have sent you elsethread the corrected program.
Since now gcc optimizes even when it is not told
to do that, you have to trick it into generating code
for the program you wrote, not for the program gcc
think you should have written.
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i,c=0;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if (strchr(s,'1'))
c++;
;
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if( memchr(s,'1',sizeof(s)))
c++;
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
return c;
}
jacob navia wrote:
<snip>
In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux
dougal(~/navia) cat chr.c
#include <stdio.h>
#include <string.h>
#define MAXITER 100000000
int main(void)
{
char s[4096];
int i;
memset(&s, 'a', sizeof(s) - 1);
s[sizeof(s)-1] = 0;
for (i = 0; i < MAXITER; i++)
{
#ifdef MEMCHR
memchr(s, '1', sizeof s)
#else
strchr(s, '1')
#endif
}
return 0;
}
dougal(~/navia) gcc -O0 chr.c -o strchr
dougal(~/navia) time ./strchr
real 0m1.403s
user 0m0.990s
sys 0m0.040s
dougal(~/navia) time ./strchr
real 0m1.743s
user 0m1.000s
sys 0m0.050s
dougal(~/navia) time ./strchr
real 0m1.212s
user 0m1.000s
sys 0m0.050s
dougal(~/navia) gcc -O0 chr.c -DMEMCHR -o memchr
dougal(~/navia) time ./memchr
real 0m1.874s
user 0m1.010s
sys 0m0.020s
dougal(~/navia) time ./memchr
real 0m1.485s
user 0m1.030s
sys 0m0.030s
dougal(~/navia) time ./memchr
real 0m1.282s
user 0m0.990s
sys 0m0.020s
I can see no clear pattern in the performance of the two functions, and
believe that your claim is unsubstantiated.
/proc/cpuinfo says that the processor this was run on was a 735Hz VIA
Ezra (x86) processor, with the flags "fpu de tsc msr cx8 mtrr pge mmx
3dnow", and a 64KB cache.
Andrew Sidwell
--
My email address changes monthly because of Too Much Spam. It's always
the first three letters of the month (in English), followed by the last
two digits of the current year. For example, ja***@entai.co.uk.
Andrew Sidwell wrote:
<snip>
#ifdef MEMCHR
memchr(s, '1', sizeof s)
#else
strchr(s, '1')
#endif
<snip>
Ouch. Please pretend I wrote semicolons at the end of the two lines
which don't start with '#'.
Andrew Sidwell
--
My email address changes monthly because of Too Much Spam. It's always
the first three letters of the month (in English), followed by the last
two digits of the current year. For example, de***@entai.co.uk.
Andrew Sidwell a écrit :
jacob navia wrote:
<snip>
>>In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux
dougal(~/navia) cat chr.c
#include <stdio.h>
#include <string.h>
#define MAXITER 100000000
int main(void)
{
char s[4096];
int i;
memset(&s, 'a', sizeof(s) - 1);
s[sizeof(s)-1] = 0;
for (i = 0; i < MAXITER; i++)
{
#ifdef MEMCHR
memchr(s, '1', sizeof s)
#else
strchr(s, '1')
#endif
}
return 0;
}
dougal(~/navia) gcc -O0 chr.c -o strchr
dougal(~/navia) time ./strchr
real 0m1.403s
user 0m0.990s
sys 0m0.040s
dougal(~/navia) time ./strchr
real 0m1.743s
user 0m1.000s
sys 0m0.050s
dougal(~/navia) time ./strchr
real 0m1.212s
user 0m1.000s
sys 0m0.050s
dougal(~/navia) gcc -O0 chr.c -DMEMCHR -o memchr
dougal(~/navia) time ./memchr
real 0m1.874s
user 0m1.010s
sys 0m0.020s
dougal(~/navia) time ./memchr
real 0m1.485s
user 0m1.030s
sys 0m0.030s
dougal(~/navia) time ./memchr
real 0m1.282s
user 0m0.990s
sys 0m0.020s
I can see no clear pattern in the performance of the two functions, and
believe that your claim is unsubstantiated.
/proc/cpuinfo says that the processor this was run on was a 735Hz VIA
Ezra (x86) processor, with the flags "fpu de tsc msr cx8 mtrr pge mmx
3dnow", and a 64KB cache.
Andrew Sidwell
Obviously there is something wrong since in a MUCH faster machine
for 100 million iterations I take 84/43 SECONDS and you take not even
a second...
I explicitely said that you should NOT set any optimizations, and you
compiled with O0. O0 DOES some optimizations, so this is quite dangerous
with benchmarks. I would suggest that you use this program without any
optimizations at all:
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i,c=0;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if(strchr(s,'1'))
c++;;
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if(memchr(s,'1',sizeof(s)))
c++;
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
return c;
}
The additions to the variable "c" disable any optimization
of the calls away. Besides, main returns that value
and this means that gcc must generate the code as told.
It is very disappointing that compilers optimize when told
not to!!!
jacob
On Sun, 31 Dec 2006 16:14:40 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
Dave Vandervies a écrit :
[snip]
>I started by making sure I was working with a correct C program.
If you consider this inappropriate, you're posting to the wrong newsgroup.
dave
[1] The obvious comment about frames of reference is Left As An Exercise
For The Reader.
root@ubuntu:/tmp# gcc tmemchr.c
root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
root@ubuntu:/tmp# uname -a
Linux ubuntu 2.6.12-10-386 #1 Fri Sep 15 16:31:49 UTC 2006 i686 GNU/Linux
[snip]
In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux
Maybe so, but it takes over 2 minutes to complete on a PPC (dual G5
2.0GHz) system when compiled with gcc. It outputs 0.000000 for the
strchr, and just goes off into the weeds for the memchr portion.
By dividing the iteration count by 10, I get:
Time for strchr=0.000000
Time for memchr=13.000000
So much for any theory that this method is generally applicable.
Even by using -O3 during compilation, it only shaves a second off the
memchr timing.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
On Mon, 1 Jan 2007 16:45:34 -0600, jacob navia wrote
(in article <45***********************@news.orange.fr>):
Dave Vandervies a écrit :
>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>jacob navia <ja***@jacob.remcomp.frwrites:
>>>root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
[snip]
>>>In any case it proves my point
strchr is slower by more than 30 % compared to memchr under libc/linux
On an x86 platform.
On his particular x86 system. I couldn't replicate his results on any
of the three x86 systems I tried it on (all run the entire test program
in no more than a few tenths of a second), and nobody else seems to have
though it was worth trying it and posting the results. (On the slowest
of the bunch (the only I tried to find an actual difference on rather
than just re-running the test that navia posted), four billion calls to
either function took a little bit over 200 seconds, with the differences
between them smaller than the error bound on the measurement.)
>>I asked whether you had tested it on multiple
platforms. Optimizations that work only on x86 systems are only
slightly interesting.
...and optimizations that work only on the x86 system used by the person
claiming the optimization is useful are even less interesting.
dave
I have sent you elsethread the corrected program.
Since now gcc optimizes even when it is not told
to do that, you have to trick it into generating code
for the program you wrote, not for the program gcc
think you should have written.
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
strchr(s,'1');
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
memchr(s,'1',sizeof(s));
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
}
Same as before on the PPC G5. strchr takes zero time to complete,
memchr takes forever.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
On Mon, 1 Jan 2007 16:49:16 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
DAMM!!!!!
I sent you the wrong one.
Here is the one with the necessary corrections for gcc.
1) new variable c, is incremented at
each function call. Then the compiler
cab't optimize the call away.
To avoid that the variable is discarded
main returns that value
jacob navia a écrit :
>>
I have sent you elsethread the corrected program.
Since now gcc optimizes even when it is not told
to do that, you have to trick it into generating code
for the program you wrote, not for the program gcc
think you should have written.
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i,c=0;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if (strchr(s,'1'))
c++;
;
>}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if( memchr(s,'1',sizeof(s)))
c++;
>}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
return c;
>}
Again, I had to reduce the MAXITER value by dividing it by 10 to get
reasonable run times.
Anyway, here is the output:
Time for strchr=17
Time for memchr=13
Okay, you managed to make gcc on the PPC G5 hate them both now. I'm
not sure what that is supposed to prove. Are we to assume people care
about best performance when compiling with optimization turned off?
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Randy Howard a écrit :
On Mon, 1 Jan 2007 16:49:16 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
>>DAMM!!!!!
I sent you the wrong one.
Here is the one with the necessary corrections for gcc.
1) new variable c, is incremented at
each function call. Then the compiler
cab't optimize the call away.
To avoid that the variable is discarded
main returns that value
jacob navia a écrit :
>>>I have sent you elsethread the corrected program.
Since now gcc optimizes even when it is not told
to do that, you have to trick it into generating code
for the program you wrote, not for the program gcc
think you should have written.
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i,c=0;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if (strchr(s,'1'))
c++;
;
>>>}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if( memchr(s,'1',sizeof(s)))
c++;
>>>}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
return c;
>>>}
Again, I had to reduce the MAXITER value by dividing it by 10 to get
reasonable run times.
Anyway, here is the output:
Time for strchr=17
Time for memchr=13
Okay, you managed to make gcc on the PPC G5 hate them both now. I'm
not sure what that is supposed to prove. Are we to assume people care
about best performance when compiling with optimization turned off?
What I wanted to prove is just that since strchr must test
TWO characters: zero AND the character searched, it must be
slower than memchr that tests only if the count is exhausted.
Counted strings then, can use a memchr function to search
for a character since the count is known. strchr is much faster
then for those strings.
PHEW!!!!
What I thought would be evident for everyone was kind
of difficult to prove, specially since gcc seems to optimize
things when nobody is asking for it.
I personally think that a compiler should TRANSLATE the
program AS IS, not be some kind of artificial intelligence
machine that decide how you should have written the
program... specially because they guess WRONG in
some cases.
In article <45***********************@news.orange.frjacob navia <ja***@jacob.remcomp.frwrites:
Andrew Sidwell a écrit :
....
dougal(~/navia) gcc -O0 chr.c -o strchr
....
I explicitely said that you should NOT set any optimizations, and you
compiled with O0. O0 DOES some optimizations, so this is quite dangerous
with benchmarks.
From the gcc man page:
-O0 Do not optimize.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
jacob navia wrote:
Obviously there is something wrong since in a MUCH faster machine
for 100 million iterations I take 84/43 SECONDS and you take not even
a second...
I explicitely said that you should NOT set any optimizations, and you
compiled with O0. O0 DOES some optimizations, so this is quite dangerous
with benchmarks. I would suggest that you use this program without any
optimizations at all:
The man page for gcc states that -O0 is the default, and so your own
results are tainted in a similar manner.
<snip code>
>
The additions to the variable "c" disable any optimization
of the calls away. Besides, main returns that value
and this means that gcc must generate the code as told.
It is very disappointing that compilers optimize when told
not to!!!
I get:
Time for strchr=394
And the time for memchr was getting on for fifty minutes...
Changing MAXITER to 100000, I get (terminated early because of the time
it was taking):
dougal(~/navia) time ./a.out
Time for strchr=3
real 0m39.707s
user 0m31.120s
sys 0m0.250s
Andrew Sidwell
--
My email address changes monthly because of Too Much Spam. It's always
the first three letters of the month (in English), followed by the last
two digits of the current year. For example, de***@entai.co.uk.
Andrew Sidwell a écrit :
jacob navia wrote:
>>Obviously there is something wrong since in a MUCH faster machine
for 100 million iterations I take 84/43 SECONDS and you take not even
a second...
I explicitely said that you should NOT set any optimizations, and you
compiled with O0. O0 DOES some optimizations, so this is quite dangerous
with benchmarks. I would suggest that you use this program without any
optimizations at all:
The man page for gcc states that -O0 is the default, and so your own
results are tainted in a similar manner.
<snip code>
>>The additions to the variable "c" disable any optimization
of the calls away. Besides, main returns that value
and this means that gcc must generate the code as told.
It is very disappointing that compilers optimize when told
not to!!!
I get:
Time for strchr=394
And the time for memchr was getting on for fifty minutes...
Changing MAXITER to 100000, I get (terminated early because of the time
it was taking):
dougal(~/navia) time ./a.out
Time for strchr=3
real 0m39.707s
user 0m31.120s
sys 0m0.250s
Andrew Sidwell
You should of course lower the iterations since they
are machine dependent!!!
It really depends on the couple/libc implementation and processor.
I did not know that O0 was the default. In any case, I do get
those results in the linux machine. It would be interesting to lower
the count and to try again if possible.
Which version of gcc are you using?
jacob navia <ja***@jacob.remcomp.frwrites:
Dave Vandervies a écrit :
>In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>>>root@ubuntu:/tmp# gcc tmemchr.c
root@ubuntu:/tmp# ./a.out
Time for strchr=51
Time for memchr=27
[...]
>>>How I did that?
This is Left As An Exercise For The Reader.
I don't think I'll bother. Since you don't seem to be inclined to be
cooperative, it's Highly Unlikely to be worth my time and energy to
figure out why you're claiming results that can't be replicated here.
dave
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i,c=0;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if (strchr(s,'1'))
c++;
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if (memchr(s,'1',sizeof(s)))
c++;
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
return c;
}
You're still printing your time_t values incorrectly. "%d" expects a
value of type int. I suggest:
printf("Time for memchr=%lu\n", (unsigned long)tMemchr));
Subtracting time_t values is not a good way to measure performance.
You're measuring wall-clock time, not CPU time. And subtracting
time_t values doesn't necessarily give you a meaningful result (which
is why the difftime() function exists). You'd be better off using the
clock() function rather than the time() function.
I've gotten the following results on various platforms:
x86:
Time for strchr=33
Time for memchr=18
IA-64:
Time for strchr=16
Time for memchr=8
PowerPC:
Time for strchr=46
Time for memchr=127
PowerPC64:
Time for strchr=158
Time for memchr=239
(I'm running it on a SPARC as well, but I've lost patience waiting for
the output.)
So memchr is significantly faster on some systems, and significantly
slower on others.
--
Keith Thompson (The_Other_Keith) 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.
On Mon, 1 Jan 2007 18:44:08 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
Randy Howard a écrit :
>On Mon, 1 Jan 2007 16:49:16 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
>>DAMM!!!!!
I sent you the wrong one.
Here is the one with the necessary corrections for gcc.
1) new variable c, is incremented at
each function call. Then the compiler
cab't optimize the call away.
To avoid that the variable is discarded
main returns that value
jacob navia a écrit :
I have sent you elsethread the corrected program.
Since now gcc optimizes even when it is not told
to do that, you have to trick it into generating code
for the program you wrote, not for the program gcc
think you should have written.
#include <stdio.h>
#include <time.h>
#include <string.h>
#define MAXITER 10000000
int main(void){
char s[4096];
int i,c=0;
time_t t,tStrchr,tMemchr;
for (i=0; i<sizeof(s)-1;i++) {
s[i] = 'a';
}
s[sizeof(s)-1] = 0;
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if (strchr(s,'1'))
c++;
;
}
tStrchr= time(NULL) - t;
printf("Time for strchr=%d\n",tStrchr);
t = time(NULL);
for (i=0; i<MAXITER;i++) {
if( memchr(s,'1',sizeof(s)))
c++;
}
tMemchr=time(NULL)-t;
printf("Time for memchr=%d\n",tMemchr);
return c;
}
Again, I had to reduce the MAXITER value by dividing it by 10 to get
reasonable run times.
Anyway, here is the output:
Time for strchr=17
Time for memchr=13
Okay, you managed to make gcc on the PPC G5 hate them both now. I'm
not sure what that is supposed to prove. Are we to assume people care
about best performance when compiling with optimization turned off?
What I wanted to prove is just that since strchr must test
TWO characters: zero AND the character searched, it must be
slower than memchr that tests only if the count is exhausted.
Counted strings then, can use a memchr function to search
for a character since the count is known. strchr is much faster
then for those strings.
PHEW!!!!
What I thought would be evident for everyone was kind
of difficult to prove, specially since gcc seems to optimize
things when nobody is asking for it.
I personally think that a compiler should TRANSLATE the
program AS IS, not be some kind of artificial intelligence
machine that decide how you should have written the
program... specially because they guess WRONG in
some cases.
Given that the compiler generates code which executes in 0 time, versus
like 2 minutes as you wrote it, I'll take the compiler's version. :-)
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...
Stephen Sprunk a écrit :
>"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**********************@news.orange.fr...
>>Instead of strcat Strcat, etc. That's why operator overloading comes
handy since it allows ...
C does not have operator (or any other type of) overloading. You
appear to have, yet again, gotten lost on your way to comp.lang.c++.
<OTC++ even has a standard "string" object, which does all of the
nice things you're advocating here, and is typically implemented with
counted strings. </OT>
I have implemented operator overloading in the lcc-win32
coimpiler system. I think it is an improvement to C, without
incurring with all the associated costs of C++.
So was C++ at first :)
You're free, of course, to add any extensions you want to your product,
but any discussion you have _here_ needs to be confined to Standard C,
which you well know. Quit using this forum as a soapbox to market your
product and advocate something which is not C. If you wish to discuss
changing C to include your extensions, feel free to visit comp.std.c.
Here, please limit your discussion to how your product behaves when
invoked in a standards-compliant mode (if you have one).
And no, nobody is out to get you. The GCC and MSVC folks get the same
treatment, and for the same reason. You're the only one that doesn't
get the concept of topicality.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com
In article <45***********************@news.orange.frjacob navia <ja***@jacob.remcomp.frwrites:
....
The additions to the variable "c" disable any optimization
of the calls away. Besides, main returns that value
and this means that gcc must generate the code as told.
The variable c is not needed for that. It is sufficient that the return
value of the function is used in some way (e.g.
if(strcgr(s, '1'));
is sufficient). If the result is not used, gcc removes the call, even
with -O0.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter a écrit :
In article <45***********************@news.orange.frjacob navia <ja***@jacob.remcomp.frwrites:
...
The additions to the variable "c" disable any optimization
of the calls away. Besides, main returns that value
and this means that gcc must generate the code as told.
The variable c is not needed for that. It is sufficient that the return
value of the function is used in some way (e.g.
if(strcgr(s, '1'));
is sufficient). If the result is not used, gcc removes the call, even
with -O0.
I see that as a bug. Why it removes things when not
asked for optimizations???
In a more philosophical mood, I think a compiler
is a TRANSLATOR of MY program, not something
that translates my program as it thinks I should have written
it...
jacob navia said:
Dik T. Winter a écrit :
<snip>
>If the result is not used, gcc removes the call, even
with -O0.
I see that as a bug. Why it removes things when not
asked for optimizations???
The Standard doesn't require it not to, so it's not a bug.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: William C. White |
last post by:
Does anyone know of a way to use PHP /w Authorize.net AIM without using
cURL? Our website is hosted on a shared drive and the webhost company
doesn't installed additional software (such as cURL)...
|
by: Albert Ahtenberg |
last post by:
Hello,
I don't know if it is only me but I was sure that header("Location:url")
redirects the browser instantly to URL, or at least stops the execution of
the code. But appearantely it continues...
|
by: James |
last post by:
Hi,
I have a form with 2 fields.
'A'
'B'
The user completes one of the fields and the form is submitted.
On the results page I want to run a query, but this will change
subject to which...
|
by: Ollivier Robert |
last post by:
Hello,
I'm trying to link PHP with Oracle 9.2.0/OCI8 with gcc 3.2.3 on a Solaris9
system. The link succeeds but everytime I try to run php, I get a SEGV from
inside the libcnltsh.so library.
...
|
by: Richard Galli |
last post by:
I want viewers to compare state laws on a single subject.
Imagine a three-column table with a drop-down box on the top. A viewer
selects a state from the list, and that state's text fills the...
|
by: Albert Ahtenberg |
last post by:
Hello,
I have two questions.
1. When the user presses the back button and returns to a form he filled
the form is reseted. How do I leave there the values he inserted?
2. When the...
|
by: inderjit S Gabrie |
last post by:
Hi all
Here is the scenerio ...is it possibly to do this...
i am getting valid course dates output on to a web which i have designed
....all is okay so far , look at the following web url
...
|
by: Jack |
last post by:
Hi All,
What is the PHP equivilent of Oracle bind variables in a SQL statement, e.g.
select x from y where z=:parameter
Which in asp/jsp would be followed by some statements to bind a value...
|
by: Sandwick |
last post by:
I am trying to change the size of a drawing so they are all 3x3.
the script below is what i was trying to use to cut it in half ... I
get errors.
I can display the normal picture but not the...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
| |
