Intel® Software Network (FR) » ISN France

Create a Ubuntu 11.04 LiveUSB to use Intel® Parallel Studio XE

Xavier Hallade (Intel) — Mon, 14 May 2012 06:49:52 +0000

You need a license for Intel® Parallel Studio XE for Linux and and at least a 4GB USB Key.

Get an ISO image of Ubuntu 11.04.

Create a new Ubuntu 11.04 LiveUSB, with persistence mode enabled (you can specify a size of 1mo for the persistence file, you will overwrite it with a ~3Go file in the next step).

To do that from Windows, you can use LiLi :

but any other tool like Unetbootin or USB Universal Installer is fine.

Download casper-rw.zip and unzip casper-rw to the root of your freshly built Ubuntu LiveUSB :

It is a persistence file that contains an installation of Parallel Studio XE 2011 SP1 Update1.

Create a new folder at the root of your key, named "intel-licenses", and put your .lic file inside it.

Now you are ready to boot on this LiveUSB and directly use Intel® tools to accelerate your code

The Maximum Subarray Problem - Algorithmic Optimizations

candreolli — Mon, 28 Nov 2011 08:55:10 +0000

Acceler8 contest

Andreolli Cédric - Garcia Pascal - Templé Arthur

Date: October 15th 2011 - November 15th 2011

Abstract:

This report explains the approach we used for resolving the ``Maximum Subarray Problem'' during the Intel Acceler8 contest. We are two students in fourth year and a teacher at INSA of Rennes.
The idea of the contest was to build an algorithm able to scale on computers with large number of cores. Here are the different steps of the development process. We hope you will enjoy reading it as much as we enjoyed the contest.

Introduction

The maximum subarray problem

The first step was, of course, to understand the problem. The maximum subarray problem is a well known algorithmic problem. It consists of finding the rectangle (a submatrix) with the maximum area in a matrix of integers.

A lot of documentation about this problem can be found on the Internet. First, we started to study and test some algorithms we found such as the Kadane algorithm.

We choose to use C++ for solving the problem. C++ offers the advantage to be quite low level if you need it, but you also have access to higher level objects such as vectors, lists, etc. Besides, we are currently learning this language at INSA so it was a good opportunity to practice.

OpenMP

For the parallelization part, we chose to use OpenMP. We made this choice for two main reasons.

First, the video tutorial was really easy to understand and went over a lot of functionalities really helpful for what we planned to do. Furthermore, the MTL did not recquire a lot of specific settings to work with OpenMP and we thought it was a good idea not to loose time on compilation problems.

The second reason is that none of us ever used it and it is always interesting to discover new libraries. One of the main interest that offers OpenMP is that it allows you to incrementally parallelized your code. With really few changes, you can improve the speed of a sequential program and this is one of the big interest we found in this library.

Finally, OpenMP offers the advantage of adding very few lines of code. For example, you do not have to use multiple semaphores or mutexes to protect your critical datas.

Different tasks

Once we finished to discover the possibilities of OpenMP, we decided to split the project into some independent tasks.
The next sections explain those different tasks. You will also find the program documentation in the doc directory.

Reading the files

Problems encountered

As we decided to work with C++, we started to create a really simple file reader. So we used the basic STL operations at first and we proceeded as follows:

std::ifstream file(fileName, std::ios::in);
std::string line;...
...ringstream::in);
while(tmp»num){
//Parsing code here
}
}
}
\end{lstlisting}">

But actually, the line:

