Additional ways of increasing productivity of program systems

In the last part of this article we’d like to touch upon some more technologies which may be useful for you while developing resource-intensive program solutions.

Intrinsic- functions

Intrinsic-functions are special system-dependent functions which execute actions impossible to be executed on the level of C/C++ code or which execute these actions much more efficiently. As the matter of fact they allow to avoid using inline-assembler because it is often impossible or undesirable.

Programs may use intrinsic-functions for creating faster code due to the absence of overhead costs on the call of a usual function type. In this case, of course, the code’s size will be a bit larger. In MSDN the list of functions is given which may be replaced with their intrinsic-versions. For example, these functions are memcpy, strcmp etc.

In Microsoft Visual C++ compiler there is a special option «/Oi» which allows to automatically replace calls of some functions with intrinsic-analogs.

Beside automatic replacement of usual functions with intrinsic-variants we can explicitly use intrinsic-functions in the code. It may be used due to the following reasons:

• Inline assembler code is not supported by Visual C++ compiler in 64-bit mode, while intrinsic-code is.
• Intrinsic-functions are simpler to use as they don’t require the knowledge of registers and other similar low-level constructions.
• Intrinsic-functions are updated in compilers, while assembler code has to be updated manually.
• Inline optimizer doesn’t work with assembler code, that’s why you need exterior linking of the module, while intrinsic-code doesn’t need this.
• Intrinsic-code is easier to port than assembler code.
• The use of intrinsic-functions in automatic mode (with the help of the compiler’s key) allows to get some per cent of productivity increase free and “manual” mode even more. That’s why the use of intrinsic-functions is justified.
• To learn more about the use of intrinsic-functions you may see Visual C++ group’s blog [21].

Data blocking and alignment

• Data alignment doesn’t influence the code productivity so greatly as it was 10 years ago. But sometimes you can get a little profit in this sphere too saving some memory and productivity.

Let’s look at an example:

struct foo_original {int a; void *b; int c; };

struct foo_new { void *b; int a;  int c; };

// 16-byte aligned data
__declspec(align(16)) double init_val [3.14, 3.14];
// SSE2 movapd instruction
_m128d vector_var = __mm_load_pd(init_val);

Files mapped into memory

With the appearance of 64-bit systems the technology of mapping of files into memory became more attractive because the data access hole increased. It may be a very good addition for some applications. Don’t forget about it.

Memory mapping of files is becoming less useful with 32-bit architectures, especially with the introduction of relatively cheap recordable DVD technology. A 4 Gb file is no longer uncommon, and such large files cannot be memory mapped easily to 32-bit architectures. Only a region of the file can be mapped into the address space, and to access such a file by memory mapping, those regions will have to be mapped into and out of the address space as needed. On 64-bit windows you have much larger address space, so you may map whole file at once.

Keyword __restrict

One of the most serious problems for a compiler is aliasing. When the code reads and writes memory it is often impossible at the step of compilation to determine whether more than one index is provided with access to this memory space, i.e. whether more than one index can be a "synonym" for one and the same memory space. That's why the compiler should be very careful working inside a loop in which memory is both read and written while storing data in registers and not in memory. This insufficient use of registers may influence the performance greatly.

The keyword __restrict is used to make it easier for the compiler to make a decision. It "tells" the compiler to use registers widely.

Keyword __restrict allows the compiler not to consider the marked pointers aliased, i.e. referring to one and the same memory area. In this case the compiler can provide more efficient optimization. Let’s look at the example:

int * __restrict a;
int *b, *c;
for (int i = 0; i < 100; i++)
{
	*a += *b++ - *c++ ;  // no aliases exist

}

SSE- instructions

Applications executed on 64-bit processors (independently of the mode) will work more efficiently if SSE-instructions are used in them instead of MMX/3DNow. This is related to the capacity of processed data. SSE/SSE2 instructions operate with 128-bit data, while MMX/3DNow only with 64-bit data. That’s why it is better to rewrite the code which uses MMX/3DNow with SSE-orientation.

We won’t dwell upon SSE-constructions in this article offering the readers who may be interested to read the documentation written by developers of processor architectures.

Some particular rules of using language constructions

64-bit architecture gives new opportunities for optimizing the programming language on the level of separate operators. These are the methods (which have become traditional already) of “rewriting” pieces of a program for the compiler to optimize them better. Of course we cannot recommend these methods for mass use but it may be useful to learn about them.

On the first place of the whole list of these optimizations is manual unrolling of the loops. The essence of this method is clear from the example:

double a[100], sum, sum1, sum2, sum3, sum4;
sum = sum1 = sum2 = sum3 = sum4 = 0.0;
for (int i = 0; i < 100; I += 4)
{
sum1 += a[i];
sum2 += a[i+1];
sum3 += a[i+2];
sum4 += a[i+3];
}
sum = sum1 + sum2 + sum3 + sum4;

• In many cases the compiler can unroll the loop to this form (/fp:fast key for Visual C++) but not always.
• Another syntax optimization is the use of array notation instead of pointer one.

A lot of such methods are described in "Software Optimization Guide for AMD64 Processors" [12].

Conclusion