Multitraitement.Piscine fait Numpy multiplication de matrice plus lent

Donc, je joue avec multiprocessing.Pool et Numpy, mais il semble que j'ai manqué quelque point. Pourquoi le pool version beaucoup plus lent? J'ai regardé htop et je peux voir à plusieurs procédés d'être créé, mais ils partagent tous un des Processeurs d'ajouter jusqu'à ~100%.

$ cat test_multi.py 
import numpy as np
from timeit import timeit
from multiprocessing import Pool


def mmul(matrix):
    for i in range(100):
        matrix = matrix * matrix
    return matrix

if __name__ == '__main__':
    matrices = []
    for i in range(4):
        matrices.append(np.random.random_integers(100, size=(1000, 1000)))

    pool = Pool(8)
    print timeit(lambda: map(mmul, matrices), number=20)
    print timeit(lambda: pool.map(mmul, matrices), number=20)

$ python test_multi.py 
16.0265390873
19.097837925

[mise à jour]

changé à timeit pour l'analyse comparative des processus de
init de la Piscine avec un certain nombre de mes cœurs
changé de calcul de sorte qu'il n'y a plus de calcul et de moins de transfert de mémoire (je l'espère)

Toujours pas de changement. pool version est encore plus lent et je peux voir dans htop qu'un seul core est utilisé également plusieurs processus sont générés.

[update2]

En ce moment je lis à propos de @Jan-Philip Gehrcke la suggestion d'utiliser multiprocessing.Process() et Queue. Mais en attendant, je voudrais savoir:

Pourquoi mon exemple, le travail pour tiago? Ce qui pourrait être la raison pour laquelle il ne fonctionne pas sur ma machineUn?
Est dans mon exemple de code toute copie entre les processus? J'ai prévu mon code afin de donner à chaque thread une matrice de la matrice, liste.
Est mon code est un mauvais exemple, parce que je utiliser Numpy?

J'ai appris que, souvent, l'on obtient une meilleure réponse, quand les autres savent mon objectif final est donc: j'ai beaucoup de fichiers, qui sont atm chargés et traités dans une série de la mode. Le traitement du CPU est intense, donc je suppose que beaucoup pourrait être acquise par la parallélisation. Mon but est d'appeler la fonction python qui analyse un fichier en parallèle. De plus, cette fonction est juste une interface pour le code en C, je suppose, cela fait une différence.

Un Ubuntu 12.04, Python 2.7.3, i7 860 @ 2.80 - s'il vous Plaît laissez un commentaire si vous avez besoin de plus d'infos.

[update3]

Voici les résultats de Stefano exemple de code. Pour une raison quelconque il n'y a pas de vitesse. :/

testing with 16 matrices
base  4.27
   1  5.07
   2  4.76
   4  4.71
   8  4.78
  16  4.79
testing with 32 matrices
base  8.82
   1 10.39
   2 10.58
   4 10.73
   8  9.46
  16  9.54
testing with 64 matrices
base 17.38
   1 19.34
   2 19.62
   4 19.59
   8 19.39
  16 19.34

[jour 4] réponse à Jan-Philip Gehrcke commentaire

Désolé que je n'ai pas fait moi-même plus clair. Comme je l'ai écrit dans la mise à Jour 2 mon principal but est de paralléliser plusieurs série d'appels d'un 3ème partie Python fonction de la bibliothèque. Cette fonction est une interface pour du code C. J'ai été recommandé d'utiliser Pool, mais cela n'a pas fonctionné, j'ai donc essayé quelque chose de simple, le montre l'exemple ci-dessus avec numpy. Mais là aussi, je ne pouvais pas obtenir une amélioration de la performance, même s'il semble pour moi", emberassing parallélisables`. Donc je suppose que je dois avoir manqué quelque chose d'important. Cette information est ce que je suis à la recherche de cette question et la générosité.

[jour 5]

Merci à tous pour votre formidable d'entrée. Mais à lire vos réponses ne crée plus de questions pour moi. Pour cette raison, je vais la lire sur le notions de base et en créer de nouveaux AFIN de questions quand j'ai une compréhension plus claire de ce que je ne sais pas.

Je suppose que les frais généraux de la création de processus de vous tuer ici. Essayez d'utiliser le timeit module ou au moins déplacer le pool = Pool() fonction de la chronologie de la routine.
J'ai peut-être tort, mais je soupçonne la plupart du temps est consacré à l'envoi de la matrices d'avant en arrière entre vos processus.
Mais on ne devrait pas tous les processus/threads de travail sur leur propre de la matrice? Comme chaque processus en prenant une matrice à partir de la liste de travail et avec qui?
Mais vous devez passer entre les différents processus (c'est à dire la copie de la mémoire). La multiplication de matrice est plutôt rapide (il faut environ 6 ms selon vos timings) de telle sorte que cette surcharge est importante.
J'ai changé l'exemple, afin qu'il n'y a plus de calcul et de moins de transfert de mémoire.

OriginalL'auteur Framester | 2013-03-14

16

Concernant le fait que l'ensemble de vos processus en cours d'exécution sur le même PROCESSEUR, voir ma réponse ici.

Lors de l'importation, numpy modifie l'affinité CPU du processus parent, de sorte que lorsque vous utilisez ensuite Pool tous les processus de travail qu'elle engendre sera à la fin en lice pour le même cœur, plutôt que d'utiliser tous les cœurs disponibles sur votre machine.

Vous pouvez appeler taskset après l'importation numpy pour réinitialiser l'affinité CPU de sorte que tous les cœurs sont utilisés:
```
import numpy as np
import os
from timeit import timeit
from multiprocessing import Pool


def mmul(matrix):
    for i in range(100):
        matrix = matrix * matrix
    return matrix

if __name__ == '__main__':

    matrices = []
    for i in range(4):
        matrices.append(np.random.random_integers(100, size=(1000, 1000)))

    print timeit(lambda: map(mmul, matrices), number=20)

    # after importing numpy, reset the CPU affinity of the parent process so
    # that it will use all cores
    os.system("taskset -p 0xff %d" % os.getpid())

    pool = Pool(8)
    print timeit(lambda: pool.map(mmul, matrices), number=20)
```
De sortie:
```
    $ python tmp.py                                     
    12.4765810966
    pid 29150's current affinity mask: 1
    pid 29150's new affinity mask: ff
    13.4136221409
```
Si vous regardez CPU useage à l'aide de top pendant que vous exécutez ce script, vous devriez le voir à l'aide de l'ensemble de vos cœurs lorsqu'il exécute le "parallèle". Comme d'autres l'ont souligné, dans votre exemple d'origine les frais généraux impliqués dans le décapage de données, de processus de création, etc. probablement l'emportent sur tout avantage possible de la parallélisation.

Edit: je soupçonne qu'une partie de la raison pour laquelle le processus unique semble être toujours plus rapide, c'est que numpy peut avoir quelques astuces pour accélérer cet élément-sage de la multiplication de matrice qu'il ne peut pas utiliser lorsque les tâches sont réparties entre plusieurs cœurs.

Par exemple, si je viens d'utiliser Python ordinaire des listes de calculer la suite de Fibonacci, je peux obtenir une énorme accélération de la parallélisation. De même, si je ne l'élément de sage multiplication d'une manière qui ne prend pas avantage de la vectorisation, je reçois un semblable speedup pour la version parallèle:
```
import numpy as np
import os
from timeit import timeit
from multiprocessing import Pool

def fib(dummy):
    n = [1,1]
    for ii in xrange(100000):
        n.append(n[-1]+n[-2])

def silly_mult(matrix):
    for row in matrix:
        for val in row:
            val * val

if __name__ == '__main__':

    dt = timeit(lambda: map(fib, xrange(10)), number=10)
    print "Fibonacci, non-parallel: %.3f" %dt

    matrices = [np.random.randn(1000,1000) for ii in xrange(10)]
    dt = timeit(lambda: map(silly_mult, matrices), number=10)
    print "Silly matrix multiplication, non-parallel: %.3f" %dt

    # after importing numpy, reset the CPU affinity of the parent process so
    # that it will use all CPUS
    os.system("taskset -p 0xff %d" % os.getpid())

    pool = Pool(8)

    dt = timeit(lambda: pool.map(fib,xrange(10)), number=10)
    print "Fibonacci, parallel: %.3f" %dt

    dt = timeit(lambda: pool.map(silly_mult, matrices), number=10)
    print "Silly matrix multiplication, parallel: %.3f" %dt
```
De sortie:
```
$ python tmp.py
Fibonacci, non-parallel: 32.449
Silly matrix multiplication, non-parallel: 40.084
pid 29528's current affinity mask: 1
pid 29528's new affinity mask: ff
Fibonacci, parallel: 9.462
Silly matrix multiplication, parallel: 12.163
```
Je pense que la première phrase de cette réponse est à peu près l'ensemble de la réponse. Tout est destiné à s'exécuter sur la même base, donc c'est un peu plus lent (parce qu'il y a des frais généraux supplémentaires), plutôt que plus rapide (car il n'y a pas de parallélisation).
En fait, je crois toujours que c'est plus probablement liée à des bizarreries de numpy plutôt que de simplement le faire avec l'utilisation du CPU. Même quand je paralléliser Framester le code original de sorte qu'il est en fait l'utilisation de l'ensemble de mon Cpu j' trouve que c'est légèrement plus lente qu'une exécution en série. C'est seulement quand j'ai délibérément éviter de faire des choses qui numpy est particulièrement bon à ce que je vois aucun gain de performance de la parallélisation.
Vous avez raison; désolé, je n'ai pas lu assez loin, j'ai juste commencé à tester sur mon propre trivial/stupide exemple de code. Jamais l'esprit. 🙂
Pour la comparaison, vous avez à montrer ce qui se passe lorsque vous quittez os.system("taskset -p 0xff %d" % os.getpid()).
Pourquoi? Si je quitte cette ligne alors (au moins sur ma machine) en un seul noyau qui sera utilisé, alors, évidemment, je ne vois pas d'accélération à partir de la version parallèle.

OriginalL'auteur
11

L'imprévisible de la concurrence entre la communication de la surcharge et de calcul de l'accélération est certainement la question ici. Ce que vous observez est parfaitement bien. Si vous obtenez une vitesse nette dépend de nombreux facteurs et est quelque chose qui doit être quantifié correctement (comme vous l'avez fait).

Alors pourquoi est - multiprocessing si "lent de façon inattendue" dans votre cas? multiprocessing's map et map_async fonctions réellement pickle des objets Python en arrière à travers les tuyaux qui relient le parent avec l'enfant des processus. Cela peut prendre un temps considérable. Pendant ce temps, le processus enfants n'ont presque rien à faire, c'est ce qui est à voir dans htop. Entre les différents systèmes, il y a peut être une grande pipe de transport différence de performance, qui est aussi pourquoi pour certaines personnes de votre piscine code est plus rapide que votre CPU seul code, même si pour vous il n'est pas (d'autres facteurs peuvent entrer en jeu ici, c'est juste un exemple pour expliquer l'effet).

Que pouvez-vous faire pour le rendre plus rapide?
1. Ne pas cornichons à l'entrée sur POSIX systèmes.
  
  Si vous êtes sous Unix, vous pouvez obtenir autour de la relation parent->enfant de la communication frais généraux par l'intermédiaire de prendre avantage de POSIX' processus de fourche comportement (copie de la mémoire lors de l'écriture):
  
  Créez votre tâche d'entrée (par exemple une liste de matrices de grande taille), de travailler sur dans le processus parent dans un accessible dans le monde entier variable. Puis de créer des processus de travail en appelant multiprocessing.Process() vous-même. Chez les enfants, prenez le travail de saisie à partir de la variable globale. Simplement exprimé, ce qui rend l'enfant à accéder à la mémoire de la mère sans aucune communication, les frais généraux (*, l'explication ci-dessous). Envoyer le résultat à la maison mère, par exemple, au moyen d'un multiprocessing.Queue. Cela permettra d'économiser beaucoup de la communication-dessus, surtout si la sortie est faible par rapport à l'entrée. Cette méthode ne fonctionnera pas sur, par exemple, Windows, parce que multiprocessing.Process() il crée une toute nouvelle Python processus qui n'hérite pas de l'état de la société mère.
2. Utiliser numpy multithreading.
  Selon votre tâche de calcul, il peut arriver que la participation de multiprocessing ne va pas aider du tout. Si vous compilez numpy vous-même et de permettre aux directives OpenMP, puis des opérations sur des grandes matrices pourrait devenir très efficacement multithread (et distribué sur de nombreux cœurs de PROCESSEUR; le GIL est pas un facteur limitant ici) par eux-mêmes. Fondamentalement, c'est le plus efficace l'utilisation de plusieurs cœurs de PROCESSEUR que vous pouvez obtenir dans le contexte de numpy/scipy.
*L'enfant ne peut pas accéder directement au parent de la mémoire en général. Cependant, après fork(), le parent et l'enfant sont dans un équivalent de l'état. Il serait stupide de copier l'ensemble de la mémoire de la mère à une autre place dans la RAM. C'est pourquoi la copie sur écriture principe de sauts. Tant que l'enfant n'a pas changement son état de la mémoire, en effet, il accède à la mère de la mémoire. Uniquement en cas de modification, les morceaux sont copiés dans l'espace mémoire de l'enfant.

Majeur edit:

Permettez-moi d'ajouter un bout de code qui croque une grande quantité de données d'entrée avec plusieurs processus de travail et suit les conseils "1. Ne pas cornichons à l'entrée sur POSIX systèmes.". En outre, la quantité d'information transférée au travailleur manager (le processus père) est assez faible. La lourde calcul le cadre de cet exemple est une valeur unique de la décomposition. Il peut faire un usage intensif de OpenMP. J'ai exécuté l'exemple à plusieurs reprises:
- Une fois avec 1, 2, ou 4 processus de travail et OMP_NUM_THREADS=1, de sorte que chaque processus de travail crée une charge maximale de 100 %. Là, le nombre de travailleurs-calculer les temps de mise à l'échelle de comportement est presque linéaire et la nette accélération facteur correspond au nombre de travailleurs concernés.
- Une fois avec 1, 2, ou 4 processus de travail et OMP_NUM_THREADS=4, de sorte que chaque processus crée une charge maximale de 400 % (par l'intermédiaire de frai 4 threads OpenMP). Ma machine a 16 de véritables noyaux, donc 4 processus avec max 400 % de la charge à chaque va et presque obtenir le maximum de performances de la machine. La mise à l'échelle n'est pas parfaitement linéaire plus et l'accélération facteur n'est pas le nombre de travailleurs impliqués, mais la valeur de temps de calcul devient significativement réduite par rapport à OMP_NUM_THREADS=1 et le temps encore diminue significativement avec le nombre de processus de travail.
- Une fois avec plus de données d'entrée, de 4 cœurs, et OMP_NUM_THREADS=4. Il en résulte une moyenne de charge du système de 1253 %.
- Une fois avec la même configuration que la dernière, mais OMP_NUM_THREADS=5. Il en résulte une moyenne de charge du système de 1598 %, ce qui suggère que nous avons tout de de 16 de base de la machine. Cependant, le calcul de la paroi temps ne s'améliore pas par rapport à ce dernier cas.
Le code:
```
import os
import time
import math
import numpy as np
from numpy.linalg import svd as svd
import multiprocessing
# If numpy is compiled for OpenMP, then make sure to control
# the number of OpenMP threads via the OMP_NUM_THREADS environment
# variable before running this benchmark.
MATRIX_SIZE = 1000
MATRIX_COUNT = 16
def rnd_matrix():
offset = np.random.randint(1,10)
stretch = 2*np.random.rand()+0.1
return offset + stretch * np.random.rand(MATRIX_SIZE, MATRIX_SIZE)
print "Creating input matrices in parent process."
# Create input in memory. Children access this input.
INPUT = [rnd_matrix() for _ in xrange(MATRIX_COUNT)]
def worker_function(result_queue, worker_index, chunk_boundary):
"""Work on a certain chunk of the globally defined `INPUT` list.
"""
result_chunk = []
for m in INPUT[chunk_boundary[0]:chunk_boundary[1]]:
# Perform single value decomposition (CPU intense).
u, s, v = svd(m)
# Build single numeric value as output.
output =  int(np.sum(s))
result_chunk.append(output)
result_queue.put((worker_index, result_chunk))
def work(n_workers=1):
def calc_chunksize(l, n):
"""Rudimentary function to calculate the size of chunks for equal 
distribution of a list `l` among `n` workers.
"""
return int(math.ceil(len(l)/float(n)))
# Build boundaries (indices for slicing) for chunks of `INPUT` list.
chunk_size = calc_chunksize(INPUT, n_workers)
chunk_boundaries = [
(i, i+chunk_size) for i in xrange(0, len(INPUT), chunk_size)]
# When n_workers and input list size are of same order of magnitude,
# the above method might have created less chunks than workers available. 
if n_workers != len(chunk_boundaries):
return None
result_queue = multiprocessing.Queue()
# Prepare child processes.
children = []
for worker_index in xrange(n_workers):
children.append(
multiprocessing.Process(
target=worker_function,
args=(
result_queue,
worker_index,
chunk_boundaries[worker_index],
)
)
)
# Run child processes.
for c in children:
c.start()
# Create result list of length of `INPUT`. Assign results upon arrival.
results = [None] * len(INPUT)
# Wait for all results to arrive.
for _ in xrange(n_workers):
worker_index, result_chunk = result_queue.get(block=True)
chunk_boundary = chunk_boundaries[worker_index]
# Store the chunk of results just received to the overall result list.
results[chunk_boundary[0]:chunk_boundary[1]] = result_chunk
# Join child processes (clean up zombies).
for c in children:
c.join()
return results
def main():
durations = []
n_children = [1, 2, 4]
for n in n_children:
print "Crunching input with %s child(ren)." % n
t0 = time.time()
result = work(n)
if result is None:
continue
duration = time.time() - t0
print "Result computed by %s child process(es): %s" % (n, result)
print "Duration: %.2f s" % duration
durations.append(duration)
normalized_durations = [durations[0]/d for d in durations]
for n, normdur in zip(n_children, normalized_durations):
print "%s-children speedup: %.2f" % (n, normdur)
if __name__ == '__main__':
main()
```
La sortie:
```
$ export OMP_NUM_THREADS=1
$ /usr/bin/time python test2.py 
Creating input matrices in parent process.
Crunching input with 1 child(ren).
Result computed by 1 child process(es): [5587, 8576, 11566, 12315, 7453, 23245, 6136, 12387, 20634, 10661, 15091, 14090, 11997, 20597, 21991, 7972]
Duration: 16.66 s
Crunching input with 2 child(ren).
Result computed by 2 child process(es): [5587, 8576, 11566, 12315, 7453, 23245, 6136, 12387, 20634, 10661, 15091, 14090, 11997, 20597, 21991, 7972]
Duration: 8.27 s
Crunching input with 4 child(ren).
Result computed by 4 child process(es): [5587, 8576, 11566, 12315, 7453, 23245, 6136, 12387, 20634, 10661, 15091, 14090, 11997, 20597, 21991, 7972]
Duration: 4.37 s
1-children speedup: 1.00
2-children speedup: 2.02
4-children speedup: 3.81
48.75user 1.75system 0:30.00elapsed 168%CPU (0avgtext+0avgdata 1007936maxresident)k
0inputs+8outputs (1major+809308minor)pagefaults 0swaps
$ export OMP_NUM_THREADS=4
$ /usr/bin/time python test2.py 
Creating input matrices in parent process.
Crunching input with 1 child(ren).
Result computed by 1 child process(es): [22735, 5932, 15692, 14129, 6953, 12383, 17178, 14896, 16270, 5591, 4174, 5843, 11740, 17430, 15861, 12137]
Duration: 8.62 s
Crunching input with 2 child(ren).
Result computed by 2 child process(es): [22735, 5932, 15692, 14129, 6953, 12383, 17178, 14896, 16270, 5591, 4174, 5843, 11740, 17430, 15861, 12137]
Duration: 4.92 s
Crunching input with 4 child(ren).
Result computed by 4 child process(es): [22735, 5932, 15692, 14129, 6953, 12383, 17178, 14896, 16270, 5591, 4174, 5843, 11740, 17430, 15861, 12137]
Duration: 2.95 s
1-children speedup: 1.00
2-children speedup: 1.75
4-children speedup: 2.92
106.72user 3.07system 0:17.19elapsed 638%CPU (0avgtext+0avgdata 1022240maxresident)k
0inputs+8outputs (1major+841915minor)pagefaults 0swaps
$ /usr/bin/time python test2.py 
Creating input matrices in parent process.
Crunching input with 4 child(ren).
Result computed by 4 child process(es): [21762, 26806, 10148, 22947, 20900, 8161, 20168, 17439, 23497, 26360, 6789, 11216, 12769, 23022, 26221, 20480, 19140, 13757, 23692, 19541, 24644, 21251, 21000, 21687, 32187, 5639, 23314, 14678, 18289, 12493, 29766, 14987, 12580, 17988, 20853, 4572, 16538, 13284, 18612, 28617, 19017, 23145, 11183, 21018, 10922, 11709, 27895, 8981]
Duration: 12.69 s
4-children speedup: 1.00
174.03user 4.40system 0:14.23elapsed 1253%CPU (0avgtext+0avgdata 2887456maxresident)k
0inputs+8outputs (1major+1211632minor)pagefaults 0swaps
$ export OMP_NUM_THREADS=5
$ /usr/bin/time python test2.py 
Creating input matrices in parent process.
Crunching input with 4 child(ren).
Result computed by 4 child process(es): [19528, 17575, 21792, 24303, 6352, 22422, 25338, 18183, 15895, 19644, 20161, 22556, 24657, 30571, 13940, 18891, 10866, 21363, 20585, 15289, 6732, 10851, 11492, 29146, 12611, 15022, 18967, 25171, 10759, 27283, 30413, 14519, 25456, 18934, 28445, 12768, 28152, 24055, 9285, 26834, 27731, 33398, 10172, 22364, 12117, 14967, 18498, 8111]
Duration: 13.08 s
4-children speedup: 1.00
230.16user 5.98system 0:14.77elapsed 1598%CPU (0avgtext+0avgdata 2898640maxresident)k
0inputs+8outputs (1major+1219611minor)pagefaults 0swaps
```
Question supplémentaire concernant point2: stackoverflow.com/questions/15531556/...
+1: plus d'explication plausible. Permettez-moi seulement d'ajouter qu'en plus de permettre OpenMP dans numpy, on doit aussi utiliser des fournisseurs de bibliothèques blas, si disponible.
Je me demande si la raison pour laquelle vous ne pas voir beaucoup de notable gain de performance lors de la parallélisation de la matrice des manipulations dans numpy pourrait en fait être parce que numpy externes BLAS et LAPACK bibliothèques, qui sont souvent compilées à l'utilisation de plusieurs cœurs simultanément. Si vous essayez d'exécuter quelque chose comme svd en parallèle (qui utilise LAPACK) peut-être que chaque travailleur se comporte comme si elle est en cours d'exécution sur plusieurs cœurs, et ne "sous-optimale" des choses comme écrire des uns et des autres caches etc.
Dans le premier exemple, nous voyons idéal de mise à l'échelle (1-enfants speedup: 1.00, 2-les enfants de l'accélération: 2.02, 4-les enfants de l'accélération: 3.81). Je suppose que ce que vous êtes en train de parler: Calcul de la durée dans le cas où 4 enfants / OMP_NUM_THREADS=1: 4.37 s vs 2.95 s avec OMP_NUM_THREADS=4. Oui, c'est de loin pas un changement de facteur 4 (comme l'aurait été l'idéal). Cependant, ce qui est attendu. Comme SVD sur de grandes matrices consiste à déplacer autour des tonnes de données entre la mémoire RAM, la mémoire cache, et les registres, les pipelines (esp. entre le CPU et la RAM, c'est à dire Hypertransport/Quickpath/FSB) sont le goulot d'étranglement. Très simple.
Merci pour l'exemple de code. Malheureusement, parfois, le code s'arrête après " Croquer entrée avec 1 enfant(s)' et y reste à jamais. Mais je n'ai pas vérifié l'OMP soutien de mon numpy version.

OriginalL'auteur
3

Votre code est correct. J'ai juste couru mon système (avec 2 cœurs, l'hyperthreading) et a obtenu les résultats suivants:
```
$ python test_multi.py 
30.8623809814
19.3914041519
```
J'ai regardé les processus et, comme prévu, le parallèle de la partie montrant plusieurs processus de travail de près de 100%. Ce doit être quelque chose dans votre système ou de l'installation de python.

Merci d'essayer mon code de +1 et de votre évaluation. Aucune idée de ce qui pourrait être mal, ou ce que je pourrais google?
Pas sûr de ce que pourrait être mauvais. Quel système utilisez-vous? Je voudrais essayer d'autres multiprocessing méthodes de côté de Pool de départ, ou même Pool avec les différents processus de travail sur les parties d'un tableau partagé.

OriginalL'auteur
2

La mesure de l'arithmétique débit est une tâche très difficile: sur le fond, votre cas de test est trop simple, et je vois beaucoup de problèmes.

Première à tester l'arithmétique entière: est-il une raison particulière? Avec virgule flottante vous obtenez des résultats qui sont comparables sur plusieurs architectures différentes.

~~Deuxième matrix = matrix*matrix remplace le paramètre d'entrée (matrices sont passés par référence et non par valeur), et chaque échantillon a travailler sur des données différentes...~~

Derniers tests devraient être réalisés sur un large éventail de la taille du problème et le nombre de travailleurs, afin de saisir les tendances générales.

Voici donc modifié mon script de test
```
import numpy as np
from timeit import timeit
from multiprocessing import Pool
def mmul(matrix):
mymatrix = matrix.copy()
for i in range(100):
mymatrix *= mymatrix
return mymatrix
if __name__ == '__main__':
for n in (16, 32, 64):
matrices = []
for i in range(n):
matrices.append(np.random.random_sample(size=(1000, 1000)))
stmt = 'from __main__ import mmul, matrices'
print 'testing with', n, 'matrices'
print 'base',
print '%5.2f' % timeit('r = map(mmul, matrices)', setup=stmt, number=1)
stmt = 'from __main__ import mmul, matrices, pool'
for i in (1, 2, 4, 8, 16):
pool = Pool(i)
print "%4d" % i, 
print '%5.2f' % timeit('r = pool.map(mmul, matrices)', setup=stmt, number=1)
pool.close()
pool.join()
```
et mes résultats:
```
$ python test_multi.py 
testing with 16 matrices
base  5.77
1  6.72
2  3.64
4  3.41
8  2.58
16  2.47
testing with 32 matrices
base 11.69
1 11.87
2  9.15
4  5.48
8  4.68
16  3.81
testing with 64 matrices
base 22.36
1 25.65
2 15.60
4 12.20
8  9.28
16  9.04
```
[Mise à JOUR] - je exécuter cet exemple à la maison sur un ordinateur différent, l'obtention d'un uniforme ralentissement:
```
testing with 16 matrices
base  2.42
1  2.99
2  2.64
4  2.80
8  2.90
16  2.93
testing with 32 matrices
base  4.77
1  6.01
2  5.38
4  5.76
8  6.02
16  6.03
testing with 64 matrices
base  9.92
1 12.41
2 10.64
4 11.03
8 11.55
16 11.59
```
Je dois avouer que je ne sais pas qui est à blâmer (numpy, python, compilateur, noyau)...

Merci, mais je reçois des messages d'erreur suivants: "Exception RuntimeError: RuntimeError('impossible de joindre un thread en cours',) <Finaliser l'objet, dead> ignorés'
s'il vous plaît ajouter pool.join() après pool.close(); si l'exécution est court, vous pouvez augmenter le nombre d'itérations dans timeit.
Merci, j'ai essayé le code et je reçois aussi pas speedup?
Personne n'est à blâmer, sauf pour le code! 🙂 Je l'ai essayé sur un moderne 16 core E5-2650 système. J'observe une vitesse pour un député de la piscine de taille 2 et 4. Au-delà, le temps d'exécution devient de pire encore. La parallélisation de la méthode de ce code est loin d'être efficace. Stefano: la vitesse que vous avez observé sur un ordinateur n'est pas du tout linéaire au nombre de noyaux impliqués. Raisonnable théorie pour expliquer les différences entre vos deux ordinateurs: dans le premier exemple, le ratio entre la vitesse de base et du transport des tuyaux de performance est plus faible que dans le deuxième exemple.

OriginalL'auteur
1

Par défaut, Pool utilise uniquement les processus n, où n est le nombre de Processeurs sur votre machine. Vous devez spécifier le nombre de processus que vous souhaitez utiliser, comme Pool(5).

Voir ici pour plus d'infos

merci pour vos commentaires, veuillez voir ma mise à jour

OriginalL'auteur
1

Puisque vous mentionnez que vous avez beaucoup de fichiers, je dirais que la solution suivante;
- Faire une liste de noms de fichiers.
- Écrire une fonction qui charge et les processus d'un seul fichier nommé comme le paramètre d'entrée.
- Utilisation Pool.map() appliquer la fonction à la liste de fichiers.
Puisque chaque instance se charge désormais de son propre fichier, les données transmises sont des noms de fichiers, et non pas (potentiellement important) les tableaux numpy.

OriginalL'auteur
0

J'ai aussi remarqué que quand j'ai couru numpy multiplication de matrice à l'intérieur de la Piscine.map() de la fonction, il a couru beaucoup plus lent sur certaines machines. Mon but était de paralléliser mon travail sur la Piscine.map(), et de lancer un processus sur chaque cœur de ma machine. Quand les choses ont été en cours d'exécution rapide, le numpy multiplication de matrice était seulement une petite partie de l'ensemble du travail effectué en parallèle. Quand j'ai regardé à l'utilisation du PROCESSEUR du processus, j'ai pu voir que chaque processus peut utiliser, par exemple, plus de 400% de CPU sur les machines où il s'lent, mais toujours <=100% sur les machines où il a couru vite. Pour moi, la solution a été de arrêter de numpy de multithreading. Il s'avère que numpy a été mis en place pour multithread exactement sur les machines où ma Piscine.map() a été lent. Evidemment, si vous êtes déjà de la parallélisation de l'aide à la Piscine.map(), puis d'avoir numpy aussi paralléliser crée des interférences. Je viens d'appeler export MKL_NUM_THREADS=1 avant l'exécution de mon code Python et il a travaillé rapide partout.

OriginalL'auteur

Vous devez vous connecter pour publier un commentaire.