while(tmp»num){
\end{lstlisting}">

had really bad performances. We then decided to write our own integer parser. After few tests, it was really faster. Then we started to think about the possibility to parallelize this step.

We first took some time to see what was going on when we read a file and parsed it into a vector. As a matter of fact, we could see that the cores were absolutly not busy during this operation.
As there were a lot of hard drive access, the cores were spending most of their time to wait until data arrived. It was not optimal but for us, it was not possible to parallelize the file reading operation because there is only one bus between the hard drive and the main memory.

The way we resolved it

Finally, after more tries, we realized that loading the whole file into main memory was quite fast. We call buffer this array of characters.
We then imagined a trick to use parallelization to speed-up the parsing of the files.

Actually, once the file is in main memory, it is really fast to run throught it. So we decided to go two times through the whole file.
The first time, to get the matrix dimensions, the second, to parse the file.

Getting the matrix dimensions

At this point, we wanted to spend the least time we can on this step but as the buffer is an array of characters, it is really difficult to parallelize the whole process.
So we decided to sequentially read the first line (until a '\n' is found) and count the number of columns of the matrix thanks to the white spaces.
As the input file must respect some specifications, we are sure that the number of columns of the matrix is equal to the number of spaces on a line plus one.
Once this step is over, we just need to rush through the rest of the file to count the '\n'. This last step can easily be parallelized with
OpenMP and a #pragma omp for directive.

During this process, we register the addresses of the new lines into a vector named addressTab.

Parsing the file

Once we get the matrix dimensions, we get a vector (addressTab) which contains the addresses of all new lines in buffer.
We can now parallelize the file parsing. Depending on the number of cores we have, we split buffer into different parts based on the new lines addresses (see Figure 1).

**Figure 1:**
The file parsing parallelization

The goal of the process is to fill a two dimensions vector. We will call this vector: matrix. The elements in addressTab corresponds to the addresses of the beginning of each new lines in buffer and as a core is at least responsible of an entire line, it can put the parsed numbers to the correct position in matrix.

Our algorithm for solving the maximum subarray problem is faster if the matrix of n rows and m columns is such that n ≤ m. So we have two different functions for generating an optimal matrix (readLinesOrdered and readLinesReversed).
We did not factorize this part of the code because of optimization concerns. Indeed, this would have add a test condition for every numbers we had to put in matrix. On big files, this could have been an important waste of time.

The one dimension algorithm

We actually do not have a lot to tell here.
We started to work on this algorithm and wrote some parallelized functions to do it, but as it is already a very fast sequential algorithm (
O(n) complexity), the improvments were not significant. Actually, the time needed for solving the problem, was not significant compare to the time needed to read and parse the file.

The two dimensions problem was hard enough, so we decided not to spend more time on this particular case.

The two dimensions algorithm

The Kadane algorithm

As said before, the two dimensions maximum subarray problem is a well known problem and it is possible to find some documentations on the Internet.
We decided to work on the Kadane algorithm which is quite simple to understand.
We started to work on the parallelization process for this algorithm. The two dimensions Kadane algorithm is a generalization of the one dimension case.
It is based on three overlapped for loops.

As we chose to use OpenMP, we had two main approaches. One was to use the #pragma omp for directive, the second one was to use the #pragma omp task one.
We started with the easy solution (the #pragma omp for). After running some tests, we could see that the cores were not busy during all the process. That is the reason why we imagined a solution with the #pragma omp task directive.

The idea was to compute the number of tasks we wanted to create (let's call it numberOfTasks) and launch the tasks. Each task is responsible for computing the maximal sum (and the associated coordinates) for a part of the matrix.
The first for loop in the Kadane algorithm iterates on the rows of the matrix.
The parallelization is done by dividing the loop in numberOfTasks tasks. Each thread assigned to a task realize a for loop but instead of incrementing by one, we increment by numberOfTasks.
Here is the corresponding part of the code (where n is number of rows of the matrix):

...
for (unsigned int rowStart = taskNumber; rowStart < n; ro...
...
...
for (...) {
...
for(...) {
...
}
...
}
...
}
\par
\end{lstlisting}">

It is important to create more tasks than the number of cores. Indeed, each task does not have the same computation time and in this case, we would have to wait for the longest tasks at the end of the function. Increasing the number of tasks will reduce the time we have to wait because the tasks are shorter.

Our algorithm

After having parallelized the two dimensions Kadane algorithm, we started to work on the algorithm itself.
First we had the idea to create a new one-dimension array (called maxSumStartingAtRow) which contained for each index i an upper bound on the maximal sum you can obtained for a sub-matrix starting from i to the end of the original matrix.

We used the maxSumStartingAtRow array to break the second for loop if the current maximal sum found in the current task was already bigger than the upper bound on the maximal sum (lines 9 to 12 in figure 2).

**Figure 2:**
Part of our Kadane algorithm.
... break; } ... for(...){ ... } ... } ... } \end{lstlisting} \end{figure}">

