Je suis d'accord qu'il ne s'agit que d'un bench, mais ce bench a le bon goût d'être relativement complet par rapport aux autres puisqu'il aborde plusieurs types d'algo différents, et n'oublie pas de tester la consommation mémoire. Si tu veux encore parler de produit matriciel ou de calcul scientifique, je ne me battrai pas sur ce point pour la simple raison que je ne connais pas assez ce domaine, et il est possible que la stratégie d'allocation mémoire de ocaml (ou d'un autre équivalent) soit peu compatible avec les données et algorithmes en jeu.
par construction, il y a un overhead si la gestion d'une ressource est automatique. (Si tu n'est pas d'accord avec cette affirmation, je vois pas bien comment t'en convaincre...)
Ben je suis désolé je suis pas d'accord. Sur les processeurs modernes par exemple, les règles d'optimisation pour produire un code assembleur performant sont tellement complexes et nombreuses que même si optimiser une petite boucle sera plus rapide à la main, pour un algorithme plus long il vaudra mieux l'écrire en C et avoir un compilateur performant (ou un autre langage).
Ton argument, même s'il a l'air théoriquement séduisant, n'est pas vrai en toute circonstance, en particulier dans celles où les choses à prendre en compte sont trop nombreuses ou trop complexes pour l'esprit humain.
Dans le cas de l'allocation mémoire (mais tu parlais du cas général dans cet argument-là), je suis d'accord qu'en théorie une gestion automatique devrait impacter les performances. On voit que pour le calcul matriciel comme tu en parler, gcc est nettement devant. Mais pour fibonacci ocaml est nettement devant ! Alors que penser ?
Je pense que toutes choses considérées, ça vaut le coup de perdre quelques pourcents (on en est là) de performance brute en utilisant un langage à gestion automatique de la mémoire, pour l'énorme prix de supprimer magiquement 95% des segfaults et une bonne partie (je ne saurais pas la chiffrer) des problèmes de sécurité. Après tout, les processeurs augmentent leur puissance annuellement à un rythme plus rapide que quelques pourcents - et on utilise aussi des processeurs qui sont en permanence en famine d'accès mémoire, ce qui montre qu'il y a déjà beaucoup de performance gâchée pour des buts beaucoup moins nobles.
Bien sûr c'est là le point essentiel de notre divergence :)
[^] # Re: C
Posté par gc . En réponse au journal "Virus d'image" sous Lnux. Évalué à 2.
par construction, il y a un overhead si la gestion d'une ressource est automatique. (Si tu n'est pas d'accord avec cette affirmation, je vois pas bien comment t'en convaincre...)
Ben je suis désolé je suis pas d'accord. Sur les processeurs modernes par exemple, les règles d'optimisation pour produire un code assembleur performant sont tellement complexes et nombreuses que même si optimiser une petite boucle sera plus rapide à la main, pour un algorithme plus long il vaudra mieux l'écrire en C et avoir un compilateur performant (ou un autre langage).
Ton argument, même s'il a l'air théoriquement séduisant, n'est pas vrai en toute circonstance, en particulier dans celles où les choses à prendre en compte sont trop nombreuses ou trop complexes pour l'esprit humain.
Dans le cas de l'allocation mémoire (mais tu parlais du cas général dans cet argument-là), je suis d'accord qu'en théorie une gestion automatique devrait impacter les performances. On voit que pour le calcul matriciel comme tu en parler, gcc est nettement devant. Mais pour fibonacci ocaml est nettement devant ! Alors que penser ?
Je pense que toutes choses considérées, ça vaut le coup de perdre quelques pourcents (on en est là) de performance brute en utilisant un langage à gestion automatique de la mémoire, pour l'énorme prix de supprimer magiquement 95% des segfaults et une bonne partie (je ne saurais pas la chiffrer) des problèmes de sécurité. Après tout, les processeurs augmentent leur puissance annuellement à un rythme plus rapide que quelques pourcents - et on utilise aussi des processeurs qui sont en permanence en famine d'accès mémoire, ce qui montre qu'il y a déjà beaucoup de performance gâchée pour des buts beaucoup moins nobles.
Bien sûr c'est là le point essentiel de notre divergence :)