Version 1.0 de Julia

Posté par  . Édité par reno, Nÿco, Brndan, Bruno Michel, Xavier Teyssier et olivierweb. Modéré par NeoX. Licence CC By‑SA.
Étiquettes :
40
4
mar.
2012
Technologie

Julia, un langage de programmation peu connu, a atteint la version 1.0 (disponible uniquement sur Linux et Mac OS X actuellement). Le langage a été créé par des scientifiques et se veut donc optimisé pour leurs besoins : le calcul scientifique, l'apprentissage automatique (machine learning en anglais), la fouille de données (data mining), le calcul algébrique linéaire à grande échelle et le calcul distribué et parallèle.

Ils veulent un langage :

  • Très simple à apprendre, mais qui puisse aussi convenir aux « hackeurs sérieux » : Julia a une syntaxe facile à apprendre pour les utilisateurs de Matlab, tout en étant homoiconique avec des vrais macros comme le Lisp.
  • Aussi utilisable pour la programmation « normale » que Python, aussi simple pour les statistiques que R, aussi naturel pour le traitement de texte que Perl (Julia supporte les PCRE), aussi puissant pour l'algèbre linéaire que Matlab et aussi bon pour lier des programmes ensemble que le shell.

Avec une implémentation :

  • Open source avec une licence peu contraignante : Julia est sous licence MIT.
  • Aussi performante que le C tout en ayant la dynamicité de Ruby : quelques benchmarks sont sur la page d'accueil de Julia qui est dynamiquement typé avec annotation optionnelle de type (et dispatch multiple).
  • Fournissant un mode interactif et compilé.

Bref, ils sont ambitieux ! Leur manuel de référence est assez bien fait : à vous de juger…

NdA : Merci à Nÿco, olivierweb, Brndan et particulièrement à reno pour leur aide lors de la rédaction de cette dépêche.

Exemples

Hello world

Un hello world en ligne de commande utilisant l'interpolation de chaîne.

julia> whom = "world"
"world"
julia> "Hello, $whom.\n"
"Hello, world.\n"

Mandelbrot

Un exemple d'une fonction pour avoir un aperçu de la syntaxe.
Noter qu'ici z est normalement un complexe, qui tout comme les nombre rationnels, sont gérés "nativement" dans Julia.

function mandel(z)
    c = z
    maxiter = 80
    for n = 1:maxiter
        if abs(z) > 2
            return n-1
        end
        z = z^2 + c
    end
    return maxiter
end

Calcul parallèle

Le calcul parallèle est très simple, il se fait à l'aide de la macro @spawn. Le code suivant va simuler le lancement de deux pièces en même temps et compter le nombre de « face » :

function count_heads(n)
    c = 0
    for i=1:n
        c += randbit()
    end
    c
end

a = @spawn count_heads(100000000)
b = @spawn count_heads(100000000)
fetch(a)+fetch(b)

Personnellement (reno), je trouve que c'est un langage qui a de bonnes idées, avec tout de même quelques éléments qui peuvent être gênants/surprenants :

  • L'indice des tableaux commence à 1 plutôt qu'à 0 : l'héritage de Matlab probablement, mais quand on est habitué au C…
  • Pas de détection des débordements: "x::Int8 = 1000" ne retourne pas d'erreur (x vaut -24), curieux pour un langage prévu pour les scientifiques!
  • Les String bien qu'UTF-8, ont un opérateur de tableau [] qui retourne les octets sous-jacents : en UTF-8 l'accès par index étant ambigu (entre les octets et les codepoints), cela devrait être fourni par des fonctions explicites : une String UTF-8 n'est pas un tableau (oui, je sais : bikeshedding) !