For the generation of maxSumStartingAtRow, we first did a preprocessing operation which was parallelized. This operation started from the bottom of the matrix, and computed some one-dimension Kadane and added the value from the bottom to the top of maxSumStartingAtRow as illustrated in figure 3.

**Figure 3:**
The maxSumStartingAtRow generation

With this solution, the problem was that maxSumStartingAtRow was a really bad estimation of the real maximum sum starting at a row. This is quite easy to understand with the example in figure 4.

**Figure 4:**
The problem with maxSumStartingAtRow

A solution we found was to compute at regular intervals some Kadane in two dimensions. Indeed, on huge arrays, this last algorithm is way more accurate. The two dimensions algorithm was used to decrease the difference between the real and the computed values in maxSumStartingAtRow.

The last problem we had was about the necessary time needed to compute this preprocessing operation. Even with this preprocessing, the solving time of the two dimensions algorithm was reduced, but on big arrays (10000 x 10000) the total time was only decreased by few seconds (due to a long preprocessing).

Finally, our last two dimensions algorithm does not use preprocessing. The trick is that the classical Kadane two dimensions algorithm spends its time computing sums from a row to an other. This allows us to use the solve part of our algorithm to fill the maxSumStartingAtRow (the following piece of code is placed on line 19 in figure 2):

