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

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.

And here are the timings of the whole algorithm:

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:)).

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

Maximum Subarray Problem Parallelization using PThreads

Catalin Ionut Fratila, Vlad-Marian Spoiala

University Politehnica of Bucharest

Faculty of Automatic Control and Computers, Computer Science Department

The algorithm we used for solving the maximum subarray problem was Kadane's 2D algorithm. A implementation of the algorithm is presented here: http://alexeigor.wikidot.com/kadane.

Our implementation was done in C. Parallelization was done using PThreads. We started to develop solutions in both TBB and PThreads, but decided to proceed with the PThreads because we obtained better results.

We used Intel's icc compiler for generating the executable. Using the icc compiler gave us a 3-5% performance improvement over the same code compiled using gcc. Other compilers were not tested.

Profiling was done locally using the Linux command line utility perf and Intel VTune. Perf was used to obtain raw profiling data that was of interest (number of cache misses, number of cycles etc.), while VTune was used for obtaining more complex profiling data like hotspots or concurrency information.

Parsing the input

Our first attempt attempt at reading the numbers was done using fscanf. Better results were obtained by giving up using fscanf and instead using strtok. In our final version we gave up using strtok and decided to parse the line by hand. We implemented a minimal and fast, but unsafe version of the atoi function. Our final version of the read function was 2-3 times faster than using fscanf to get the numbers from the line. VTune's hotspots analysis was used here to determine where most of the time is spent in the read function.

If our initial estimation of the total number of lines is smaller than the actual number of lines we reallocate the memory area reserved for storing the matrix.

We did not attempt to parallelize the read function.

Parallelization

Each thread will compute a partial result for the iterations it was assigned. This partial result is composed of the maximum subarray sum value and the coressponding coordinates in the original matrix. The master thread goes through the partial results and selects the one with the maximum value for the subarray sum.

When running on the MTL each thread is forced to run on a certain core using the pthread_setaffinity_np function. Although this improves speedup significantly when using a large number of cores on the MTL, using this function on other machines caused a decrease of performance. Because of this its use is restricted to running our code on the MTL.

The threads are joined using a semaphore when the workload is completed: the main thread does NT waits on the semaphore, while each thread that finishes its workload (including the main thread) does a post operation on the semaphore. This was used to prevent serialization overhead from calling pthread_join for each thread from the main thread.

Other optimizations

The matrix is stored as a contiguous chunk of memory. This improves data locality.

The three loops are optimized by reducing the number of operations needed to do memory accesses. We use 3 pointers to access the numbers in the matrix: 2 are increased in a sequential manner (we add 1 to the address) while the third is increase in a non-sequential (we add N to the address, where N is the number of columns).

Results

Code

The code can be downloaded here: solution
Password for the archive is "secret"

Acceler8 contest

Andreolli Cédric - Garcia Pascal - Templé Arthur

Date: October 15th 2011 - November 15th 2011

Abstract:

Introduction

The maximum subarray problem

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

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

Reading the files

Problems encountered

But actually, the line:





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

Getting the matrix dimensions

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

Parsing the file

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

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

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.

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

The maxSumStartingAtRow vector is initialized with the next line:





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 .

Conclusion

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.

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

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.

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

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<m. Experiments showed that transposing becomes worthy as soon as the difference in complexity is above 5K operations.
• 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

]]> http://software.intel.com/fr-fr/blogs/2011/11/24/subarray-problem-a-static-numa-aware-approach/feed/ 0 http://software.intel.com/fr-fr/blogs/2011/11/22/mthodes-de-lire-un-fichier-dentre/ http://software.intel.com/fr-fr/blogs/2011/11/22/mthodes-de-lire-un-fichier-dentre/#comments Tue, 22 Nov 2011 11:10:47 +0000 wtx2338 http://software.intel.com/fr-fr/blogs/2011/11/22/mthodes-de-lire-un-fichier-dentre/ Ce test est basé sur des articles sur internet. Le but de ce test est de trouver une façon de lire des entiers à partir d'un fichier le plus vite possible, c'est un travail qu'on doit fait au début de notre programme du concours. Nous avons fait des test et voilà leur résultat.

