Qu'est-ce qui est le plus rapide en Python : x**.5 ou math.sqrt(x) ?

Question

Je me pose cette question depuis un certain temps. Comme le dit le titre, qu'est-ce qui est le plus rapide, la fonction proprement dite ou la simple élévation à la moitié de la puissance ?

UPDATE

Il ne s'agit pas d'une optimisation prématurée. Il s'agit simplement de savoir comment le code sous-jacent fonctionne réellement. Quelle est la théorie sur le fonctionnement du code Python ?

J'ai envoyé un courriel à Guido van Rossum parce que je voulais vraiment connaître les différences entre ces méthodes.

Mon email :

Il existe au moins 3 façons de faire une racine carrée en Python : math.sqrt, l'opérateur '**' et pow(x,.5). l'opérateur '**' et pow(x,.5). Je suis juste curieux de savoir quelles sont les différences dans l'implémentation de chacune d'entre elles. En termes d'efficacité, quelle est la meilleure est la meilleure ?

Sa réponse :

pow et ** sont équivalents ; math.sqrt ne fonctionne pas pour les nombres complexes, et renvoie à la fonction C sqrt(). Quant à savoir laquelle est rapide, je n'en ai aucune idée...

Answer 1

math.sqrt(x) est nettement plus rapide que `x0.5` .**

import math
N = 1000000

%%timeit
for i in range(N):
    z=i**.5

10 boucles, best of 3 : 156 ms par boucle

%%timeit
for i in range(N):
    z=math.sqrt(i)

10 boucles, meilleur de 3 : 91.1 ms par boucle

Utilisation de Python 3.6.9 ( ordinateur portable ).

Answer 2

• première règle de l'optimisation : ne le faites pas
• deuxième règle : ne le faites pas pourtant

Voici quelques timings (Python 2.5.2, Windows) :

$ python -mtimeit -s"from math import sqrt; x = 123" "x**.5"
1000000 loops, best of 3: 0.445 usec per loop

$ python -mtimeit -s"from math import sqrt; x = 123" "sqrt(x)"
1000000 loops, best of 3: 0.574 usec per loop

$ python -mtimeit -s"import math; x = 123" "math.sqrt(x)"
1000000 loops, best of 3: 0.727 usec per loop

Ce test montre que x**.5 est légèrement plus rapide que sqrt(x) .

Pour Python 3.0, le résultat est inverse :

$ \Python30\python -mtimeit -s"from math import sqrt; x = 123" "x**.5"
1000000 loops, best of 3: 0.803 usec per loop

$ \Python30\python -mtimeit -s"from math import sqrt; x = 123" "sqrt(x)"
1000000 loops, best of 3: 0.695 usec per loop

$ \Python30\python -mtimeit -s"import math; x = 123" "math.sqrt(x)"
1000000 loops, best of 3: 0.761 usec per loop

math.sqrt(x) est toujours plus rapide que x**.5 sur une autre machine (Ubuntu, Python 2.6 et 3.1) :

$ python -mtimeit -s"from math import sqrt; x = 123" "x**.5"
10000000 loops, best of 3: 0.173 usec per loop
$ python -mtimeit -s"from math import sqrt; x = 123" "sqrt(x)"
10000000 loops, best of 3: 0.115 usec per loop
$ python -mtimeit -s"import math; x = 123" "math.sqrt(x)"
10000000 loops, best of 3: 0.158 usec per loop
$ python3.1 -mtimeit -s"from math import sqrt; x = 123" "x**.5"
10000000 loops, best of 3: 0.194 usec per loop
$ python3.1 -mtimeit -s"from math import sqrt; x = 123" "sqrt(x)"
10000000 loops, best of 3: 0.123 usec per loop
$ python3.1 -mtimeit -s"import math; x = 123" "math.sqrt(x)"
10000000 loops, best of 3: 0.157 usec per loop

Answer 3

Dans ces micro-benchmarks, math.sqrt sera plus lent, en raison du léger temps nécessaire à la recherche de l'adresse de l'utilisateur. sqrt dans l'espace de nom mathématique. Vous pouvez l'améliorer légèrement avec

 from math import sqrt

Même dans ce cas, l'exécution de quelques variations à travers timeit, montre un léger avantage (4-5%) en termes de performances pour x**.5

Il est intéressant de noter que faire

 import math
 sqrt = math.sqrt

l'a accéléré encore plus, avec une différence de vitesse de moins de 1%, avec une signification statistique très faible.

---

Je vais répéter Kibbee, et dire que c'est probablement une optimisation prématurée.

Answer 4

Combien de racines carrées exécutez-vous réellement ? Essayez-vous d'écrire un moteur graphique 3D en Python ? Si ce n'est pas le cas, alors pourquoi choisir un code cryptique plutôt qu'un code facile à lire ? La différence de temps serait inférieure à ce que l'on pourrait remarquer dans n'importe quelle application que je pourrais envisager. Je ne veux vraiment pas rabaisser votre question, mais il semble que vous alliez un peu trop loin dans l'optimisation prématurée.

Answer 5

Très probablement math.sqrt(x), parce qu'il est optimisé pour la racine carrée.

Les repères vous fourniront la réponse que vous recherchez.