Intel® Software Network (FR) » programmation parallèle

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

Retour d'expérience concours Acceler'8

rimaxime — Wed, 01 Feb 2012 16:53:41 +0000

La nouvelle édition du concours acceler'8 a pris fin il y'a un peu plus d'un mois. Contrairement au concours précédent, nous n'avons pas publié d'article.

Il faudrait que nous le fassions à l'occasion. C'etait une part intéressante du concours précédent.

Les contraintes de la vie courante reprennent vite leur place. Il m'a fallu un peu de temps pour me décider d'écrire ce message.

Une petite photo du disque SSD gagné

Cet édition a été un événement intense. Contrairement à l'édition précédente, nous avons dû travailler sur un problème reconnu.
Un gros travail de recherche à effectuer. Ce fut loin d'être facile, mais au combien passionnant.

Nous sommes partis finalement sur une simple implémentation de l'algorithme de Kadan 2D pour rechercher les coordonnées du tableau maximum à l'intérieur d'un tableau contenant des valeurs négatives et positives.

Cette fois ci, nous ne découvrions plus la programmation parallèle. Nous avons décidé de nous lancer dans le C++ et d'exploiter la librairie Intel Threading Block.

Nous avons à première vue était agréablement surpris. Nous avions trouvé dans cette librairie un excellent compromis entre la puissance et la souplesse de configuration des threads.
Ce concours fut vraiment l'occasion de découvrir ce produit. Je ne saurai que en recommander l'usage.

Nous avons commis une erreur. Mon binome a perdu pratiquement un week end à chercher à améliorer les performances d'une section de code qui en faite répondait totalement à nos exigences.

Au final, le goulet d'étranglement de notre application se trouvait à la lecture du fichier.

Nous nous sommes rendus compte de ça, trop tard malheureusement, grace à l'outil Intel Vtune. Nous avons découvert trop tard que nous pouvions l'utiliser sur la MTL.
Donc un simple regret, ne pas avoir eu accès à cet outil plus facilement. Même sur la MTL, c'etait délicat et relativement fastidieux de l'utiliser.

Intel Vtune

Donc au cours de cette édition, nous avons découvert l'écosystème proposé par Intel que nous ne connaissions que de nom. La dernière fois, la découverte de la programmation parallèle avait pris tout notre temps.
Face au problème que nous avons rencontré,c'est certain que avec ces outils, nous l'aurions facilement contourné. Ils sont beaucoup plus simples à utiliser que je le pensais à l'origine. Au final, quelques clics et nous avions la vue complète de l'exécution de notre application. J'imagine vraiment l'intéret pour l'optimisation de systèmes plus complexes.

Je profite de ce poste pour soumettre une idée pour la prochaine edition.
Nous aurions aimé disposer d'une machine virtuelle avec tous les outils d'Intel installés pour la durée du concours. Ca nous aurait simplifié la vie et poussé à les découvrir.
Je suis certain qu'il nous reste encore beaucoup à en apprendre.

Nous avons beaucoup apprécié l'ouverture à l'international. Ca donnait une dimension et un enjeu différent.
C'etait impressionnant la communauté de développeurs qui a été rassemblés et l'engouement sur les forums anglais.
Nous avons également beaucoup apprécié l'entraide qui reignait et le partage (notamment les generateurs de matrice). C'est grace à certaines de ces contributions que nous avons réussi à utiliser Intel Vtune, sinon nous serions totalement passés à coté.

Cette fois ci, avec un code non optimisé pour la lecture du fichier, nous avons terminé 23 ème.
Même si c'est honorable, il ne nous reste plus qu'à mieux faire lors de la prochaine édition.

Maximum Subarray Problem - Simple Parallelization and Optimizations

neshone — Thu, 22 Dec 2011 13:26:53 +0000

University of Novi Sad

Faculty of Technical Sciences, Department of Computing and Control

authors: Predrag Ilkic, Nenad Jovanovic

Date: October 15th 2011 - November 15th 2011

Introduction:

This article is an explanation of our method for solving the maximumim subarray problem during the Intel Acceler8 contest. The team consisted of one fourth year university student and one fourth grade high school student.

