• [^] # Re: un inconvénient des templates

    Posté par . En réponse au journal Visiteurs en C++. Évalué à 1.

    C'est marrant de dire qu'un langage mort est capable de faire mieux que les existants… pourtant, il y a pas mal de langages de niche (dans la catégorie merdique, j'appelle PowerBuilder!), donc je suis intrigué qu'il n'ait pas réussi s'il est meilleur (bien que ce soit très possible, je ne le nie pas).

    Lisaac a été premier de ce benchmark

    Ce benchmark est à 2 dimensions: taille du code (et pas expressivité) à l'horizontale et vitesse d'exécution sur la hauteur, si je ne me trompe pas?
    Pour le coup (prêcher pour ma paroisse avec force mauvaise foi - comme ça c'est dit ;) - ne m'a jamais empêché de dormir) je remarque que comparer ocaml au C++ est intéressant en effet j'ai regardé sur du quad-core (C++ et les thread c'était pas ça, jusqu'au C++ après tout… toujours pas testé d'ailleurs) et je remarque qu'Ocaml est plus économe en mémoire. Sur 3 domaines. Equivalent sur 2, et il perds sur 5.

    Niveau vitesse, il atteint C++ sur 2 domaines, les autres C++ gagne.
    Code plus petit (de moitié) dans 1 cas, plus grand dans 2 cas, et équivalent dans les autres.

    Pour le coup, je te remercie, ce bench est très intéressant, même si je m'en suis un peu servi pour embêter le monde mesquinement :)

    Notes un peu plus objectives et de moins mauvaise foi:

    • dans la config ou OCaml se place le mieux, c'est à dire x86 un seul coeur, il se fait moins démonter… Problème de compilateur en retard dans les autres domaines?
    • je n'ai pas utilisé les graphiques pour comparer, ni les chiffres brut, mais la section " 2 : Are the OCaml programs faster? Approximately.". C'est celle qui m'arrange le plus après tout ;)
    • je n'ai pas pu regarder la comparaison avec "shortest C++", je sais pas pourquoi. Dommage, ça m'aurait pas mal intéressé… rien que comparer shortest C++ avec G++C++ pour voir à quel point l'optimisation est utile aurait été sympa
    • il n'y a que des algo de calcul, donc pas d'accès aux ressources, de gestion d'IHM, et caetera. Donc, comme d'hab avec les bench, résultats à n'utiliser que pour des optimisations des "zones de calcul".
    • ils mesurent la taille du code en octets, en ayant enlevé commentaires et espaces, et en compressant le texte ainsi obtenu. Franchement… je trouve difficile de trouver une façon moins pertinente de mesurer la taille des codes.