...
if (!pruningOccured) {
...">

The maxSumStartingAtRow vector is initialized with the next line:

for (int i = 0; i < n; ++i) maxSumStartingAtRow[i] = LONG_MAX»2;
\end{lstlisting}">

As we use the maxSumStartingAtRow in an addition, we want to avoid overflow. This is the reason why we divide by 4 the LONG_MAX value.

Finally, we add a variable bestSoFar shared by all threads to indicate the best value found so far by all achieved tasks. This value is used to initialized the sum variable (line 2 in figure 2. We replace sum = 0 by sum = bestSoFar) to cut part of the matrix based on the best values found on other tasks.

Note that having more tasks than available cores is important for our pruning method too. Because threads can communicate more often partial results to others and in doing so they help each other to prune some part of the computation.

To conclude, the complexity of our Kadane algorithm is still in O(n² x m), but due to the cut we use in the second for loop, most of the time, we can improve the speed of the resolution.

The final algorithm

The final part of the algorithm is realy simple, the method is in the MaxSubArrayPb class static void computeMaxSubArray(char* fileName).
It only uses the different functions we wrote. Here are the different tasks executed by the algorithm:

Load the file:

This just load the file into main memory.

Get the matrix size:

Here, the only goal is to get the dimensions of the input matrix and to fill a vector with the addresses of all the lines.

Find the good orientation:

As explained before, our algorithm is way more efficient with some particular arrangments of the initial matrix.

Generate the vector :

This operation turn the input file into a C++ two dimensions vector.

Launch the good algorithm :

Regarding the number of rows of the input vector, we choose to launch the one dimension Kadane
algorithm or our two dimensions algorithm.

Reverse the result if necessary :

If the third step reversed the matrix, we need to rotate the result to have the good output coordinates.

Print the result :

Probably no need of explanation here .

The main function, in the main.cpp file, only calls the computeMaxSubArray method on each files passed as parameters.
It also defines the number of threads the algorithms have to use.
As it is really short, here is the code :

int main(int argc, char* argv[]){
if(argc < 3){
cout«''Par...
...){
MaxSubArrayPb::computeMaxSubArray(argv[i]);
}
return 0;
}
\end{lstlisting}">

Conclusion

This constest was really interesting in a lot of different aspects. First of all, it involved team work between teacher and students wich was really rewarding.
We all learned a lot of thing on a topic we didn't know well.
As computers have more more and more cores, this kind of computation is probably going to become a very important issue in the futur application devloppment.
This contest was the occasion to discover existing technologies. It was also the occasion to pratice on a 40 cores computer, a thing that is not possible every day.
The topic of the contest, the maximum subarray problem, was an interesting problem to try to parallelize.
It was quite simple to understand and it allowed us to use multiple ways to parallelize our program.

The available resources, put at our disposal by Intel were adapted to beginners in the parallel computing learning. We enjoyed learning by watching the video tutorial.

To conclude, it was a real rich experience and we want to thank Intel for the organization of this contest.

Finally, you can download our full packages.

The first one, MTL_package.zip contains the files we sent for the contest. The makefile is adapted for the MTL.
The second one, Normal_package.zip, should run on your personnal computer. You just need to have g++ 4.5.1 or later installed on your PC.

MTL_package.zip
Normal_package.zip

In both zip files, you will find the same explanations in the detailled_explannations.pdf file. You will also have access to the doxygen documentation.

We hope you enjoyed reading this article.

Subarray Problem - A static NUMA-Aware approach

krahnack — Thu, 24 Nov 2011 12:19:44 +0000

The subarray problem on a n*m matrix is sequentially solved using an algorithm known as the Kadane 2D algorithm. This algorithm has a O(n²m) complexity. The sequential algorithm is written using 3 loops :

         for i in (0..n)   // <- We parallelize that
		 for j in (i..n)
			 for k in (0..m)
			    //do work with matrix[j][k]

Our solution does not try to optimize the work performed inside the inner loop, so we skip the details of what is actually done inside. We chose to parallelize only the outer loop (index i).

In order to parallelize the outer loop on K cores, we chose to split it into K tasks of equal duration. This approach has several advantages :

The algorithm is very simple : there is no need to steal work or do complex load balancing between the K cores.
Each thread works on big continuous portions of the matrix, which maximizes cache usage.
We know in advance what the threads are going to do and which data are going to be accessed so we can do smart NUMA optimizations.

In this article, we explain: how we achieved to split the work into K equal tasks and how we optimized the treatment of these tasks.

1-Creating K tasks of equal duration

Fig. 1 - K=4 equal areas in a triangle

In order to split a for i (0..n) loop into K tasks, one often create K tasks [i=0..n/K],[i=n/K..2*n/K]...[i=(K-1)*n/K,K]. However, this simple solution does not work well in our case because the second loop (index j) starts at index i. This means that when i==0, n iterations are done in the second loop and when i==n-1 only 1 iteration is done in the second loop! The amount of work depending on i is represented in Figure 1. This figure represents an example of the work to be done on a 250*m matrix. When i==0, 250 iterations are done; when i==250, only 1 iteration is done. The total quantity of work to be done is equal to the area of the triangle.

Splitting the work into K equal tasks is equivalent to creating K equal areas inside the above mentioned triangle.

For example, in Figure 1, representing the work to be done on a 250*m matrix, a close-to-optimal partionning is the following :

Thread 0 doing i (0-34) = 7939 j iterations (area A1)
Thread 1 doing i (34-74) = 7875 j iterations (area A2)
Thread 2 doing i (74-125) = 7860 j iterations (area A3)
Thread 3 doing i (125-250) = 7701 j iterations (area A4)

With this partionning, there is at most a 3% difference in the number of iterations performed by each thread.

In order to find the last index that a thread idx should process (e.g., 34 for thread 0 in the above example), we use the following formula:

    int last_index = 0;
    do {
	    last_index++;
    } while((last_index)*(n) - (last_index+1)*(last_index)/2 < (idx+1) * n * (n - 1) / 2 / K);

Where n in the number of lines of the matrix, idx is the thread number and K the number of threads.

This loop increments last_index until the amount of work done between i=0 and i=last_index is equal to idx*(total-work-to-be-done/number-of-workers). The calculation of "the amount of work done" is the calculation of the area of a trapeze. (E.g., on figure 1 the area A1, the work done by thread 0, represents the area of a trapeze.)

Actually this could also be calculated with the following formula:

    last_index = 2*n - (√(4*n*n-4*n+1)*K*K+((-4*idx-4)*n*n+(4*idx+4)*n)*K+(2*n-1)*K)/(2*K);

... but is is actually slower than doing the loop! (We think that the compiler is doing really smart things and that the loop is actually optimized and transformed into a much more efficient formula.)

2-NUMA optimizations

As mentioned earlier, we also do NUMA optimizations. In order to improve the locality of the memory accessed by the threads, we have:

Created a thread pool per NUMA node in the system. Each thread pool is totally independent from the others. Each thread pool is controlled by a master thread scheduled on the same NUMA node as the pool it controls.
The creation of the K tasks is done in parallel by each master thread (actually each thread creates K/4 tasks since there is 4 NUMA nodes on the MTL).
Before giving the tasks to its workers, each master thread duplicates the matrix on the local NUMA node. This ensures that, when the matrix does not fit in cache, the worker threads fetch data from their local memory. This optimization actually give a +25% performance boost at 40 cores. Lessons learned: pay attention to the data locality.
(Note for those who might think that it is an incredible waste of memory: a 10K*10K matrix occupies 380MB in RAM. The MTL machines has 64GB. So one copy per node = a "waste" of 1.5GB = 2.3% of the memory of the machine = really negligible compared to the gain.)

3-Other performance optimizations

Our approach falls back on the sequential algorithm when the parallel algorithm is considered too costly. (E.g. the cost of duplicating the matrix and managing the thread pool cannot be amortized.)
Since the subarray algorithm is of O(n²m) complexity, it is sometimes worth to transpose the matrix before any computation, in order to have n
Both reading and transposing the matrix are done in parallel using our thread pool. The input file is mapped in memory and each reader thread is responsible to parse 800Ko of the input file and creates a partial matrix corresponding to what it has read. All submatrices are then merged using a simple memcpy operation.

4-Figure for nerds

Time to present some results!

Fig 2 - Speedup of our algorithm on a 10K*10K matrix
The algorithm has an near optimal speedup between 10 and 40 cores (x3.94) and between 1 and 40 cores (x36.8). This means that, according to Amdhal's law, more than 99.77% of our code is parallel. For those interested, it takes 5.9s at 40 cores to parse a 10K*10K matrix.
We think that the speedup seen by the Intel team might have been a little lower due to our static partitionning of data: on the final test 2 cores were fully loaded, which means that our partionning was no longer optimal. Nevertheless our solution seems to have behaved quite nicely even when (intuitively) load balancing could have been required.

5-Code

Finally, here's a link to our code

Acceler8 est fini, quelle expérience !

farcellier — Mon, 01 Aug 2011 08:30:47 +0000

Mardi matin, quelle surprise agréable de réceptionner les récompenses du concours acceler8.
Ils venaient d'être expédiés la veille.

Après 2 mois de travail intensif, c'est donc une page qui se tourne. Le concours acceler8 est bien fini. Ce fut un évènement intense et enrichissant. Nous ne pensions pas quand nous nous sommes lancés dans l'aventure que celle-ci nous mènerait si loin.

Le parallélisme est aujourd'hui sur toutes les lèvres. Cependant, nous nous attendions pas à découvrir un univers aussi
riche. Le premier problème sous son apparente simplicité s'est révélé bien plus corsé et pimenté que nous ne l'attendions. Jusqu'à la dernière demi heure, nous n'avons cessé d'y réfléchir et de chercher à améliorer le temps d'exécution de notre programme.

Le second, plus difficile, nous a fait transpiré plus d'une fois. L'expérience du premier s'est révélé formatrice et c'est après un travail de longues haleines que nous sommes parvenus à fournir un programme efficace.

Ces 2 netbooks ne sont pas seulement une récompense. C'est un rappel des efforts que nous avons fourni pour s'améliorer en permanence. C'est aussi un rappel des efforts qu'ils nous restent encore à fournir pour nous améliorer.

En nous conviant à ce voyage sur le chemin du parallélisme, Intel nous a permis de faire un bout de chemin dans ce domaine. Tout au long de ce défi, ils nous ont guidé sur cette voie. Le partage que ce soit avec les organisateurs ou avec les autres concurrents a rendu cette expérience unique.

J'espère que d'autres défis sur des domaines aussi pointus seront organisés avec la même passion et la même volonté de permettre à
des étudiants de découvrir des domaines parfois laissés en marge des programmes scolaires.

Fabien

La description des nouvelles instructions de Haswell

AnthonyC — Mon, 20 Jun 2011 13:00:10 +0000

Intel vient de rendre publique les détails sur la prochaine génération des architectures X86. Arrivant en premier dans nos microarchitectures Intel en 2013 sous le nom de code "Haswell", les nouvelles instructions accèlerent une large catégorie d'applications et de modèles d'usage. Téléchargez la référence de programmation Intel® Advanced Vector Extensions Programming (319433-011).

Cette build viendra sur les instrutions dans l'architecture Ivy Bridge, incluant le générateur digital de nombre aléatoire, les accelerateurs float16, et étend les extensions de l'Intel Advanced Vector ( Intel AVX) qu'Intel a lancé en 2011.

Ces instructions pourront se partager dans les deux catégories suivantes :

AVX2 -Les types de donnés Entier étendus à 256-bit SIMD. Le support des entiers AVX2’s est particulièrement utile pour traiter les données visuelles généralement rencontrées dans l'imagerie et dans le traitement de vidéos pour les particulier. Avec Haswell, nous avons l'Intel® Advanced Vector Extensions (Intel® AVX) pour virgules flottantes, et aussi AVX2 pour les type de données Entier.

Les instructions de manipulations de Bit sont très utiles pour les base de données compressées, le hashing, l'arithmetic des grands nombres, mais aussi une large varieté de code à utilisation plutôt générale.

Regroupement des codes de vectorisation avec des éléments de données non-adjacents.
Les rassemblements de Haswell sont masqués pour la sécurité ( comme les charges conditionnelles et les stockages introduits dans Intel AVX ) , ce qui favorise leur utilisation dans des codes avec coupures ou d'autres conditionnelles.

Any-to-Any permutes – Des opérations de Shuffling incroyablement utiles. Haswell ajoute le support pour la granularité DWORD et QWORD dans un registre entier de 256-bit.

Vector-Vector Shifts:Nous avons ajouté des déplacements avec le contrôle du déplacement vectoriel. Ils sont critiques dans la vectorisation de boucle avec déplacement variables.

Floating Point Multiply Accumulate – Cette fonction améliore de manière significative les pics de flops et fournit une précision accrue pour l'amélioration de l'usage des mathématiques transcendantes. Elles sont très largement utilisées dans le monde du calcul intensif, dans l'imagerie professionnelle, mais aussi dans la reconnaissance faciale. Ils opèrent sur des , 128-bit packed simple et double précision de type scalar, mais aussi sur des 256-bit packed single et double précision du même type. [Ces instructions ont été décrites précedemment, dans les spécifications initiales de l'Intel AVX.].