The problem was the following: in the given matrix, find the subarray (corner coordinates) that has the maximum sum of elements. The algorithm used for the solution was the well-known Kadane's algorithm adapted for two-dimensional
arrays. We started the project using the OpenMP, but at one point we switched to pthreads because we got much better results. The algorithm wasn't too complex for implementation so the transition went quite smoothly. The only downside of
pthread solution was that we switched to it much too late so we never had the time to try out some of our ideas that failed with OpenMP. The compiler used was gcc, no other compilers were tested.

1 - matrix parsing

Matrix parsing and loading was done sequentially. While in the OpenMP phase of the project, we tried to parallelize the matrix parsing and loading, but without success. The results were pretty much the same at best, so the solution
was dropped. No parsing parallelization was attempted with pthreads due to the lack of time.

Matrix parsing was done using tha standard fread() function. One chunk at the time was loaded into memory. It was parsed, firstly, by counting all of the spaces to get the column count and then by counting the linebreaks to get the
row count. After acquiring the matrix size, we allocated the appropriate amount of memory. The matrix was then loaded into memory in an appropriate way depending on the number of rows and columns (whether or not rows>columns -
this effects the complexity of the solution which is calculated O(rows*rows*columns)). This enabled us not to waste time on matrix transposing later. The loading was done using our own integer reading. We found it much
faster compared to standard fscanf(). The matrix from the file itself was never actually loaded into memory. We just used the integers read to generate the prefix sum matrix. Only the prefix sum matrix was processed in this
solution.

2 - parallelization and optimizations

The whole parallelization process was done in OpenMP and later literally translated to pthreads. Since the Kadane algorithm consists of three nested for loops, the parallelization was done on the outer most for loop to decrease
overhead and increase data locality and cache hit rate. All interations in the outer loop are completely independant so parallelizing the algorithm in this way enables great scalability. Every iteration is picked up for processing by one of
the worker threads. Every iteration is processed one by one until all iterations are processed. We tried different types of scheduling with OpenMP. Static scheduling was the least effective and dynamic and guided scheduling gave very
similar results so we preoceeded with dynamic scheduling which has just been explained. After the transition to pthreads, dynamic scheduling was kept and no other scheduling types were tried due to before mentioned lack of time. Every
worker thread collects it's own results from which is later picked the final result. This was done to eliminate any thread synchronization that might slow down performance.

3 - results

For starters, here are some matrix parsing and loading timings:

matrix size	timing
1000x1000	39.35 ms
2000x2000	153.2 ms
5000x5000	984.52 ms
8000x8000	2466.63 ms

And here are the timings of the whole algorithm:

matrix size	number of cores	timing
1000x1000	1	1.523 s
	8	0.223 s
	16	0.132 s
	24	0.104 s
	32	0.089 s
	40	0.082 s
2000x2000	1	12.093 s
	8	1.683 s
	16	0.891 s
	24	0.646 s
	32	0.525 s
	40	0.465 s
5000x5000	20	11.886 s
	30	7.584 s
	40	6.041 s
8000x8000	20	52.050
	30	34.685
	40	26.234

No fancy graphs or pictures

4 - conclusion

As the results show, for smaller matrices, speed up drops greatly because of the large part of execution that the sequential part of the code takes. As the matrix gets larger, the speed up grows to almost linear.

The code, makefile and the readme file from the contest are attached. The password for the archive is "secret". We tried to make the code well commented, so it should be easy to understand. You can download all of it here.

For the end, we'd like to say that the contest was a pleasure, a great experience and a great chance to learn something new and useful as well as try it out properly(40 core MTL was great:)).

Maximum Subarray Problem using TBB and Pipelines

ph0b — Fri, 16 Dec 2011 10:01:17 +0000

Algorithm

Kadane 2d's classic algorithm has a complexity of O(r²c), where r is the number of rows and c the number of cols.

We use it when there is more columns than rows, but instead of tranposing the matrix for the opposite case, we developed a second algorithm that is O(c²r). It's basically a transposition of Kadane 2d's algorithm :

      for(size_t colStartIndex=0; colStartIndex!=numberOfCols; ++colStartIndex)
         for(size_t rowIndex=0;rowIndex!=numberOfRows;++rowIndex)
            for (size_t colEndIndex = colStartIndex; colEndIndex!=numberOfCols; ++colEndIndex)
                    // do one step of kadane's 1D maximum subarray search (one step for one row)
		    // a kadane's 1D search is associated to a (colStartIndex, colEndIndex) pair