Aller plus loin

  • # Beau projet!

    Posté par  (site web personnel) . Évalué à 10.

    C'est un beau projet, et s'ils le mènent à terme, ce sera sans aucun doute très utile.

    Cela dit, je doute vraiment qu'ils parviennent à faire tout ça. S'ils échouent, ils auront simplement un peu fragmenté un peu plus la communauté de l'informatique scientifique. Je pense que leurs efforts seraient sans doute mieux employés à améliorer une plateforme existante, comme Python/Scipy et sa possible intégration avec Numpy.

    • [^] # Re: Beau projet!

      Posté par  . Évalué à 5.

      Oui, enfin on pourrait dire de la même chose pour d'autres divisions des logiciels libres: deb/rpm je n'ai jamais compris l'intérêt,
      par contre Julia a une syntaxe proche de Matlab ce qui peut être un plus pour les utilisateurs,
      pareil pour KDE/Gnome avoir plusieurs options cotés interfaces graphique ça apporte un bénéfice aux utilisateurs..

    • [^] # Re: Beau projet!

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 04 mars 2012 à 18:30.

      J'ai fais pas mal de Matlab et j'ai essayé scipy et Julia dernièrement. L'avantage de Julia c'est d'intégrer les matrices au langage.
      Numpy souffre de quelques bizareries qui font que c'est un peu moins naturel à utiliser que Matlab/Julia. Je pense notamment à la différence array/matrix, à l'initialisation des matrices qui demande un peu plus de parenthèses et aux
      erreurs pas toujours très claires.

      Julia a aussi l'avantage d'utiliser LLVM et donc de bénéficier d'une infrastructure de compilation qui commence à faire ses preuves. J'imagine que c'est ça qui lui permet de si facilement battre numpy dans les benchmarks alors que c'est un langage tout jeune.

    • [^] # Re: Beau projet!

      Posté par  . Évalué à 6.

      Pour moi qui connais déjà scilab (syntaxe proche de matlab) mais rien à python, le langage julia est une vraie bonne opportunité de basculer certains développements que je fais actuellement en C. L'avantage d'un temps de développement réduit dépasse la perte de performances sur les parties non-critiques du code.

    • [^] # Re: Beau projet!

      Posté par  . É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: Beau projet!

      Posté par  . Évalué à 2.

      Scipy est en effet là pour ôter tous nos soucis en la matière…

  • # Wow !

    Posté par  (site web personnel) . Évalué à 5.

    Sur la page du projet, on peut voir un traditionnel 'BenchmarkSayMoiQuaLaPlusGrosse'. Et je suis hautement surpris des perfs du javascript, bien meilleur que les langages adaptés au calcul scientifique, et qui rivalise même avec Julia.

    J'en attendais pas tant d'un simple langage de script pour faire du web.

    • [^] # Re: Wow !

      Posté par  . Évalué à 8.

      Ben moi je m'étonne des performances de loutre bourrée de R. Je croyais qu'un langage fait pour les statisticiens, et donc qui sera utilisé pour manipuler des donner en grand nombre serait très très optimisé.

      Apparemment, il est surtout optimisé pour proposer des fonctions de stats faciles d'accès? Ces fonctions pourraient très bien être implémentées dans d'autres langages, et alors que resterait-il?

      Ou alors, comme tout benchmark qui se respecte, celui-ci n'a que peu de valeur?

      • [^] # Re: Wow !

        Posté par  . Évalué à 10.

        Ne panique pas, ils ne savent pas coder en R. Le code est plein de boucles, ce qui est une aberration en R. 

        pisum = function() {
    t = 0.0
    for (j in 1:500) {
        t = 0.0
        for (k in 1:10000) {
            t = t + 1.0/(k*k)
        }
    }
    return(t)
}

pisum2 = function() {
    t = 0.0
    for (j in 1:500) {
        t = sum(1/((1:10000)^2))
    }
    return(t)
}

pisum3 <- function() {
     return(replicate(500, sum(1/((1:10000)^2)))[1])
}

