Discussion :

[jlg_47]

Bonjour,

Comme j'en ai déjà parlé, j'ai un code qui s'exécute pratiquement 100 fois plus vite en Fortran qu'en Python ...

Cet écart important me surprend car j'utilise numpy qui, je crois, accélère les calculs ...

J'ai fait un essai sur un bout de code très simple que j'exécute un million de fois et dont je mesure le temps d'exécution ...

verdict : 0,48 secondes en Fortran pour 9,23 secondes en Python/Numpy; soit pratiquement un facteur 40

Et sans Numpy, le code Python met 325 secondes soit un facteur 700 !!!

voici le bout de code en Python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# -*- coding: cp1252 -*-
import numpy as np
from time import *

# creation de 5 arrays Numpy 
dimension = 40
f = np.ndarray(shape =(dimension),dtype=np.float)
h = np.ndarray(shape =(dimension),dtype=np.float)
w = np.ndarray(shape =(dimension),dtype=np.float)
e = np.ndarray(shape =(dimension),dtype=np.float)
t = np.ndarray(shape =(dimension),dtype=np.float)
# remplissage des arrays Numpy
h.fill (10.)
w.fill (1000.)
e.fill (290.)
t.fill (300.)

t1 = time()  # recuperation du temps système
i = 0
while (i < 1000000):  # execution de un million de calcul
    f = h * w * ( e - t ) # calcul
    i = i +1

print 'temps pour un million de passages:', (time() - t1)

Et pour ceux qui lisent le Fortran, le même en Fortran, les opérations Numpy sont remplacées par des boucles :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
USE DFPORT
	implicit none
	real t1, t2
	real temps(2)
	integer n, i, j
	
	! déclaration de 5 tableaux
	parameter (n=40)
	real f(n),h(n), w(n), e(n), t(n)
	
	! remplissage des tableaux
	do i = 1,n
		h(i) = 10.
		w (i) = 1000.
		e (i) = 290.
		t (i) = 300.
	enddo 

	t1= dtime(temps) ! récupération du temps système avant calcul
	do i = 1, 1000000  ! boucle pour un million de calcul
		do j = 1, n  ! boucle remplaçant les opérations Numpy
			f(j) = h(j) * w(j) * ( e(j) - t(j) )
		enddo
	enddo	
	t2 = dtime(temps) ! récupération du temps système après calcul
	write (6,*) 'temps pour un million de passages:',temps(1) + temps(2)
	
	end

N'y a t-il pas moyen de faire plus rapide avec Python?

En utilisant Numpy, je m'attendais à avoir quelque chose 2 à 3 fois plus lent que Fortran mais j'étais loin de penser à un facteur 40 à 100

Est ce normal?
Est ce que je fais quelque chose de mal?



Bon dimanche

[PauseKawa]

Bonjour,

<Cote avis perso Cote>
Dans un premier temps je pense qu'il serait bon de remettre les choses en place pour ce qui est de la vitesse des codes.
Pour moi (j'espère qu'eyquem est en congé...) tu dois déjà faire la différence entre les langages interprétés, semi-compilés (donc python) et compilés. Les derniers étant dans l'absolu plus rapides que les précédents car le code est plus proche de ce qui est attendu.
Maintenant il y à aussi la qualité du langage. Les premiers d'une classes étant meilleurs que les plus mauvais d'une autre
Les autres facteurs étant l'optimisation du code (donc toi) et dans le cas des semi-compilés la présence de bytecode optimisé pour ce que tu cherche à faire.
Petit aveu : Python n'est pas le plus rapide.
<Cote avis perso Cote>

Je ne connais pas Fortran ni numpy pour te dire si le code est optimisé.

@+

Ps : Je trouve que tu utilise pas mal de while dans tes codes.

[PauseKawa]

Re,

J'avais oublié la qualité du compilateur, cela y fais sur la rapidité du code.

@+

[PauseKawa]

Rere,

Si tu code en Fortran regarde cela :

http://cens.ioc.ee/projects/f2py2e/
http://sourceforge.net/projects/pyfortran/
http://fortrancython.wordpress.com/

@+

[jlg_47]

Re bonjour PauseKawa,