The position of the loop on rows is carefully choosen. It's not the most innerloop because we would have very bad cache locality, and it can't be parallelized so we didn't put it as the most outer loop.

Pipelining

We assumed that reading the file was a really slow and sequential process, and our work is based on that assumption. The other teams have proven that it wasn't true - on the MTL at least.

Our goal was to start searching the maximum subarray before the file was entirely read. We modified our algorithm's implementations to work on slices of matrix, in order, coming from the pipeline.

The pipeline serially read slices of the input file, then each slice is parsed in parallel, and sent to the search.

We choosed to work on slices of files of a size inferior to the L3 cache and used circular buffers to avoid memory reallocation.

The O(c²r) algorithm doesn't need to remember the previous slice of matrix to work : only two values, indexed by colStartIndex and colEndIndex, are needed for continuing the kadane 1d search. So the memory footprint is independant on the number of rows.

Here is the pipeline definition for the O(c²r) implementation :

    tbb::parallel_pipeline(
            ntoken,
            tbb::make_filter(
                tbb::filter::serial_in_order,
                InputFileReader(file, textSlices, ntoken)
            ) // read a chunk of the file (n-rows)
            &
            tbb::make_filter(
                tbb::filter::parallel,
                TextLinesToArray(matrixes, /*prefixedSum=*/true)
            ) 	// parse this chunk to fill corresponding matrix
		// with a prefixedSum done on each line
            &
            tbb::make_filter(
                tbb::filter::serial_in_order,
                MaximumSubarraySearchCCRStep(&kadaneSavedResults, &numberOfRows, &result)
            )
        ); // add the matrix to the search

Parallelization

We already parallelized the parsing of the matrix using the pipeline. For the searching part, we used tbb::parallel_reduce() on the most outer loop (on colStartIndex for both algorithms). Given the triangle-balanced nature of the problem, we defined a specific tbb::range.
The length of this range is defined using it's length, then multiplied by it's position. The grainsize of the parallel_reduce is divided by the number of rows for the O(c²r) algorithms and by the number of cols for the other one. Splitting the range is done at the first 3rd instead of at the middle of the range.
This is a bit tricky, but a range should stay as simple as possible because its split function is used a really high number of times. Every of our tentatives to do smarter splitting involving a bit more calculation didn't succeed.
We didn't have the time to try to directly use parallel tasks instead of ranges and parallel_reduce. It might have much better performances, allowing a better task splitting with less overhead.

Our program scaled very well but there is much overhead that doesn't depend on the number of cores, these are some results we had on 40 :

1000x1000 : 1.64s user 0.06s system 2022% cpu 0.084 total
2000x2000 : 11.69s user 0.09s system 3138% cpu 0.375 total
4000x4000 : 108.18s user 0.25s system 3684% cpu 2.943 total
8000x8000 : 758.06s user 1.21s system 3865% cpu 19.642 total
10000x10000 : 1431.10s user 1.79s system 3895% cpu 36.781 total

The source code is here : maxSubarraySearch-TBB-Pipelines.zip

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

Introduction aux "Ranges" des TBB

megra — Tue, 22 Nov 2011 11:10:28 +0000

Bonjour à tous,

Je vais vous présenter une fonctionnalité de la bibliothèque TBB que j'ai eu l'occasion de découvrir durant le concours Acceler8.
Pour rappel, TBB qui est l'acronyme de "Threading Building Blocks" est une bibliothèque développée par Intel qui vise à faciliter le parallélisme.

Rappel sur les TBB

L'une des fonctionnalités très appréciée est le parallel_for, et ses dérivées tels que le parallel_reduce.
Ils permettent de paralléliser une boucle très facilement, voici un exemple de code qui parallélise une fonction d'affichage simple, qui pourrait être remplacée par un traitement long et coûteux.

Ainsi le code suivant affiche les entiers de 1 à 41 :
Code source brut.
Code source avec coloration syntaxique.

Peut être parallélisé ainsi :
Code source brut.
Code source avec coloration syntaxique.

L'ordre d'affichage est parallélisé, et donc, les nombres ne sont pas dans l'ordre.

