RE: [Dev-C++] Discussion about C/C++ details

[Ioannis V. <no...@ya...>]

Are you sure you have all optimizations on? We agree only at the last
result. I can't understand how memset() takes more than the for loop. As
for the case of length it is surely compiler defect. Standard library
operations are always expected to be at least as fast as our equivalents
(and since compiler can be more low level). strlen() case here is
unacceptable. About memset() latency probably it has to do with the
operating system, probably that your swap file is being used. Try to
reduce the string. It has nothing to do that the memory has been just
assigned.
=20
Anyway as you see strcat() outperforms our high level portable character
by character search. And if you want to see pure performance results,
since you have few memory close all running applications before
executing.
=20
About the operation ++x versus x++ for BUILT IN types, there is no value
returned if they are used stand alone. If they are assigned at the first
an increase is performed and then it is assigned, at the second it is
assigned and then it is increased which means the same performance.
=20
For custom classes operator++() and operator++(int) *have* difference in
performance when they are performed stand alone because they are
*functions* and we define them the first to increment the value and then
return the value and the second usually to create a copy of the existing
value, then increment the normal value and return the copy which takes
more time and space than the first. And these if we define them to
behave as the operators of built in types do (and this is what we must
do).=20
=20
At my first C times i was feeling very cool to use pointer arithmetic
and travel across even multidimensional arrays as if they were single
dimensional, or cast a pointer to a function to char *  and putchar()
its guts to the screen under dos, but the performance is the same. In
summary the postfix and prefix operator performance differences for
built in types is a myth and it applies only (and *usually*) for our
classes. Also the difference in performance between pointer arithmetic
and array indexing for built in types is also a myth and may apply only
for our classes if we define our iterators to behave different than
operator []. In case for C++ standard library there *must* be no
difference too.
=20
=20
Ioannis
=20
* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

-----Original Message-----
From: Jason Hardman [mailto:jas...@bt...]=20
Sent: Friday, October 26, 2001 5:28 PM
To: Ioannis Vranos
Subject: Re: [Dev-C++] Discussion about C/C++ details


My machine is a PIII 750MHz, 128Mb RAM, so we are bound to have some
performance differences. The results I got were:
=20
Time spent for memset(): 770
Time spent for the for loop: 440
=20
strcat() needed: 330
Our manual strcat character by character thing needed: 390
=20
The size of our string was: 63999992
strlen() needed to measure the string length: 660
The time we needed to measure the length of the string: 380
=20
Some of the differences can be accounted for my the loading of my
machine. I've not gone to the trouble of shutting down all the
background tasks before running this test. The length taken for the
memset is probably because the memory had only just been assigned.
=20
The reason that I recommend the pre form over the post form in increment
and decrement operators is because of a discussion on a newsgroup I once
read. The gist of it was that when using a post form, a copy of the
original value is made before it is modified, and the copy is returned
as the result of the operator. I don't know if it's still true in modern
compilers. This copy will be discarded if it isn't assigned to anything
and so is a waste. Part of the argument was that the name C++ is
misleading and it really should be ++C if you wanted to follow a good
programming practice. :)
=20
As for pointer arithmetic, that was about something I was taught when
leaning C. It seems to be no longer true now, but I still like to use a
pointer to traverse an array rather than an index.
=20
That website certainly doesn't like Herbert Schilt do they? I'm not
going to argue about the relative merits of different authors. I still
use The Complete Reference books I have and that is what they are used
as, references. I'm not familiar with every nuance of C/C++ and so when
I answer a question posted on this site I am generally refering to at
least one of my books to check syntax, validity and context.
=20
Jason.

----- Original Message -----=20
From: Ioannis Vranos <mailto:no...@ya...> =20
To: Dev-C++ <mailto:dev...@li...> =20
Sent: Friday, October 26, 2001 1:01 PM
Subject: [Dev-C++] Discussion about C/C++ details