pisum4 <- function() {
     require(compiler)
     f <- cmpfun(function() {sum(1/((1:10000)^2))})
     return(replicate(500, f)[1])
}

        > system.time(pisum())
        user system elapsed
        7.180 0.000 7.197
        > system.time(pisum2())
        user system elapsed
        0.070 0.000 0.069
        > system.time(pisum3())
        user system elapsed
        0.070 0.000 0.069
        > system.time(pisum4())
        user system elapsed
        0.000 0.000 0.006

        Voila, quand on sait utiliser R, on diminue par 100 le temps d'exécution. Et en utilisant le bytecode, la fonction s'exécute trop rapidement pour la mesurer—et encore, je récupère les 500 sorties identiques dans un vecteur, donc il faudrait en plus retirer l'étape inutile d'allocation d'espace. Conclusion : comme d'hab, benchmark stupide.

        • [^] # Re: Wow !

          Posté par  . Évalué à 9.

          même chose pour numpy, un simple np.sum(1./(np.arange(1,10000)**2)) est 15 fois plus rapide que la boucle.

          • [^] # Re: Wow !

            Posté par  . Évalué à 3.

            N'hésitez pas a leur soumettre vos améliorations.
            Avec un peu de chance ils ne sont pas sectaires et vont les intégrer :)

      • [^] # Re: Wow !

        Posté par  . Évalué à 7.

        J'ai regardé le code source du test sous R et il n'est pas du tout optimisé. Ils utilisent des boucles for dans tous les sens alors que sous R, c'est à éviter et à remplacer par des apply ou assimilé. De plus, ils auraient pu utiliser le package compiler (compilateur bytes code) pour optimiser un peu le temps d'execution. On voit que le code a été fait comme un code C sans tenir compte des spécificités du langage. Bref, le test est très subjectif.

    • [^] # Re: Wow !

      Posté par  (site web personnel) . Évalué à 7.

      Je pense que c'est dû à la course à la vitesse que les navigateurs se livrent depuis l'apparition de v8. Je ne sais pas quelle est la taille de l'équipe qui s'occupe de V8 chez Google, mais j'imagine qu'il y a pas mal de monde.

      Ca m'attriste un peu parfois, parce que je n'aime pas beaucoup Javascript et je me dis que si ces efforts avaient été mis sur Python ou un autre langage plus potable, on pourrait avoir des perfs nettement meilleures aujourd'hui.

    • [^] # Re: Wow !

      Posté par  (site web personnel) . Évalué à 3.

      J'en attendais pas tant d'un simple langage de script pour faire du web.

      Quand tu sais que Google a mis toute sa force pour en optimiser l'exécution, c'est pas si surprenant que ça, non?

  • # LLVM

    Posté par  (Mastodon) . Évalué à 4.

    À noter que Julia utilise LLVM et qu'on en avait parlé dans la news sur la sortie de LLVM 3.0

  • # Surprenant que le Fortran ne soit pas mentionné

    Posté par  . É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

    • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

      Posté par  . Évalué à 1.

      Ils donnent un exemple pour appeler des librairies C ou Fortran: http://julialang.org/manual/calling-c-and-fortran-code/

      • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

        Posté par  . É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.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 9.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

        Posté par  . É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).

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 4.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

              Posté par  . É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  . Évalué à 2.

              COMMON c'est une sorte d'espace de nom où l'on peut changer les noms localement ?

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

                Posté par  . Évalué à 3.

                Oui, c'est une bonne description. Un COMMON est une zone de mémoire commune (d'où son nom) à plusieurs parties du programme, et elle est le plus souvent nommée, ce qui fait qu'on peut effectivement la voir comme un espace de nom. Les sous-zones qu'elle contient sont allouées à des variables dont le nom peut changer localement, même si le bon sens voudrait au minimum que l'on garde les mêmes noms à chaque endroit où le COMMON est utilisé.

                • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

                  Posté par  (site web personnel) . Évalué à 9.

                  COMMON vient de l'époque où les grosses machines avaient peu de mémoire (1Mo, c'était beaucoup) et on utilisait des programmes segmentés. Un programme était constitué d'un bloc de commons, d'un bout de programme principal et de segments. Il n'y avait à la fois qu'un seul segment en mémoire. Quand on chargeait un nouveau segment, les commons restaient et le programme pouvait continuer avec le nouveau segment en conservant les variables stockées dans le bloc de commons. Je crois me souvenir que la taille des segments était limitée à 64k. Ça vous fait sourire ?

                  Je me souviens aussi de l'arrivée de la disponibilité en FORTRAN de "implicit none". Il m'a fallu persuader mes techniciens de l'obligation de l'utiliser.

                  Bon tout ça, c'est de l'archéologie !

                  • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

                    Posté par  . Évalué à 3.

                    Je confirme, j'ai programmé en Fortran IV sur DEC PDP, certaines machines avaient une plantureuse mémoire de 128 Kb. Le problème était que parfois, on avait besoin en même temps de fonctions qui étaient dans des segments différents… fallait ruser!

    • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

      Posté par  . Évalué à 2.

      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.

      J'ai regardé un peu rapidement, je trouve OpenMP tout aussi puissant.

      Sinon c'est quoi l'aliasing ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

        Posté par  . É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.

    • [^] # Re: Surprenant que le Fortran ne soit pas mentionné

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 05 mars 2012 à 08:49.

      Ce n'est peut être pas très constuctif, mais à chque fois que j'entends parler du Fortran, je ne peux pas m'empêcher de penser au texte Real programmers don't use Pascal (forcément, puisqu'ils utilisent Fortran):

      http://www.pbm.com/~lindahl/real.programmers.html

      S'il y a des quiche eaters qui ne connaissent pas encore ce texte, régalez vous!

  • # Le langage kifétou

    Posté par  . Évalué à 10.

    En lisant la description et les buts à atteindre, je me dis:
    "sont vraiment cons les autres d'avoir seulement un ou deux des avantages de Julia!"
    Et on peut dire que certains sont limités pour raisons historiques, ou autre.

    Ou alors on peut se dire…

    Xkcd-Standards

    C'est sûr, c'est prometteur sur le papier et j'espère que ce sera aussi bien que ce que l'on en dit. Mais ça fait tellement présentation marketing que j'ai du mal à y croire (aussi simple que le plus simple, aussi puissant que le plus puissant, aussi pratique que le plus pratique, aussi rapide que le plus rapide, etc. et tout ça mesdames et messieurs, dans un seul produit unique!).

    Bonne chance à eux en tout cas!

    • [^] # Re: Le langage kifétou

      Posté par  (site web personnel) . Évalué à 5.

      Le problème c'est qu'en calcul scientifique, il n'y a pas grand chose entre Matlab/Octave/R/Numpy qui sont lents et Fortran/C qui sont rapides.
      Le problème de C/C++, c'est qu'on perd du temps de développement pour des conneries et certaines choses qui s'écrivent en une ligne de Matlab (notamment quand on utilise des matrices) prennent 20 lignes de C.

      Du coup ce qui se fait c'est qu'on écrit en Matlab et quand on se rend compte que ça avance pas, on fais des bouts en C. Julia a l'avantage de permettre des perfs proches de C et une syntaxe agréable quand on bosse avec des matrices.

      • [^] # Re: Le langage kifétou

        Posté par  . Évalué à 3.

        Ou bien, on fait une partie du code sous R et les parties critiques en C avec openMP en prime si on veut. On garde ainsi la flexibilité de R et on gagne en vitesse sur le code critique. R s'interface très facilement avec C et fortran (voir d'autres) (Voir fonction .C, .Call …). Ce qui permet de ne pas réinventer la roue.

  • # Macros et (Common) Lisp

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 05 mars 2012 à 13:50.

    Tiens, pour comparer au Common Lisp. Supposons que l'on veuille écrire une macro qui exécute des opérations séquentielles dans l'ordre inverse (c'est totalement inutile mais il me semble que ce n'est pas trivial à faire dans d'autres langages). Par exemple :

    (reverse-exec
 (print 1)
 (print 2)
 (print 3)
 (print 4))

    Qui exécuterait :

    (PROGN (PRINT 4) (PRINT 3) (PRINT 2) (PRINT 1))
=> 4 3 2 1

    (progn est équivalent au begin)

    C'est facile en Lisp puisque le code est une liste et que le Lisp manipule très bien ce type données.
    Le code en Common Lisp est le suivant :

    (defmacro reverse-exec (&body body)
  `(progn
     ,@(reverse body)))

    Quel serait le code équivalent en Julia ?

    PS : Ce n'est pas un concours de qui a la plus grosses mais juste de la curiosité.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.