Le "range" utilisé ici est le "tbb::blocked_range", qui permet de reproduire les itérations de la boucle. Il suffit de spécifier le "range" et la classe qui effectue le travail, le parallel_for fait tout le reste du travail. La simplicité d'écriture est vite perçue.

Enfin, il est important de noter que le type du range se retrouve dans la méthode de la classe qui surcharge l'opérateur ().

Rendre notre classe Compute plus modulaire

Avant d'aller plus, modifions notre classe Compute pour lui faire accepter un "range" de type différent plus facilement. Pour cela, rien de plus simple, il suffit de templater la classe, ce qui nous donne :
Code source brut.
Code source avec coloration syntaxique.

Avec ce template, il nous suffira de modifier les 2 lignes du main pour changer de "range".

L'utilité des ranges

Mais finalement, quelle est l'utilité des ranges ?
C'est simple, ils servent à découper votre problème en sous-problèmes, et permettent après découpage, de lancer les threads sur ces sous-problèmes.

Dans notre cas, nous voulons paralléliser une boucle, et le "tbb::blocked_range" est la méthode parfaite pour faire cela, il découpe l'intervalle demandé (de 1 à 42) en deux, et cela récursivement tant que jugé utile.

Bien sûr, pour des problèmes plus complexes, pour des problèmes entraînant des appels récursifs par exemple, vous ne pourrez pas utiliser bêtement le parallel_for, et il vous faudra chercher du côté de "ranges" ou des "tasks". Nous n'aborderons pas ici les tasks néanmoins.

Les méthodes à implémenter pour faire une classe "range"

En parcourant la documentation, on s'aperçoit que notre classe "range" n'a pas besoin d'hériter d'une classe abstraite, mais doit implémenter certaines méthodes :

Un constructeur par copie : R( const R& )
Un constructeur qui découpe le problème en deux : R( R& r, split )
Un destructeur : ~R()
Une méthode qui spécifie si on peut découper le "range" en deux : is_divisible
Une méthode qui spécifie si le "range" courant est vide ou non : empty

Définir son propre range

Ce qui nous donne le code suivant dans notre cas :
Code source brut.
Code source avec coloration syntaxique.

Les méthodes très importantes sont :

empty : permet de ne pas lancer de calcul sur une morceau vide du problème (après découpage, cela peut arriver).
is_divisible : cela permet de donner une taille minimale à un problème, et de s'assurer qu'il sera effectué par un seul thread. Cela évite le surcoût du lancement de trop de threads. Le paramètre "grain_size" est ainsi utilisé pour limiter s'assurer que le problème envoyé à un thread fait au minium 5 lignes (car pour 11 lignes, on découpe en 5 et 6 lignes).
do_split : qui est introduite dans le code mais n'est pas nécessaire, et qui se charge d'effectuer le découpage du problème en deux sous problèmes. C'est là que toute l'intelligence du découpage doit se faire.

Et en intégrant notre "range" personnalisé à notre code précédent cela donne :
Code source brut.
Code source avec coloration syntaxique.

Vous noterez que la liste d'initialisation du constructeur définit end avant begin, ce qui est impératif à cause du constructeur qui découpe un problème, et de la fonction "do_split", qui modifie "r.end_".

Remarques sur les performances

Le découpage en sous-problèmes peut être appelé un nombre conséquent de fois, il est donc important que la fonction de découpage ne soit pas trop longue à s'exécuter.
Pour l'anecdote, sur le concours Acceler8, en voulant découper un problème très équitablement, j'ai utilisé la fonction de calcul de racine carré (sqrt), qui a eu pour conséquence d’augmenter drastiquement le temps de calcul. Ce que je gagnais en répartissant plus équitablement le travail sur les cœurs de la machine, je le perdais en calcul de racine carré. Attention donc à ne pas vous faire avoir.

Conclusion

Vous avez vu ici un petit aperçu des "ranges" personnalisés, à vous d'adapter le code à vos besoin : ajouter des paramètres au constructeur, ainsi que découper intelligemment et efficacement.

Sources :

http://jfkbits.blogspot.com/2007/12/tbbs-parallelfor.html
http://threadingbuildingblocks.org/files/documentation/range_req.html
http://threadingbuildingblocks.org/files/documentation/a00266.html : il s'agit de l'implémentation du blocked_range. Cela reste une des meilleurs sources de documentation.

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/ )

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 !