fortran vs C

Version imprimable

fortran vs C

Bonjour à tous,

Je cherche à comparer les vitesses d'exécution de codes C et fortran identiques (pour faire de la prog scientifique) et j'obtiens des résultats curieux.
Sachant que :

le programme utilisé est un simple produit de matrices 1000*1000, la subroutine qui prend du temps est donnée juste après
le compilo C est mingw-gcc et le compilo F95 est Lahey Fortran
options de compil optimales
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 void multiplie(double ***pointeur1, double ***pointeur2, double ***pointeur3, int taille) { int i, j, k; for (i=0;i<taille;i++) { for (j=0;j<taille;j++) { (*pointeur3)[i][j] = 0.0E0; for (k=0;k<taille;k++) { (*pointeur3)[i][j]+=(*pointeur1)[i][k]*(*pointeur2)[k][j]; } } } }
le calcul fortran est 5 fois plus rapide que le calcul C (les résultats étant rigoureusement identiques)
Je ne comprends pas cette différence aussi flagrande ...

Une idée ?

Merci !

pourquoi tu passes l'adresse de l'adresse de la matrice?

test ça:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
void multiplie(double **pointeur1, double **pointeur2, double **pointeur3, int taille)
{
	int i, j, k;
	for (i=0;i<taille;i++)
	{
		for (j=0;j<taille;j++)
		{
			pointeur3[i][j] = 0.;
			for (k=0;k<taille;k++)			
				pointeur3[i][j]+=pointeur1[i][k]*pointeur2[k][j];		
		}
	}
}

donne tes temps pour voir avec et sans optimisations

03/05/2007, 17h50
afrancisco

Citation:

Envoyé par reptils

pourquoi tu passes l'adresse de l'adresse de la matrice?

c'est en essayant plusieurs trucs (je suis en train d'apprendre...)

Suite à ta modif, j'ai les mêmes temps :
- optimisation "level 3" : 12.7s
- optimisation "level 1" : 15.3s

et fortran, 2.8s 8O
03/05/2007, 17h53
reptils

je vais tester de mon coté voir... en fortran tes matrices sont allouées statiquement ou dynamiquement?

EDIT: tu peux me montrer ton equivalent en fortran stp?

EDIT2: est ce que tu peux tester avec un autre compilo fortran genre g95 ou gfortran? genre avec un compilo non commercial
03/05/2007, 18h55
afrancisco

merci pour ta participation !

Les matrices sont allouées dynamiquement, mais là, j'ai quitté le boulot, je posterai ça demain après mes cours. Effectivement, je n'ai pas pensé à tester g95...

bonne soirée
03/05/2007, 19h02
Jean-Marc.Bourguet

Je suppose qu'en Fortran tu as des tableaux bi-dimentionnel, ici tu as un tableau unidimentionnel de pointeur vers tableau unidimentionnel. Tu prends plus de memoire et tu as une indirection de plus a chaque etape.
03/05/2007, 19h14
afrancisco

Citation:

Je suppose qu'en Fortran tu as des tableaux bi-dimentionnel

effectivement

Citation:

ici tu as un tableau unidimentionnel de pointeur vers tableau unidimentionnel. Tu prends plus de memoire et tu as une indirection de plus a chaque etape.

ouïe ! je débute. Peux-tu m'expliquer ou me donner une référence à potasser ?

merci !
03/05/2007, 19h26
Jean-Marc.Bourguet

Citation:

Envoyé par afrancisco

ouïe ! je débute. Peux-tu m'expliquer ou me donner une référence à potasser ?

Je suis mal place pour donner des references adequates aux debutants. Cherche dans les archives et ailleurs sur le site... mais je ne garanti la qualite de rien.

Je peux par contre te donner le conseil d'arreter de t'occuper des performances tant que tu ne maitrise pas le C.
03/05/2007, 19h37
afrancisco
Citation:

Je peux par contre te donner le conseil d'arreter de t'occuper des performances tant que tu ne maitrise pas le C.

