Home  |  News  |  Reviews  | About Search :  HardWare.fr 



MiscellaneousStorageGraphics CardsMotherboardsProcessors
Advertise on BeHardware.com
Review index:
The impact of compilers on x86/x64 CPU architectures
by Guillaume Louel
Published on September 27, 2012

Optimisations and performance
As we said previously, there’s more than one way of translating a C programme into machine language that can be executed by a processor. Compilers tend to differentiate themselves by offering options and optimisations designed to improve performance. Before going further and clarifying what we mean by optimisations, it’s important to put how much of an impact compilers have into context.

Although compilers are increasingly intelligent and can sometimes offer impressive optimisations and gains in performance, they don’t perform miracles and can’t automatically transform a slow and poorly designed algorithm (the program’s logic) into something that is very fast. Whether through parallelism (using all the cores) or by optimising processing on modern processors, compilers attempt to do their best with the code written by developers. To make things more complicated, the gap between the developer's domain and that of the compiler is getting smaller all the time. While managing multiple cores in parallel is supposed to be part of the developers domain, some compilers do attempt (often badly) to have an impact in this area. On the other hand, processor architecture, supposedly entirely hidden by C/C++ and purely the domain of the compiler, is in fact taken into account by developers via various mechanisms designed to inform the compiler of their intentions. Almost an art, aiming to get the most out of modern processor performance is a very difficult balancing act, both for the developer and the compiler. Having said this, let’s now get back to the different optimisations that we can expect to find in the various compilers!

Reducing the size
In past times, the quality of a compiler was judged on how big the executable file (the compiled machine code) that it produced was. At a time when storage was costly, economising a few kilobytes was significant.

Above and beyond the simple gain in space however, reducing the size of this file was considered to represent a performance optimisation. Given that processors are classified according to the number of instructions they can process per second, reducing the number of instructions in a program and reducing its size does therefore seem worthwhile!


While there is something in this, the issue of the size of the executable file is now more complicated. Not all instructions take the same time to be processed. With Intel’s Sandy Bridge architecture for example, an addition (add) has a latency of one cycle (1 hertz of the processor’s GHz total), a full multiplication (imul) three and a division (div) 26! Moreover this can change from one processor to another: on a Pentium 4 F a multiplication has a latency of 10 cycles.

Things get more complicated when you take into account the fact that processors have multiple units in each of their cores (known as superscalar architectures and providing the possibility of executing several instructions per cycle, an innovation introduced with the Pentium; we often speak about this in our articles on processor architecture such as Sandy Bridge). A Sandy Bridge processor can thus carry out three additions at the same time in a single cycle, as can Phenom IIs. With Bulldozer, this drops to two per core (if you’re interested you can find a full list of latencies and instruction speeds on multiple x86 architectures in this PDF from Torbjörn Granlund).

Optimising for size does nevertheless remain an option included in compilers and later in this report we will see a case where this was beneficial. In most other cases, this option slowed performance down.

<< Previous page
C, C++, role of the compiler

Page index
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16
Next page >>
Optimising for particular CPU architectures  




Copyright © 1997- Hardware.fr SARL. All rights reserved.
Read our privacy guidelines.