Les inscructions vectorisées basées sur l'état de registre étendue ( 256-bit) ajouté dans Intel AVX sont supportées par tous les systèmes qui supportent l'Intel AVX.
Pour les développeurs, il est intéressant de noter que les instructions couvrent plusieurs feuilles CPUID. Vous devriez être prudent de vérifier toutes les bits applicables avant d'utiliser ces instructions.
Veuillez lire les spécifications et restez en ligne pour les outils de support pendant les prochains mois..

Mark Buxton
Software Engineer
Intel Corporation

( Ceci est la version traduite de l'article originale qui se trouve ici : http://software.intel.com/en-us/blogs/2011/06/13/haswell-new-instruction-descriptions-now-available/ )

Devenez l'ambassadeur de la marque Intel

Anthony Charbonnier (Intel) — Mon, 23 May 2011 09:46:41 +0000

Devenez l’ambassadrice ou l’ambassadeur de la marque Intel !

Nous recherchons plusieurs personnes pour l’animation du tout nouveau showroom Intel, qui ouvrira prochainement au sein d’un grand magasin parisien.

Vous aimez les innovations et êtes passioné(e) de nouvelles technologies ?

Alors inscrivez-vous au casting en envoyant CV et photos à chloe.janvier@pwpassociates.com. Nous vous répondrons dans les plus brefs délais !

Voir plus d"infos ici

Meilleures questions autour de la programmation parallèle

Anthony Charbonnier (Intel) — Tue, 19 Apr 2011 11:18:25 +0000

Bonjour à vous

Grâce au concours de programmation parallèle, de nombreux threads très intéressants sont apparus sur le forum.
Je vais m'efforcer de vous les lister pour les trouver plus rapidement .

VinceRev écrit son avis et ses méthodes sur l'accès au cache et l'architecture des processeurs.
voir le forum accès au cache et architecture des processeurs

Shaolan a ouvert un thread sur la découverte d'OpenMP , très intéressant à lire.

Encore Shaolan, pour cette fois une réflexion sur l'optimisation de la programmation

Et enfin, VinceRev nous offre un très bel article sur le temps d'execution des programmes au niveau du cache .

Ce post sera mis à jour avec les meilleures contributions au fur et à mesure que nos utilisateurs garniront le forum !

Analyseur de performances Intel

AnthonyC — Fri, 07 Jan 2011 15:33:52 +0000

Gagnez des nouveaux cients et préparez vos logiciels pour les ordinateurs portables de plus en plus utilisés par les joueurs nomades. Les suites de logiciel d'Analyseurs de Performance Graphique Intel® (Graphics Performance Analyzers/ Intel® GPA ) fournissent des anlyses en profondeur pour vous aider à optimiser au mieux vos jeux basés sur les API Microsoft DirectX* et sur les ordinateurs équipés des cartes Intel® HD Graphics. Utilisez les analyseurs graphiques de performance pour porter vos applications sur de nouveaux environnements ou encore pour développer des logiciels innovants pour le futur du jeu mobile.

Support des Microarchitecture Intel® Core™ et Intel® HD Graphics . Utilisez un outil conçu spécifiquement pour analyser et optimiser les jeux pour les dernières plateformes à savoir les processeurs Intel® Core™ avec des Intel® HD Graphics
Analyse en profondeur et en temps réel. Idenfitiez les facteurs limitants, essayez des solutions , et voyez les résultats en temps réel.
Profil de plateforme. Visualisez les performances de vos jeux sur les CPU et GPU pour vous assurer de tirer parti au maximum de la puissance de calcul disponible.
Interfance intuitive. Accèdez à une suite complète d'outils depuis une interfance très simple d'utilisation hautement configurable.
Librairies ouvertes et programmables. Adaptez les outils à vos propres besoins.

Ciblez de nouveaux clients

Développez votre base de clients en vous assurant que vos applications sont optimisés pour les millions de PCs équipés avec l'Intel HD Graphics. Préparez vous pour un monde mobile croissant de manière exponentiel en optimisant vos logiciels pour les ordinateurs basés sur la technologie Intel.

Accèdez à une suite d'outils complète

Les analyseurs de performances graphiques d'Intel proposent une suite complète d'outils pour une analyse en prodonfeur des problèmes de performances. Ces outils sont développés pour travailler à votre manière, pour pouvoir utiliser immédiatement les outils proposés de la meilleure des façon.

Téléchargez le brief complet de la suite

Intel® Graphics Performance Analyzers: Game Development for a Mobile World [PDF 204KB]