Je n'ai jamais bien réfléchi aux avantages des langages fonctionnels pour l'analyse numérique. Je ne connais pas Haskell mais je connais un peu OCaml et j'avoue ne jamais avoir réfléchi à ce qu'ils peuvent apporter en analyse numérique.
Mathematica (qui est très fonctionnel) et le F# (Un Objective Caml adapté à .NET) sont utilisés, notamment en Finance. Je crois aussi avoir qu'une université américaine réputée à choisit de faire passer le fonctionnel avant l'orienté objet dans son cursus. Il est donc probable que le fonctionnel soit de plus en plus utilisé par les jeunes générations.
Le Python est assez agréable comme langage de haut niveau, mais on reste dans les langages dans lesquels la "boucle" est "interdite" pour des raisons de performance (Comme Matlab (vieilles versions)/Mathematica/…). Je n'ai jamais pu m'y faire et il y a encore de nombreux algos qui ne s'expriment pas simplement sans boucle. Leur version "vectorielle" est souvent inefficace (par exemple, calculer les distances mutuelles entre n points du plan).
Julia, développé par des personnes du MIT, semble mélanger les avantages d'un langage dynamique avec un JIT, comme les dernières versions de Matlab. Du coup, on peut faire des boucles sans perdre trop de performance. C'est encore très jeune, mais cela à l'air intéressant : Julia. D'autres personnes pensent mettre un JIT dans Python. Bref, cela bouge pas mal.
Du coup, je préfère rester avec ma "vieille casserole" qui marche très bien : Fortran 2003.
Posté par magnolia .
En réponse à la dépêche LLVM 3.4 et Clang 3.4.
Évalué à 7.
Dernière modification le 26 janvier 2014 à 13:06.
Les codes numériques sont aujourd'hui majoritairement écrits en MATLAB/Python/C++/C/Fortran. En langage compilés il reste donc C++/C/Fortran.
Une grande partie de la MKL (Math Kernel Library, développée par Intel) est écrite en C, pour que tout soit optimisé aux petits oignons. Une telle optimisation nécessite une très bonne connaissance du compilateur et du processeur pour lequel vous optimisez. Intel sait le faire, mais il ne doit pas y avoir grand monde qui sait le faire correctement.
De nombreux code sont aujourd'hui écrits en C++ et certains codes sont très bien programmés. Cependant, l'écriture de codes numériques nécessitent une bonne connaissance en physique, mathématique, informatique. Les journées ayant un nombre limitées d'heures, il est bon de ne pas se surcharger en "connaissances" informatique. En analyse numérique, il est essentiel de bien maitriser :
- La gestion de la mémoire
- L'OpenMP, le MPI
- Des Design Pattern qui ne ruinent pas la performance
C'est déjà beaucoup pour une personne qui doit connaître aussi de la physique et des maths (surtout cela d'ailleurs). Se lancer dans l'apprentissage et la maitrise du C++ est une longue route, et l'optimisation du C++ est parfois "surprenante". Par exemple, si vous écrivez :
for (i = 0; i < size; i++) {
v[i] = pow((double) (i+1), -2);
}
vous verrez que le "vectorizer" va se comporter de manière très différente selon : le type de vecteur utilisé ("vecteur" C, ou std::vector), le compilateur utilisé (gcc ou icc) ainsi que sa version. Il y a 2 ans, icc n'était pas fichu de vectoriser le code lorsque v était un std::vector. J'en avais discuté avec des développeurs Intel qui confirmait ce problème (Voir ici std::vector et vectorisation). Depuis, ce problème a été résolu sur icc, mais une recherche rapide montre que les compilateurs microsoft ont encore du mal avec cela : Problème de vectorisation en C++. J'imagine qu'il y a encore de nombreux problèmes, même avec icc et gcc.
Du fait de l'inexistence de pointeurs (ou plutôt du fait qu'ils ne peuvent pas pointer vers n'importe quoi), le Fortran est bien plus facile à optimiser pour les compilateurs et ce genre de surprise n'existe pas vraiment. C'est un langage facile à utiliser, efficace et propre. Il y a même de très bon bouquins sur les Designs Pattern avec des exemples en Fortran : Design Pattern.
Malheureusement, de nombreux code Fortran sont vraiment programmés avec les pieds d'un point de vue d'un informaticien. Ce n'est pas propre au language, mais aux capacités informatiques des programmeurs qui sont le plus souvent tout d'abord des matheux et des physiciens. Si vous leur donnez entre les mains du C++, vous courez à la catastrophe.
J'ai écrit un code de 30 000 lignes il y a 2 ans en Fortran 2003 (orienté objet) + OpenMP + MPI + MKL. Si c'était à refaire, je choisirai à nouveau ce langage. Alors laissez nous le Fortran. Merci.
Posté par magnolia .
En réponse à la dépêche Version 1.0 de Julia.
Évalué à 5.
Dernière modification le 05 mars 2012 à 00:56.
Pour faire du calcul parallèle scientifique en C/C++ ou en Fortran, il y a actuellement plusieurs méthodes utilisées.
OpenMP: On insère des directives en commentaires et un compilateur qui est compatible OpenMP (gcc/icc par exemple) et le compilateur parallélise le tout. Le plus souvent, OpenMP est utilisé pour paralléliser des boucles, mais c'est beaucoup trop réducteur que de le cantonner à cela. A l'exécution, ce sont plusieurs threads qui apparaissent.
MPI: C'est souvent utiliser pour paralléliser des gros bout de codes. Par exemple, avoir plusieurs simulations qui tournent avec différentes conditions initiales, et les synchroniser de temps à autre pour changer quelques paramètres. Cela nécessite une librairie et des appels de fonction. A l'exécution, ce sont plusieurs processus qui sont exécutés et qui s'envoient des "messages" d'ou le nom de MPI (Message Passing Interface).
Ces deux méthodes sont très populaires en Fortran comme en C et il est possible de les mélanger. Cependant, de nombreux ajouts au Fortran 2008 tendent à remplacer ces deux méthodes. Ils ont l'avantage de faire partie du language et d'être plus faciles à utiliser.
Pointer aliasing
On dit qu'on a un aliasing de pointeur lorsque deux pointeurs pointent vers la même case mémoire. La plupart du temps cela n'arrive pas, et le compilateur peut optimiser le code. Par exemple en C, dans le code suivant
void test(int *a, int *array, int size) {
int k;
for (k = 0, k less size, ++k) {
array[k] = array[k] * (* a);
}
}
il parrait absurder d'appeler le code avec
test(array + 2, array, n);
qui va multiplier par a[2] a[0], a[1] et a[2] et par a2 les valeurs dans a[3], …, a[n]. En général personne ne va appeler le code comme cela, mais le compilateur ne peut pas en être sur.
Supposons que le compilateur ait moyen de savoir qu'il n'y a pas d'aliasing (dans notre exemple a et &array[2] pointent vers la même case mémoire) il peut en déduire que la boucle peut être exécutée dans n'importe quel sens et même parallélisée.
Je suis d'accord avec vous : utiliser le COMMON aujourd'hui dans un code est une honte. C'est un vieil héritage qui n'a rien à faire dans le language aujourd'hui. Il est seulement là pour garder la compatibilité avec les vieilles versions du language. Il y a aussi le GOTO calculé qui est toujours présent et qui est aussi une honte aujourd'hui.
C'est pourquoi, il ne faut surtout pas apprendre le Fortran sur les sites internet ou en lisant du code produit par une personne qui code comme un cochon (l'essentiel des codes en Fortran malheureusement) mais plutôt par un bon bouquin comme http://www.amazon.com/Explained-Numerical-Mathematics-Scientific-Computation/dp/0199601429/ref=sr_1_1?ie=UTF8&qid=1330902466&sr=8-1 . Vous avez tout à fait raison de dire que ce sont des langages. Je dirai qu'il y a le Fortran 77 (et ses horreurs) et le Fortran tel qu'il est pensé depuis la version 90 et qui est devenu ensuite le Fortran 2003 (ajout des objets) puis Fortran 2008 (Ajout des coarray). C'est un fabuleux language pour le calcul scientifique. Pour éviter la confusion, certaines personnes utilisent le mot "Modern Fortran" pour le Fortran >= 90.
Pour revenir au problème de l'aliasing, ce qui est important est que le compilateur sache lorsqu'il n'y en a pas pour pouvoir optimiser le code. En Fortran, le compilateur a beaucoup plus d'informations qu'en C car :
- Les pointeurs sont très rarement utilisés
- L'arithmétique des pointeurs n'existe pas
- Un pointeur ne peut pas pointer vers n'importe quelle variable. Pour qu'un pointeur pointe vers l'adresse mémoire occupée par la variable x, il faut que x soit déclarée comme target. Cela limite drastiquement les cibles d'un pointeur et le compilateur peut optimiser le code en sachant que le pointeur ne peut pas pointer vers certaines cases mémoires.
Je n'ai plus le lien ici, mais lorsque j'ai fais le choix du Fortran pour mon projet, j'ai comparé le C++ et le Fortran et j'ai été amené à poser quelques questions sur les forums des compilateurs Intel. Je donnais des exemples qui étaient optimisés par le compilateur Fortran mais qui ne l'était pas par le compilateur C++. Un développeur d'Intel m'avait d'ailleurs dit qu'on ne pouvait pas espérer le même niveau d'optimisation qu'en Fortran en C/C++ sans donner des directives aux compilateurs assez complexes.
PS: Désolé pour le COMMON. Je comprends qu'on en fasse des cauchemards. Je souhaite juste faire partager le fait que le Fortran moderne est un excellent language et qu'il est malheureusement injustement dénigré car beaucoup pensent que le Fortran est bloqué au Fortran 77, ce qui est très loin d'être le cas.
Effectivement, votre exemple est parlant et j'ai surement été un peu vite. J'ai appris le C dans le Kernighan & Ritchie et il me semble qu'ils disent bien que c'est quasiment la même chose. Il n'empêche, le bound checking reste un problème.
J'ai vu le lien que vous avez donné, qui consiste à faire un hack du C pour faire ce que fait le Fortran. Je vais regarder plus en détail.
La différence entre le Fortran et le C est que justement, le Fortran ne permet pas d'écrire quelque chose comme ptr = 1589. Le Fortran possède des pointers (rarement utiles en Fortran), des smarts pointers et des arrays. Cependant, l'arithmétique des pointeurs est interdite, ce qui permet de sécuriser grandement les codes. C'est une des raisons pour laquelle je ne suis pas fan de C/C++ pour le calcul scientifique.
De plus, pour la parallelisation, les compilateurs C/C++ sont souvent très gênés par l'aliasing de pointeurs, problème qui n'existe pas en Fortran. Je sais bien que le C99 a ajouté le keyword "restrict", mais il n'existe pas en C++ et il semble très mal implémenté dans les compilateurs C (voir http://people.freebsd.org/~lstewart/articles/cpumemory.pdf page 50, en bas à droite).
Posté par magnolia .
En réponse à la dépêche Version 1.0 de Julia.
Évalué à 2.
Dernière modification le 04 mars 2012 à 21:16.
La force de Matlab est son côté tout intégré. C'est pour cela que le gens délaissent le Fortran/C++.
En tant qu' "environnement intégré", Python/Scipy/Numpy/Matplotlib/Mayavi existe et semblent être d'assez bonne qualité. Il serait plus utile de contribuer à ces projets.
En même temps, je pense que les gens qui sont derrière Juila apprendront beaucoup, et c'est pour cela que cela reste une bonne initiative. Seulement, si ils espèrent des utilisateurs en masse, je crois qu'il vont être déçus.
Je suis très surpris que le Fortran ne soit pas mentionné comme influence. En calcul scientifique haute performance les deux langages qui dominent sont le C++ et le Fortran.
Le Fortran 2008 est un excellent langage pour le calcul scientifique.
- Il comporte des constructions propres. Par exemple, on peut dire qu'il existe deux types de boucles : les boucles inconditionnelles (on sait combien de fois on va l'exécuter avant de l'exécuter) et les boucles conditionnelles (on ne sait pas). Généralement, on implémente le premier type de boucle avec un for en C et le second avec un while en C. Mais un for en C n'est qu'un while caché. Par exemple, il est possible d'écrire for (i = 0, i less n, ++i) et de changer le n à l'intérieur de la boucle, ce qui en fait une boucle conditionnelle. Le Fortran rend ce genre de choses impossibles.
- Il possède des array, ce que ne possède pas le C. En C, il n'existe pas d'array, mais tout est simulé par des pointeurs. Par exemple a[k] n'est qu'un raccourcit pour *(a+k). Cela rend impossible de compiler le programme pour qu'il vérifie qu'on accède pas à un élément en dehors du tableau. Le C++ essaie de s'en sortir avec la STL et Boost, mais les compilateurs sont incapables d'optimiser correctement ces codes souvent à cause des problèmes d'aliasing de pointeurs.
- Les smart pointers, qui existent dans Boost, existent en Fortran dans le language depuis le Fortran 90 (allocatable components). Et je n'ai jamais vu de programmeur Fortran devenu fou à cause d'un problème de version de Boost ou d'une message de Template incompréhensible!
- Il possède la notion de Coarray, qui permet de faire du calcul parallèle bien plus simplement que le MPI. C'est moins puissant mais largement plus facile à gérer.
Malheureusement, ce language est souvent ignoré car beaucoup de programmeurs Fortran écrivent des choses horribles. Cependant, le language a énormément de qualités souvent ignorées.
[^] # Re: mélange de langage ?
Posté par magnolia . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 1.
Je n'ai jamais bien réfléchi aux avantages des langages fonctionnels pour l'analyse numérique. Je ne connais pas Haskell mais je connais un peu OCaml et j'avoue ne jamais avoir réfléchi à ce qu'ils peuvent apporter en analyse numérique.
Mathematica (qui est très fonctionnel) et le F# (Un Objective Caml adapté à .NET) sont utilisés, notamment en Finance. Je crois aussi avoir qu'une université américaine réputée à choisit de faire passer le fonctionnel avant l'orienté objet dans son cursus. Il est donc probable que le fonctionnel soit de plus en plus utilisé par les jeunes générations.
Le Python est assez agréable comme langage de haut niveau, mais on reste dans les langages dans lesquels la "boucle" est "interdite" pour des raisons de performance (Comme Matlab (vieilles versions)/Mathematica/…). Je n'ai jamais pu m'y faire et il y a encore de nombreux algos qui ne s'expriment pas simplement sans boucle. Leur version "vectorielle" est souvent inefficace (par exemple, calculer les distances mutuelles entre n points du plan).
Julia, développé par des personnes du MIT, semble mélanger les avantages d'un langage dynamique avec un JIT, comme les dernières versions de Matlab. Du coup, on peut faire des boucles sans perdre trop de performance. C'est encore très jeune, mais cela à l'air intéressant : Julia. D'autres personnes pensent mettre un JIT dans Python. Bref, cela bouge pas mal.
Du coup, je préfère rester avec ma "vieille casserole" qui marche très bien : Fortran 2003.
[^] # Re: mélange de langage ?
Posté par magnolia . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 7. Dernière modification le 26 janvier 2014 à 13:06.
Les codes numériques sont aujourd'hui majoritairement écrits en MATLAB/Python/C++/C/Fortran. En langage compilés il reste donc C++/C/Fortran.
Une grande partie de la MKL (Math Kernel Library, développée par Intel) est écrite en C, pour que tout soit optimisé aux petits oignons. Une telle optimisation nécessite une très bonne connaissance du compilateur et du processeur pour lequel vous optimisez. Intel sait le faire, mais il ne doit pas y avoir grand monde qui sait le faire correctement.
De nombreux code sont aujourd'hui écrits en C++ et certains codes sont très bien programmés. Cependant, l'écriture de codes numériques nécessitent une bonne connaissance en physique, mathématique, informatique. Les journées ayant un nombre limitées d'heures, il est bon de ne pas se surcharger en "connaissances" informatique. En analyse numérique, il est essentiel de bien maitriser :
- La gestion de la mémoire
- L'OpenMP, le MPI
- Des Design Pattern qui ne ruinent pas la performance
C'est déjà beaucoup pour une personne qui doit connaître aussi de la physique et des maths (surtout cela d'ailleurs). Se lancer dans l'apprentissage et la maitrise du C++ est une longue route, et l'optimisation du C++ est parfois "surprenante". Par exemple, si vous écrivez :
vous verrez que le "vectorizer" va se comporter de manière très différente selon : le type de vecteur utilisé ("vecteur" C, ou std::vector), le compilateur utilisé (gcc ou icc) ainsi que sa version. Il y a 2 ans, icc n'était pas fichu de vectoriser le code lorsque v était un std::vector. J'en avais discuté avec des développeurs Intel qui confirmait ce problème (Voir ici std::vector et vectorisation). Depuis, ce problème a été résolu sur icc, mais une recherche rapide montre que les compilateurs microsoft ont encore du mal avec cela : Problème de vectorisation en C++. J'imagine qu'il y a encore de nombreux problèmes, même avec icc et gcc.
Du fait de l'inexistence de pointeurs (ou plutôt du fait qu'ils ne peuvent pas pointer vers n'importe quoi), le Fortran est bien plus facile à optimiser pour les compilateurs et ce genre de surprise n'existe pas vraiment. C'est un langage facile à utiliser, efficace et propre. Il y a même de très bon bouquins sur les Designs Pattern avec des exemples en Fortran : Design Pattern.
Malheureusement, de nombreux code Fortran sont vraiment programmés avec les pieds d'un point de vue d'un informaticien. Ce n'est pas propre au language, mais aux capacités informatiques des programmeurs qui sont le plus souvent tout d'abord des matheux et des physiciens. Si vous leur donnez entre les mains du C++, vous courez à la catastrophe.
J'ai écrit un code de 30 000 lignes il y a 2 ans en Fortran 2003 (orienté objet) + OpenMP + MPI + MKL. Si c'était à refaire, je choisirai à nouveau ce langage. Alors laissez nous le Fortran. Merci.
[^] # Re: Surprenant que le Fortran ne soit pas mentionné
Posté par magnolia . En réponse à la dépêche Version 1.0 de Julia. Évalué à 4.
Si vous venez de passer une semaine avec un vieux programme FORTRAN 77 écrit avec les pieds, il y a aussi cela pour se détendre :
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4c8623dae8615db5
[^] # Re: Beau projet!
Posté par magnolia . En réponse à la dépêche Version 1.0 de Julia. Évalué à 2.
Je viens de voir la présentation donnée à Stanford. C'est effectivement très impressionnant. Il serait bien de mettre le lien dans la news: http://ee380.stanford.edu/cgi-bin/videologger.php?target=120229-ee380-300.asx
[^] # Re: Surprenant que le Fortran ne soit pas mentionné
Posté par magnolia . En réponse à la dépêche Version 1.0 de Julia. Évalué à 5. Dernière modification le 05 mars 2012 à 00:56.
Pour faire du calcul parallèle scientifique en C/C++ ou en Fortran, il y a actuellement plusieurs méthodes utilisées.
OpenMP: On insère des directives en commentaires et un compilateur qui est compatible OpenMP (gcc/icc par exemple) et le compilateur parallélise le tout. Le plus souvent, OpenMP est utilisé pour paralléliser des boucles, mais c'est beaucoup trop réducteur que de le cantonner à cela. A l'exécution, ce sont plusieurs threads qui apparaissent.
MPI: C'est souvent utiliser pour paralléliser des gros bout de codes. Par exemple, avoir plusieurs simulations qui tournent avec différentes conditions initiales, et les synchroniser de temps à autre pour changer quelques paramètres. Cela nécessite une librairie et des appels de fonction. A l'exécution, ce sont plusieurs processus qui sont exécutés et qui s'envoient des "messages" d'ou le nom de MPI (Message Passing Interface).
Ces deux méthodes sont très populaires en Fortran comme en C et il est possible de les mélanger. Cependant, de nombreux ajouts au Fortran 2008 tendent à remplacer ces deux méthodes. Ils ont l'avantage de faire partie du language et d'être plus faciles à utiliser.
Pointer aliasing
On dit qu'on a un aliasing de pointeur lorsque deux pointeurs pointent vers la même case mémoire. La plupart du temps cela n'arrive pas, et le compilateur peut optimiser le code. Par exemple en C, dans le code suivant
void test(int *a, int *array, int size) {
int k;
}
il parrait absurder d'appeler le code avec
test(array + 2, array, n);
qui va multiplier par a[2] a[0], a[1] et a[2] et par a2 les valeurs dans a[3], …, a[n]. En général personne ne va appeler le code comme cela, mais le compilateur ne peut pas en être sur.
Supposons que le compilateur ait moyen de savoir qu'il n'y a pas d'aliasing (dans notre exemple a et &array[2] pointent vers la même case mémoire) il peut en déduire que la boucle peut être exécutée dans n'importe quel sens et même parallélisée.
[^] # Re: Surprenant que le Fortran ne soit pas mentionné
Posté par magnolia . En réponse à la dépêche Version 1.0 de Julia. Évalué à 5.
Je suis d'accord avec vous : utiliser le COMMON aujourd'hui dans un code est une honte. C'est un vieil héritage qui n'a rien à faire dans le language aujourd'hui. Il est seulement là pour garder la compatibilité avec les vieilles versions du language. Il y a aussi le GOTO calculé qui est toujours présent et qui est aussi une honte aujourd'hui.
C'est pourquoi, il ne faut surtout pas apprendre le Fortran sur les sites internet ou en lisant du code produit par une personne qui code comme un cochon (l'essentiel des codes en Fortran malheureusement) mais plutôt par un bon bouquin comme http://www.amazon.com/Explained-Numerical-Mathematics-Scientific-Computation/dp/0199601429/ref=sr_1_1?ie=UTF8&qid=1330902466&sr=8-1 . Vous avez tout à fait raison de dire que ce sont des langages. Je dirai qu'il y a le Fortran 77 (et ses horreurs) et le Fortran tel qu'il est pensé depuis la version 90 et qui est devenu ensuite le Fortran 2003 (ajout des objets) puis Fortran 2008 (Ajout des coarray). C'est un fabuleux language pour le calcul scientifique. Pour éviter la confusion, certaines personnes utilisent le mot "Modern Fortran" pour le Fortran >= 90.
Pour revenir au problème de l'aliasing, ce qui est important est que le compilateur sache lorsqu'il n'y en a pas pour pouvoir optimiser le code. En Fortran, le compilateur a beaucoup plus d'informations qu'en C car :
- Les pointeurs sont très rarement utilisés
- L'arithmétique des pointeurs n'existe pas
- Un pointeur ne peut pas pointer vers n'importe quelle variable. Pour qu'un pointeur pointe vers l'adresse mémoire occupée par la variable x, il faut que x soit déclarée comme target. Cela limite drastiquement les cibles d'un pointeur et le compilateur peut optimiser le code en sachant que le pointeur ne peut pas pointer vers certaines cases mémoires.
Je n'ai plus le lien ici, mais lorsque j'ai fais le choix du Fortran pour mon projet, j'ai comparé le C++ et le Fortran et j'ai été amené à poser quelques questions sur les forums des compilateurs Intel. Je donnais des exemples qui étaient optimisés par le compilateur Fortran mais qui ne l'était pas par le compilateur C++. Un développeur d'Intel m'avait d'ailleurs dit qu'on ne pouvait pas espérer le même niveau d'optimisation qu'en Fortran en C/C++ sans donner des directives aux compilateurs assez complexes.
PS: Désolé pour le COMMON. Je comprends qu'on en fasse des cauchemards. Je souhaite juste faire partager le fait que le Fortran moderne est un excellent language et qu'il est malheureusement injustement dénigré car beaucoup pensent que le Fortran est bloqué au Fortran 77, ce qui est très loin d'être le cas.
[^] # Re: Surprenant que le Fortran ne soit pas mentionné
Posté par magnolia . En réponse à la dépêche Version 1.0 de Julia. Évalué à 4.
Effectivement, votre exemple est parlant et j'ai surement été un peu vite. J'ai appris le C dans le Kernighan & Ritchie et il me semble qu'ils disent bien que c'est quasiment la même chose. Il n'empêche, le bound checking reste un problème.
J'ai vu le lien que vous avez donné, qui consiste à faire un hack du C pour faire ce que fait le Fortran. Je vais regarder plus en détail.
La différence entre le Fortran et le C est que justement, le Fortran ne permet pas d'écrire quelque chose comme ptr = 1589. Le Fortran possède des pointers (rarement utiles en Fortran), des smarts pointers et des arrays. Cependant, l'arithmétique des pointeurs est interdite, ce qui permet de sécuriser grandement les codes. C'est une des raisons pour laquelle je ne suis pas fan de C/C++ pour le calcul scientifique.
De plus, pour la parallelisation, les compilateurs C/C++ sont souvent très gênés par l'aliasing de pointeurs, problème qui n'existe pas en Fortran. Je sais bien que le C99 a ajouté le keyword "restrict", mais il n'existe pas en C++ et il semble très mal implémenté dans les compilateurs C (voir http://people.freebsd.org/~lstewart/articles/cpumemory.pdf page 50, en bas à droite).
[^] # Re: Surprenant que le Fortran ne soit pas mentionné
Posté par magnolia . En réponse à la dépêche Version 1.0 de Julia. Évalué à 2. Dernière modification le 04 mars 2012 à 21:16.
La force de Matlab est son côté tout intégré. C'est pour cela que le gens délaissent le Fortran/C++.
En tant qu' "environnement intégré", Python/Scipy/Numpy/Matplotlib/Mayavi existe et semblent être d'assez bonne qualité. Il serait plus utile de contribuer à ces projets.
En même temps, je pense que les gens qui sont derrière Juila apprendront beaucoup, et c'est pour cela que cela reste une bonne initiative. Seulement, si ils espèrent des utilisateurs en masse, je crois qu'il vont être déçus.
# Surprenant que le Fortran ne soit pas mentionné
Posté par magnolia . En réponse à la dépêche Version 1.0 de Julia. Évalué à 7.
Je suis très surpris que le Fortran ne soit pas mentionné comme influence. En calcul scientifique haute performance les deux langages qui dominent sont le C++ et le Fortran.
Le Fortran 2008 est un excellent langage pour le calcul scientifique.
- Il comporte des constructions propres. Par exemple, on peut dire qu'il existe deux types de boucles : les boucles inconditionnelles (on sait combien de fois on va l'exécuter avant de l'exécuter) et les boucles conditionnelles (on ne sait pas). Généralement, on implémente le premier type de boucle avec un for en C et le second avec un while en C. Mais un for en C n'est qu'un while caché. Par exemple, il est possible d'écrire for (i = 0, i less n, ++i) et de changer le n à l'intérieur de la boucle, ce qui en fait une boucle conditionnelle. Le Fortran rend ce genre de choses impossibles.
- Il possède des array, ce que ne possède pas le C. En C, il n'existe pas d'array, mais tout est simulé par des pointeurs. Par exemple a[k] n'est qu'un raccourcit pour *(a+k). Cela rend impossible de compiler le programme pour qu'il vérifie qu'on accède pas à un élément en dehors du tableau. Le C++ essaie de s'en sortir avec la STL et Boost, mais les compilateurs sont incapables d'optimiser correctement ces codes souvent à cause des problèmes d'aliasing de pointeurs.
- Les smart pointers, qui existent dans Boost, existent en Fortran dans le language depuis le Fortran 90 (allocatable components). Et je n'ai jamais vu de programmeur Fortran devenu fou à cause d'un problème de version de Boost ou d'une message de Template incompréhensible!
- Il possède la notion de Coarray, qui permet de faire du calcul parallèle bien plus simplement que le MPI. C'est moins puissant mais largement plus facile à gérer.
Malheureusement, ce language est souvent ignoré car beaucoup de programmeurs Fortran écrivent des choses horribles. Cependant, le language a énormément de qualités souvent ignorées.
Vous pouvez par exemple lire ce livre sur le calcul scientifique orienté objet avec des exemples en C++ et en Fortran, pour vous rendre compte qu'il est possible d'écrire des programmes très bien structurés dans ce language: http://www.amazon.com/Scientific-Software-Design-The-Object-Oriented/dp/0521888131/ref=sr_1_5?ie=UTF8&qid=1330889360&sr=8-5