Comment les performances des opérations de tableau Python / Numpy évoluent-elles avec l'augmentation des dimensions du tableau?

Comment les tableaux Python / Numpy évoluent-ils avec des dimensions de tableau croissantes?

Ceci est basé sur un comportement que j'ai remarqué lors de l'analyse comparative du code Python pour cette question: Comment exprimer cette expression compliquée à l'aide de tranches numpy

Le problème concernait principalement l'indexation pour remplir un tableau. J'ai trouvé que les avantages de l'utilisation (pas très bonne) des versions Cython et Numpy sur une boucle Python variaient en fonction de la taille des tableaux impliqués. Numpy et Cython connaissent un avantage de performance croissant jusqu'à un certain point (quelque part largement autour de pour Cython et pour Numpy sur mon ordinateur portable), après quoi leurs avantages ont diminué (la fonction Cython est restée la plus rapide). $N=500$ $N=2000$

Ce matériel est-il défini? En termes de travail avec de grands tableaux, quelles sont les meilleures pratiques à respecter pour le code où les performances sont appréciées?

Tracé du temps d'exécution par rapport au code en boucle pour les implémentations vectorisées et Cython

Cette question ( pourquoi mon échelle de multiplication matricielle-vectorielle? ) Peut être liée, mais je suis intéressé à en savoir plus sur les différentes façons de traiter les tableaux à l'échelle Python les uns par rapport aux autres.

python performance numpy

— Nat Wilson
source

Avez-vous essayé numexpr ? Il y a aussi, par exemple, cet exposé qui pointe vers blosc et CArray , tous destinés à accélérer les choses (et éventuellement à contourner les limitations de la bande passante mémoire).

— 0 0

Pouvez-vous publier le code utilisé pour le profil. Il se passe probablement quelques choses ici.

— meawoppl

$4$ $16 kB$

def timeit(size):
     t0 = time.time()
     for _ in xrange(10):
         np.random.random(size)
     return time.time() - t0

sizes = np.logspace(1, 6, 40)
times = [timeit(s) for s in sizes]

Il y a quelques petites choses qui ne vont pas avec cette référence, pour commencer, je ne désactive pas la collecte des ordures et je prends la somme, pas le meilleur moment, mais supportez-moi.

$8000$ $64 kB$

Faut-il s'inquiéter de la taille du cache? En règle générale, je dis non. L'optimiser en Python signifie rendre le code beaucoup plus compliqué, pour des gains de performances douteux. N'oubliez pas que les objets Python ajoutent plusieurs frais généraux difficiles à suivre et à prévoir. Je ne peux penser qu'à deux cas où c'est un facteur pertinent:

Opérations de base sur de grands tableaux (comme évaluer un polynôme), limitées par la bande passante mémoire. Utilisez Numexpr ou (si les données sont beaucoup plus volumineuses ) Pytables . Ils sont optimisés pour tenir compte de la taille du cache entre autres optimisations.
Code de performance critique: si vous voulez presser toutes les microsecondes, vous ne devez pas utiliser Python en premier lieu. Écrire Cython vectorisé et laisser le compilateur faire ce qu'il fait le mieux est probablement le chemin indolore.

Dans les commentaires, Evert a mentionné CArray. Notez que, même en fonctionnement, le développement s'est arrêté et il a été abandonné en tant que projet autonome. La fonctionnalité sera incluse à la place dans Blaze , un projet en cours pour créer une "nouvelle génération Numpy".

— Davidmh
source