At first the results of your code to my pc (piii 1000 MHz, 512 MB RAM):
=20
Time spent for memset(): 200
Time spent for the for loop: 350
=20
strcat() needed: 290
Our manual strcat character by character thing needed: 340
=20
The size of our string was: 63999992
strlen() needed to measure the string length: 481
The time we needed to measure the length of the string: 340
=20
=20
I hadn't thought that the compiler excludes the call and assignment of
i=3Dstrlen() because it notices we do not use i (clever indeed).  But =
the
rest shows clearly that memset() is not using character by character
assignment to assign values and strcat is not looking character after
character too (perhaps they use an int pointer and make tricks,
something i just thought but not character after character).=20
=20
=20
It seems that we will never end arguing on details. I disagree with your
comment:
=20
/* When using increment or decrement operators you should use the pre
form
    rather than the post form as it is more efficient. Only post
increment or
    decrement when you need the value before the change.
    Also pointer arithmetic is faster than array indexing. */
=20
=20
This is truth *only* if we use overloaded post increment and decrement
operators for our objects and not for built in types. This thing reminds
me something i read on the web from a Schildt book, i will not tell you
about Schildt, check www.accu.org at the book reviews and read the
reviews of his books.=20
Also pointer arithmetic and array indexing is exactly the same and
compiler translates them the same. So this is definately wrong too. :)
=20
=20
I changed the color so as to find quickly my disagreements. :)
=20
=20
=20
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 3:31 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


I'm sure you want this over and done with, but I decided to look at your
code and I have optimised some of it, and corrected an error that cause
a miss read of the time taken for strlen(). I hadn't realised this, but
when you are assigning a variable a value you don't use the compiler
happily ignores the value and doesn't bother with the assignment. What
that meant was it didn't actualy execute the strlen function in your
version, hence no time taken. I hadn't known this before, but it's quite
clever.
=20
I also did some other optimisations, I note that strcat() is still
slightly faster than our own version, but not by a massive margin. I'm
not absolutley sure that the tests are equal, but they seem to be
representative. I find it funny that my "memset" is faster than the real
one, so maybe there's an error or unaccounted optimisation somewhere?
=20
Note that I did the test using full compiler optimisations, as that
would be representative of a real world test. Also note that I decreased
SIZE, because I have only 128MB on my machine and using a 100 million
bytes forces windows to use virtual memory, which will cause large
slowdown, and prevent accurate figures.
=20
I was tempted to rewrite it all into a style I would normally use, but
couldn't be bothered. :-D
=20
Regards, Jason.

----- Original Message -----=20
From: Ioannis  <mailto:no...@ya...> Vranos=20
To: Dev-C++ <mailto:dev...@li...> =20
Sent: Friday, October 26, 2001 1:02 AM
Subject: RE: [Dev-C++] Errorhandling

Ok, we all agree that it is working like that but i am probably right on
this (as you were right for some other details in things i had not
noticed before).
=20
But my last effort to persuade you is attached in this email as file
temp.c . It is ANSI C code and it shows the differences between the
performance of standard library functions and character by character
things. Please take a look and execute the code.
=20
=20
The results to my machine:
=20
C:\c>temp
Time spent for memset(): 300
Time spent for the for loop: 471
=20
strcat() needed: 461
Our manual strcat character by character thing needed: 571
=20
strlen() needed to measure the string length: 0
The time we needed to measure the length of the string: 560
=20
=20
Notice especially the last.
=20
=20
Friendly,
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 12:05 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


You cannot always know the length of an array or string at compile time.
It is possible for things like array size and such to be determined at
compile-time and at run-time (depending), but by doing it at run-time
you are incurring an overhead in your code, which isn't part of the C
style of programming. Adding these mechanisms to C code with hidden
compiler features would be breaking the general C/C++ ethic, at least in
my view.
=20
The only reason I'm 'discussing' this is because the more I think about
it the more I come to believe that it's more likely that standard
functions like strcat() and strlen() will determine the length of the
string by going all the way through the string until null. I know this
is an old argument, but I find it difficult to believe that it would be
done a different way. C doesn't actualy have native support for strings,
it just uses an array of chars, and allows the definition of string
literals.
=20
In Pascal, for example, it does have native support for strings and you
will find that it will store a pointer to an array and the first element
of the array will be the length of the string that follows.
=20
If you want we can end this particular argument and settle on the fact
that we are both willing to differ in opinion, and that it doesn't
matter which is true 'cos it still works no matter what.
=20
Jason.