Author: Omid David Tabibi
Date: 07:32:53 09/27/03
Go up one level in this thread
On September 27, 2003 at 09:36:00, Russell Reagan wrote:
>On September 27, 2003 at 08:22:47, Omid David Tabibi wrote:
>
>>Isn't it better to always use unsigned int instead of int, for example:
>>
>> for (unsigned int i; i < numner; i++)
>>
>>instead of
>>
>> for (int i; i < numner; i++)
>
>You could test it pretty easy. I have something in my program like this:
>
>typedef int Int32;
>typedef unsigned int UInt32;
>typedef Int32 Int;
>typedef Uint32 UInt;
>
>There are others for 16-bit and 8-bit data. The main advantage is that I can
>switch to a 64-bit platform by changing a line or two of code here
>(specifically, Int and UInt to be 64-bit types).
>
>I could add a FastInt type or something like that, which will just be the
>fastest available type when there is a choice between int and unsigned int. You
>could do two compiles and compare.
>
>Also worth checking out is this chart
>(http://www.tantalon.com/pete/cppopt/appendix.htm#AppendixB_RelativeCosts),
>although it is on a PIII. Note that the author says statistical error is +/-
>0.1. It would be interesting to see how the author tested this.
A very interesting table, which again shows that the fastest type is the system
word size (BOOL better than bool ?!).
Another interesting point I found on those pages:
--------
2.2: Consider Using References Instead of Pointers
As a basic design premise, consider using references instead of pointers. A
quick example for comparison:
int x;
void Ptr(const int* p) { x += *p; }
void Ref(const int& p) { x += p; }
The Ptr function and the Ref function generate exactly the same machine
language. The advantages of the Ref function:
- There's no need to check that the reference is not NULL. References are never
NULL. (Creating a NULL reference is possible, but difficult).
- References don't require the * dereference operator. Less typing. Cleaner
code.
- There's the opportunity for greater efficiency with references. A major
challenge for compiler writers is producing high-performance code with pointers.
Pointers make it extremely difficult for a compiler to know when different
variables refer to the same location, which prevents the compiler from
generating the fastest possible code. Since a variable reference points to the
same location during its entire life, a C++ compiler can do a better job of
optimization than it can with pointer-based code. There's no guarantee that your
compiler will do a better job at optimization, but it might.
--------
This last point is especially interesting. Do the compilers really manage to
produce better code when references are used instead of pointers?
Speaking of pointers, the following note from AMD Athlon Optimization guide is
noteworthy:
--------
Use Array-Style Instead of Pointer-Style Code
The use of pointers in C makes work difficult for the optimizers
in C compilers. Without detailed and aggressive pointer
analysis, the compiler has to assume that writes through a
pointer can write to any place in memory. This includes storage
allocated to other variables, creating the issue of aliasing, i.e.,
the same block of memory is accessible in more than one way.
To help the C compiler optimizer in its analysis, avoid the use of
pointers where possible. One example where this is trivially
possible is in the access of data organized as arrays. C allows the
use of either the array operator [] or pointers to access the
array. Using array-style code makes the task of the optimizer
easier by reducing possible aliasing.
For example, x[0] and x[2] cannot possibly refer to the same
memory location, while *p and *q could. It is highly
recommended to use the array style, as significant performance
advantages can be achieved with most compilers.
>
>Also, is there a penalty for doing assignment between int and unsigned, and vice
>versa? It seems like some kind of conversion might be needed.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.