Sage conseil ... cependant, le dilemne est celui-ci :
- si C et fortran donnent des temps d'exécutions équivalents en calcul scientifique, alors je m'impliquerai à fond dans C, puisqu'il offre plus de possibilités d'interfaçage graphique (je dois faire du calcul scientifique intensif, avec des IHM pas trop moches)
- si de toute façon C est moins rapide, je le laisse tomber (pour le boulot du moins)
je cherche donc à répondre à cette question ...
03/05/2007, 20h12
DaZumba

Citation:

Envoyé par afrancisco

si C et fortran donnent des temps d'exécutions équivalents en calcul scientifique, alors je m'impliquerai à fond dans C, puisqu'il offre plus de possibilités d'interfaçage graphique (je dois faire du calcul scientifique intensif, avec des IHM pas trop moches)

Dans ce cas-la, en general, on utilise les deux: le coeur calculatoire en Fortran, avec les cliquodromes en C (ou C++, Tcl/Tk, Python, IDL, ...)
03/05/2007, 20h24
afrancisco

J'y ai bien pensé, mais dans le cas où j'ai un calcul très long, j'affiche une progressbar, j'ai donc du code scientifique et du code IHM mêlés ... je ne vois alors pas comment séparer les deux pour utiliser du fortran compilé appelé par du C.
03/05/2007, 20h49
DaZumba

Citation:

Envoyé par afrancisco

J'y ai bien pensé, mais dans le cas où j'ai un calcul très long, j'affiche une progressbar, j'ai donc du code scientifique et du code IHM mêlés ... je ne vois alors pas comment séparer les deux pour utiliser du fortran compilé appelé par du C.

Le plus simple est certainement d'avoir deux processus indépendants (deux execs si tu préfères). La GUI crée les fichiers d'initialisations (éventuellement, des scripts shell) selon les préférences de l'utilisateur, puis lance l'exec qui fait les calculs. Ce dernier met à jour un fichier de temps en temps. Ce fichier est lu par la GUI pour connaitre l'état d'avancement des calculs. Ainsi, tu as une séparation complète des deux.
03/05/2007, 20h59
afrancisco

Citation:

...Ce fichier est lu par la GUI pour connaitre l'état d'avancement des calculs. Ainsi, tu as une séparation complète des deux.

Yes ! et peut-être même l'écriture sur des ports par fortran, et lecture par la GUI, mais peut-être est-ce une grosse co...ie, à voir ...

merci en tous cas !
03/05/2007, 21h03
DaZumba

Citation:

Envoyé par afrancisco

Yes ! et peut-être même l'écriture sur des ports par fortran, et lecture par la GUI

Commence par faire simple. Tu pourras compliquer apres si le besoin s'en fait sentir. Mon expérience me dit que les utilisateurs aiment bien trifouiller les fichiers de contrôle et de sortie générés par les GUI (voire se passer complètement de la GUI...). Il est donc conseillé de faire le plus transparent possible.
03/05/2007, 21h26
reptils

En tout cas si tu as des bonnes perfs numériques sur fortran c'est je pense en parti du au fait que tu utilise un compilo commerciale optimisé pour les calculs numériques. Si t'en fait de meme en C peut etre que tu auras des temps comparables.... L'experience montre que généralement (sauf calculs spécifics) c'est kiff kiff.

Perso je ferai du tout en un avec un langage si c'est possible
03/05/2007, 22h30
Mat.M

Citation:

Envoyé par afrancisco

J'y ai bien pensé, mais dans le cas où j'ai un calcul très long, j'affiche une progressbar, j'ai donc du code scientifique et du code IHM mêlés ... je ne vois alors pas comment séparer les deux pour utiliser du fortran compilé appelé par du C.

En Fortran c'est pas possible de faire une dll ?
Sinon oui comme il a été dit faire 2 exe séparément , 2 processus.
Si tu veux faire tous les calculs en C il faut faire de la programmation multithreading:
04/05/2007, 11h07
souviron34

Citation:

Envoyé par afrancisco

J'y ai bien pensé, mais dans le cas où j'ai un calcul très long, j'affiche une progressbar, j'ai donc du code scientifique et du code IHM mêlés ... je ne vois alors pas comment séparer les deux pour utiliser du fortran compilé appelé par du C.

très facile....

Mais pas pour débutants...

Faire des fonctions "vides" d'interfaçage, non liées à un outil en particulier, et suivant l'outil fabriquer cette fonction et la "linker" pour obtenir le bon exécutable..