La premier réflexion qu'on a fait est de utiliser cin et cout dans std, nous savons cette façon n'est pas le plus vite mais nous ne savons pas sa vitesse. Nous avons fait un tes avec 10000000 entier, (et tous les autres test est sur ces 10000000 aussi )le code est très simple:


std::cin>>data[i]

Le résultat est très mauvais, oui très mauvais:

time ./t1
real 0m5.615s
user 0m5.544s
sys 0m0.068s

On a quand même utilisé 5-6 seconde pour lire un fichier, de plus dans notre programme cette partie est une partie ne peut pas être parallélisée, donc en cherchant des méthode sur internet, nous avons commencé un autre test.
La deuxième méthode est de utiliser scanf, on dit que c'est beaucoup plus vite que cin, nous avons juste changé une ligne de code:


for (i;i<MAXN;i++)
scanf("%d",&data[i]);


Le résultat est vraiment beaucoup mieux cette fois ci:

time ./t2
real 0m1.909s
user 0m1.844s
sys 0m0.060s

En fait, cin est super lente parce que chaque fois il fait des synchronisation avec stdin, une personne a dit sur internet qu'on peut aussi fermer cette synchronisation avec cette ligne de code là:

std::ios::sync_with_stdio(false).

Comme cela, cin peut avoir même vitesse que scanf.

Nous pensons qu'on peut encore mieux faire, les deux méthode est lente peut être à cause de la vérification du type, donc nous avons fait une méthode de fgetc qui va lire caractère par caractère d'un flux :


FILE *fd=freopen("input.txt","rb",stdin);
int i=0;
int j=0;
char p;
while(!feof(fd)){
p=fgetc(fd);
if (p == ' ') i++;
if(p=='\n') j++;
}

Ce méthode de là peut aussi indiquer le nombre du ligne et du colonne, et le résultat est mieux que les deux premiers:

time ./t3
real 0m1.412s
user 0m1.376s
sys 0m0.032s

Après nous avons trouvé une méthode sur internet qui a utilisé fread, cette méthode-là peut être encore plus vite:


FILE *fd=fopen("input.txt","r");
int len = fread(buf,1,MAXS,fd);
buf[len] = '';
int i;
numbers[i=0]=0;
for (char *p=buf;*p && p-buf<len;p++){
if (*p == ' '){
numbers[++i]=0;}
else{
numbers[i] = numbers[i] * 10 + *p - '0';}
}

Le principe est de lire tout fichier dans le mémoire et de travailler sur le mémoire après, et le résultat est beaucoup mieux qu'avant:

time ./t2
real 0m0.288s
user 0m0.184s
sys 0m0.108s

Cette méthode est 10 fois plus vite que celle de scanf et 5 fois plus vite que celle de fgetc, enfin nous avons utilisé celle-ci pour notre programme.

]]> http://software.intel.com/fr-fr/blogs/2011/11/22/mthodes-de-lire-un-fichier-dentre/feed/ 0 http://software.intel.com/fr-fr/blogs/2011/11/22/introduction-aux-ranges-des-tbb/ http://software.intel.com/fr-fr/blogs/2011/11/22/introduction-aux-ranges-des-tbb/#comments Tue, 22 Nov 2011 11:10:28 +0000 megra http://software.intel.com/fr-fr/blogs/2011/11/22/introduction-aux-ranges-des-tbb/ 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.

]]> http://software.intel.com/fr-fr/blogs/2011/11/22/introduction-aux-ranges-des-tbb/feed/ 0 http://software.intel.com/fr-fr/blogs/2011/08/01/acceler8-est-fini-quelle-exprience/ http://software.intel.com/fr-fr/blogs/2011/08/01/acceler8-est-fini-quelle-exprience/#comments Mon, 01 Aug 2011 08:30:47 +0000 farcellier http://software.intel.com/fr-fr/blogs/2011/08/01/acceler8-est-fini-quelle-exprience/ 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

]]> http://software.intel.com/fr-fr/blogs/2011/08/01/acceler8-est-fini-quelle-exprience/feed/ 0