"je suis intrigué qu'il n'ait pas réussi s'il est meilleur"
Le code du compilo n'était pas simple du tout (détermination du type réel de chaque objet). Et le dev principal a coupé les ponts du jour au lendemain.
Les codes c++ et C utilisent massivement openMP qui n'existe pas dans le monde ocaml.
"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?"
Non, c'est juste l'affichage de ce graph, il est intéressant car la case la plus intéressante est en bas à droite : compact et rapide.
"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."
Au contraire, cela évite de parler de la définition de la "ligne de code". La compression limite l'augmentation de taille des langage verbeux par rapport à ceux abusant des symboles.
"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"."
C'est vrai. Mais les problèmes de logiciels dans ce domaine, sont liés aux algos utilisés. Il faut aussi que la taille du benchmark reste accessible aux codeurs. Il y a aussi des benchs manipulant des symboles (de mémoire, le truc qui manipule de l'ADN).
[^] # Re: un inconvénient des templates
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2. Dernière modification le 25 avril 2013 à 16:11.
"je suis intrigué qu'il n'ait pas réussi s'il est meilleur"
Le code du compilo n'était pas simple du tout (détermination du type réel de chaque objet). Et le dev principal a coupé les ponts du jour au lendemain.
Les codes c++ et C utilisent massivement openMP qui n'existe pas dans le monde ocaml.
"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?"
Non, c'est juste l'affichage de ce graph, il est intéressant car la case la plus intéressante est en bas à droite : compact et rapide.
"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."
Au contraire, cela évite de parler de la définition de la "ligne de code". La compression limite l'augmentation de taille des langage verbeux par rapport à ceux abusant des symboles.
"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"."
C'est vrai. Mais les problèmes de logiciels dans ce domaine, sont liés aux algos utilisés. Il faut aussi que la taille du benchmark reste accessible aux codeurs. Il y a aussi des benchs manipulant des symboles (de mémoire, le truc qui manipule de l'ADN).
"La première sécurité est la liberté"