Mais il faut très bien connaître les pointeurs, les structures, les appels croisés Fortran/C, etc...
04/05/2007, 11h35
reptils

j'ai tenté une fois ou deux la cross compilation... c'est du sport!
car meme en fortrn on doit faire face au probleme de name mangling :? avec un "_" ou pas devant les appels etc...

peut etre que je m'y étais mal pris, mais en tout cas j'avais galéré pour faire reconnaitre des deux bestiaux

EDIT: sinon on a testé au labo ton cas et bizarement meme des compilo light tels que gfortran ou g95 sont un poil plus rapides que le compilo gcc (mingw)
mingw32-gcc: 12.5sec
g95: 10.2sec
gfortran: 9.5sec

mais si tu utilises la subroutine intrinsèque "matmul" c'est normal que tu puisses atteindre les 2.8 sec (gfortran y arrvie aussi).

Ce qui me chagrine c'est que dans un cas simple et equivalent de calcul (boucle de boucle de boucle) le c est plus lent => (compilo / langage?)

Bonjour à tous,

bon, mes cours sont erminés :D

Citation:

En Fortran c'est pas possible de faire une dll ?

si, mais les prog doivent pouvoir tourner sur linux

Citation:

Mon expérience me dit que les utilisateurs aiment bien trifouiller les fichiers de contrôle et de sortie générés par les GUI (voire se passer complètement de la GUI...)

c'est vrai, on a eu des retours dans ce sens
----------------------------------------------------------
Voici le code fortran que j'ai utilisé (très classique, sans matmul)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 subroutine mult(tab1, tab2, tab3, taille) implicit none double precision, intent(inout) :: tab1(:,:), tab2(:,:), tab3(:,:) integer, intent(in) :: taille integer :: i, j, k do i = 1, taille do j = 1, taille tab3(i, j) = 0.0d0 do k = 1, taille tab3(i, j) = tab3(i, j) + tab1(i, k)*tab2(k, j) enddo enddo enddo return end subroutine mult
donc identique au code C.

Avec le compilo g95, niveau d'opt 3, j'ai 7.8s donc 50% plus rapide qu'avec mingw32-gcc.
Avec un compilateur C du commerce en "/K fast" j'ai le même temps qu'avec mingw32-gcc.

Je m'oriente donc, a priori, vers la solution suivante :
- GUI en C, librairie du style GTK ou wxwidgets
- executables fortran qui récupèrent les arguments de la ligne de commande

les échanges entre les 2 se feront par fichiers interposés, à fréquence définie par la GUI au lancement de l'exe

Normalement, les 2 sources pourront être compilés sur des os différents, sans changement des codes.

Merci à tous pour votre participation à la discussion !