Je suis d'accord avec toi.
Je sais qu'a priori Python n'étant pas un langage compilé, le code s'exécute plus lentement qu'un code en C ou en Fortran ...

De là à avoir un facteur 700 sur un simple calcul avec des multiplications et des soustractions !!

Numpy arrive à faire descendre le facteur de 700 à un peu moins de 40 ce qui reste encore énorme ...
Un code qui s'exécute en 90 secondes en Fortran met environ une heure en utilisant Numpy et 1 jour et demi en Python pur

Quant aux boucles while, en Python, il n'y en a qu'une: celle qui sert à faire exécuter le code plusieurs fois ....

Dans mon cas, chaque passage dans mon jeu d'équations fait avancer mon processus de 100 microsecondes ... un peu comme si je calculais l'évolution d'un nuage en déterminant ses paramètres 10000 fois par seconde.

J'ai choisi Python en voyant ce qui est dit ici et en estimant que cela me conviendrait ...

Jusqu'à maintenant le temps d'exécution de mon code Python est acceptable, mais si j'augmente la taille des tableaux Numpy, ce qui revient à faire un découpage spatial plus fin de mon processus (ce que je souhaite faire) ... je pars vers des temps d'exécution prohibitifs

Je m'oriente donc vers une mixture Fortran/Python ou C/Python qui risque de me créer beaucoup de soucis ...

D'où mon interrogation?

Bon dimanche

[PauseKawa]

Bonjour,

Je m'oriente donc vers une mixture Fortran/Python ou C/Python qui risque de me créer beaucoup de soucis ...

Pourquoi ? De toute manière le tableau final de ton lien montre que tu n'as pas le choix.

@+

Edit : Pour le while mon exemple avec range te montre que l'utilisation d'un build in est plus rapide.

[kango]

bonjour,

à algorithme identique (ce qui est ton cas ici), un code python sera plus lent qu'un code fortran.

là où tu peux gagner, c'est que python via ses librairies peut te permettre d'utiliser un algorithme différent, plus rapide, et qui va permettre de gagner du temps par rapport à fortran.

dans ton cas ici, le coeur de ton problème c'est le calcul matriciel, domaine où fortran excelle donc ça ne va pas être simple et peut être même impossible.

après tout dépend de la représentativité de ton test par rapport à ton besoin réel. ensuite, n'oublie pas de vectoriser (quand c'est possible) les calculs numpy: ils seront beaucoup plus rapides.

mais python n'a pas besoin d'être plus rapide que le fortran, il n'en a pas besoin parce qu'un code python peut facilement communiquer avec une librairie fortran avec f2py. PauseKawa t'a donné le lien plus haut

il n'existe pas de langage parfait, c'est à dire disposant d'une quantité presque illimitée de fonctionnalités, portable, sobre en cpu et en ram et peu couteux en terme de développement. mais il existe tellement de passerelles possibles entre le python, le c, le c++ et le fortran qu'un programme basé astucieusement sur ces langages sera franchement efficace

[PauseKawa]

Re,

Les autres facteurs étant l'optimisation du code (donc toi)

et dans le cas des semi-compilés la présence de bytecode optimisé pour ce que tu cherche à faire.

Un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
t1 = time()  # recuperation du temps système
i = 0
while(i<1000000):  # execution de un million de calcul
    f = h * w * ( e - t ) # calcul
    i+=1
 
print 'temps pour un million de passages:', (time() - t1)
print f

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
patrice@Zeus:~/Bureau$ python calcultime1.py 
temps pour un million de passages: 20.4945468903
[-100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.
 -100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.
 -100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.
 -100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.
 -100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
t1 = time()  # recuperation du temps système
for i in range(1000000):  # execution de un million de calcul
    f = h * w * ( e - t ) # calcul
 
print 'temps pour un million de passages:', (time() - t1)
print f

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
patrice@Zeus:~/Bureau$ python calcultime1.py 
temps pour un million de passages: 18.2382779121
[-100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.
 -100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.
 -100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.
 -100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.
 -100000. -100000. -100000. -100000. -100000. -100000. -100000. -100000.]

Et il y a sans doute mieux.

@+