Citation:
Envoyé par afrancisco
Voici le code fortran que j'ai utilisé (très classique, sans matmul)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 subroutine mult(tab1, tab2, tab3, taille) implicit none double precision, intent(inout) :: tab1(:,:), tab2(:,:), tab3(:,:) integer, intent(in) :: taille integer :: i, j, k do i = 1, taille do j = 1, taille tab3(i, j) = 0.0d0 do k = 1, taille tab3(i, j) = tab3(i, j) + tab1(i, k)*tab2(k, j) enddo enddo enddo return end subroutine mult
Souviron34 pourra peut-etre confirmer (cela fait 20 ans que j'ai plus fait de Fortran...). En Fortran j'aurais inverse les boucles sur i et j (en Fortran les elements d'un tableau bi-dimentionel avec la seconde dimention constante sont consecutif en memoire, en C ce sont les elements avec la premiere dimention constante qui le sont). C'est plus gentil pour les caches.

Citation:

Je m'oriente donc, a priori, vers la solution suivante :
- GUI en C, librairie du style GTK ou wxwidgets
- executables fortran qui récupèrent les arguments de la ligne de commande

les échanges entre les 2 se feront par fichiers interposés, à fréquence définie par la GUI au lancement de l'exe

Normalement, les 2 sources pourront être compilés sur des os différents, sans changement des codes.

Je ne suis pas sur que ce soit la bonne solution. Ce n'est pas si complique que cela d'avoir du Fortran qui appelle du C et inversement.

04/05/2007, 20h11
afrancisco

Citation:

Souviron34 pourra peut-etre confirmer (cela fait 20 ans que j'ai plus fait de Fortran...). En Fortran j'aurais inverse les boucles sur i et j (en Fortran les elements d'un tableau bi-dimentionel avec la seconde dimention constante sont consecutif en memoire, en C ce sont les elements avec la premiere dimention constante qui le sont).

Tout à fait, c'est ce que je fais habituellement, même si le compilo se charge de ce genre d'optimisation. Ici, ce n'est pas le cas car j'ai repris le bout de code C que j'ai adapté.

Citation:

Je ne suis pas sur que ce soit la bonne solution. Ce n'est pas si complique que cela d'avoir du Fortran qui appelle du C et inversement.

C'est vrai mais si les perf fortran sont meilleures, je ferais dans ce cas des appels à des routines graphiques C, ce qui nécessite de traduire les arguments (appel par valeur->par adresse) ça alourdit pas mal le code, sauf si je fais une interface ... à réfléchir aussi

Merci de cet avis, ça me fais 2 pistes de réflexion.
05/05/2007, 12h36
souviron34

Citation:

Envoyé par Jean-Marc.Bourguet

Souviron34 pourra peut-etre confirmer (cela fait 20 ans que j'ai plus fait de Fortran...). En Fortran j'aurais inverse les boucles sur i et j (en Fortran les elements d'un tableau bi-dimentionel avec la seconde dimention constante sont consecutif en memoire, en C ce sont les elements avec la premiere dimention constante qui le sont). C'est plus gentil pour les caches.

Je ne suis pas sur que ce soit la bonne solution. Ce n'est pas si complique que cela d'avoir du Fortran qui appelle du C et inversement.

Entièrement d'accord... Mes souvenirs de Fortran sont également lointains, mais maintenant que tu le dis (;) ) oui c'est bien ça je pense... : il y a inversion dans l'ordre des dimensions.

Et entièrement d'accord aussi avec ta 2ième partie.. Pourquoi s'embêter avec des fichiers (sauf si vraiment on a besoin des calculs intermédiaires) alors que le passage n'est pas si compliqué que ça.. En fait il est principalement compliqué à cause 1) de la sensibilité aux majuscules/minuscules du C vs Fortran, et 2) des chaînes de caractères et tableaux où, si mes souvenirs sont bons, en Fortran les dimensions sont ajoutées automatiquement en paramètres cachés à la fin de l'appel.

Mais un p'tit tour sur le forum Fortran devrait régler la question (traitée à moult reprises..).

Ceci dit, c'est pour ça que je mentionnais "pas pour débutants" dans mon post précédent.... Il faut maîtriser un tant soit peu les concepts des 2 côtés...
07/05/2007, 16h34
diogene

Consulter la discussion parue sur le forum C++
http://www.developpez.net/forums/sho...d.php?t=330639

C'est vrai que l'ordre du traitement peut influer sur le temps de calcul à cause de ces problèmes de cache pour de grosses matrices. Le code utilisé est transcrit du Fortran sans tenir compte de l'ordonnancement différent des tableaux en C.
J'ai vérifié en effet que si au lieu de calculer les éléments de la matrice résultat dans cet ordre (disons ligne après ligne) on les calcule colonnes après colonnes et si je copie localement chaque colonne de la deuxième matrice pour calculer une colonne du résultat, le temps de calcul est divisé par 3.
Ce facteur 3 n'existe pas pour de petites matrices (< 200*200 sur ma machine) et les temps sont comparables.
07/05/2007, 17h44
reptils

En effet je viens de tester en créant une matrice temporaire qui correspont à la transposé de B et apres je fais la multiplication ligne à ligne et au final j'ai un temps de calcul qui est de 2.3s contre 12.5s avec le meme langage
08/05/2007, 02h39
souviron34

Citation:

Envoyé par diogene

Ce facteur 3 n'existe pas pour de petites matrices (< 200*200 sur ma machine) et les temps sont comparables.

Je pense que cela provient uniquement de la taille du "chunk" de mémoire alloué à un programme par défaut par le loader...

Fuseau horaire GMT +2. Il est actuellement 22h21.