très spéculatif: consommation de 'ressources' machine, C++, C#, Py......

[Bounoume]

Il y a longtemps, j'avais appris qu' en exécution, un langage interprété consommait davantage de 'ressources' (cycles CPU, accès mémoire divers...) qu'un langage compilé.
Est-ce toujours exact, à services rendus identiques bien sûr.....

comme services rendus, je prendrais des accès à des gros ou nombreux objets, leurs données et leurs méthodes...
mais aussi des calculs matriciels de matheux.....

C++ est-il plus économe que C# et surtout Python, très diffusé maintenant ?
Dans quelle proportion (unité de mesure? flops ??)
merci d'avance
-----

[pm42]

Il y a longtemps, j'avais appris qu' en exécution, un langage interprété consommait davantage de 'ressources' (cycles CPU, accès mémoire divers...) qu'un langage compilé.
Est-ce toujours exact, à services rendus identiques bien sûr.....

Oui mais...

C++ est-il plus économe que C# et surtout Python, très diffusé maintenant ?

On ne peut pas faire de généralité. En pratique C++ est le plus efficace (et il est possible que C et Fortran soient encore un poil devant).

Après, C# est compilé vers une machine virtuelle qui est interprété. Mais derrière, il y a la même technologique que Java : ce code "assembleur" virtuel est interprété au début puis compilé à la volée lorsque c'est utile.
Pour certains usages, cette compilation qui utilise des statistiques d'exécution peut donc être plus efficace que C++. Ceci dit, cela ne sera pas le cas pour du calcul matriciel.

Après Python : il faut distinguer le langage de ses différentes implémentation : Python standard, cython, jython, PyPy...
Mais si on prend l'implémentation standard, c'est de l'interprété et largement plus lent que C++/C#/Java.

Sauf que pas mal de librairies de calcul sont implémentées en C/C++ et que donc chaque fois que Python y fait appel, on retrouve de la vitesse. Donc pour certains traitements, on ne perd rien.
Ce n'est pas par hasard que le Machine Learning est fait massivement en Python : on code avec la souplesse du langage mais quand on appelle les librairies (Scikit-learn, Tensorflow, Pytorch, etc), on utilise toute la puissance CPU voire GPU de la machine de façon très transparente.

On trouve plein de benchmarks sur le Net. Par ex : https://blog.famzah.net/2016/09/10/c...hmark-2016-q3/
On voit que la vitesse dépend beaucoup des implémentations et choix divers faits. Et que Java peut aller presque aussi vite que C++ ou être 12 fois plus lent.
Idem pour python : on peut être raisonnablement rapide avec PyPy mais le Python 2.7 standard va presque 20 fois moins vite que C++.

D'autres benchmarks donneront des résultats différents mais la hiérarchie et les variations suivant optimisation resteront.

[Bounoume]

Ainsi heureuses surprises possibles..... mais uniquement quand on est expert...
alors question subsidiaire: quid de IPython (c'est bien la version accessible avec Spyder?)


maintenant, quelques points que j'ignore, sur C++ et les appels de fonction.....
sur la place mémoire allouée :

Avec la distinction du cas où la fonction est déclarée inline et prototypée dans l'en-tête .h ....... et le cas ordinaire ou la fonction est déclarée en .cpp sous la forme
Objet_i::fonction_i(....) {.......}

Lorsque j'appelle la fonction:

Objet_i.fonction_j(.....) ;

je suppose que le prototype compilé est stocké 1 seule fois en mémoire centrale (dans un espace alloué au type Objet_i, avec toutes les autres fonctions de Objet_i, et ses variables static;

les variables propres à chaque instance sont ailleurs..... mais c'est là qu'est le lézard:

pour appeler la fonction fonction_j(......), les, instructions du programme en exécution (processus/thread) vont-elles directement charger le code fonction stocké une seule fois ( dans un espace alloué au type Objet_i, )... ou bien passent_elles chacune par une référence intermédiaire propre appendue à l' espace des variables propres à l'instance?
c.a.d. que la taille de l'instance comprendrait alors:

sizeof(Objet_i) = = ses variables + autant de pointeurs que de fonctions propres...


Tout ça pour savoir quelle place prend une instance d'objet avec peu de variables propres,mais une multitude de fonctions propres.... et aussi les indirections exécutées....

merci de faire une passerelle vers des cours théoriques...... qui étaient hors de propos pour moi il y a une quarantaine d'années....

[pm42]

alors question subsidiaire: quid de IPython (c'est bien la version accessible avec Spyder?)

IPython = Python standard de ce coté là.

je suppose que le prototype compilé est stocké 1 seule fois en mémoire centrale (dans un espace alloué au type Objet_i, avec toutes les autres fonctions de Objet_i, et ses variables static;

Oui.

sizeof(Objet_i) = = ses variables + autant de pointeurs que de fonctions propres...

Non, l'instance contient juste un pointeur vers la table des fonctions virtuelles et celle ci est commune à toutes les instances de la même classe.
La consommation mémoire supplémentaire reste donc très faible.

ou bien passent_elles chacune par une référence intermédiaire propre appendue à l' espace des variables propres à l'instance?

Cela dépend. Si la fonction n'est pas virtuelle, c'est un appel normal, direct et on a les performances du C.
Si la fonction est virtuelle, alors on passe par un pointeur de fonction stockée dans l'instance : https://en.wikipedia.org/wiki/Virtual_method_table
Et on a théoriquement moins de performance.

Mais là encore et sauf ultra-optimisation qui serait vraiment nécessaire, on a tendance à ne pas se préoccuper de ce genre de choses. Parce que entre les progrès des processeurs et des compilateurs qui implémentent tous les 2 des techniques avancées, il n'est pas sur qu'on gagne tant que ça à penser trop "bas niveau".
On cherche plutôt à gagner en performance plus globalement, en parallélisant à fond, en faisant attention à la localité des données pour que les caches processeur et mémoire soient bien remplis.

Pour en revenir à ce cas là, on peut aussi remarquer que :
- pour que la différence entre une fonction virtuelle et normale soit sensible, il faut que la fonction en question soit très courte, quelques instructions assembleur. Sinon, ce pointeur supplémentaire va couter en proportion très peu
- il faut que la fonction en question soit appelée beaucoup, typiquement dans une boucle qui représente le gros du temps de calcul ou récursivement.

Ce n'est pas le cas le plus fréquent mais alors, la question se pose de savoir pourquoi une fonction très courte est virtuelle et s'il n'est pas possible de la remplacer par une fonction "inline" (voir le mot clé).

merci de faire une passerelle vers des cours théoriques...... qui étaient hors de propos pour moi il y a une quarantaine d'années....

Je n'ai pas ça sous la main. J'ai appris ça de tonnes de sources différentes au cours des décennies...

[A voir en vidéo sur Futura]

[invite44510b00]

Ce n'est pas le cas le plus fréquent mais alors, la question se pose de savoir pourquoi une fonction très courte est virtuelle et s'il n'est pas possible de la remplacer par une fonction "inline" (voir le mot clé).

Sauf erreur (longtemps que je n'ai pas touché à C++), certains compilateurs sont capable de décider tout seul comme des grands d''inliner" un bout de code si l'optimiseur "juge" cette optim intéressante.

[pm42]

Sauf erreur (longtemps que je n'ai pas touché à C++), certains compilateurs sont capable de décider tout seul comme des grands d''inliner" un bout de code si l'optimiseur "juge" cette optim intéressante.

Oui mais il faut qu'il puisse le faire notamment qu'il ait accès au code source. Donc ça marche si la fonction est définie dans le même .cpp que son appel.
Pour être plus général, on met inline soi même et on défini la fonction avec son code dans un .h.

Ceci dit, tu as raison de faire remarquer que les compilateurs sont capable de faire beaucoup de choses et c'est aussi pour cela que je disais plus haut que ce genre d'optimisation ne concerne qu'une minorité.

[Bounoume]

messages bien reçus.....
MERCI et à bientôt j'espère

[Garion]

Il y a eu une étude sur le sujet :
https://programmation.developpez.com...es-plus-verts/

[invite6c250b59]

Il y a eu une étude sur le sujet :
https://programmation.developpez.com...es-plus-verts/

Très peu utile, àmha. On choisit son langage en fonction de l'usage que l'on souhaite et d'autres éléments de contexte. Si ce que l'on souhaite est de faire rouler les benchmarks choisis dans cet article, alors cet article est utile. Dans la vraie vie, ça se peut que non. Par exemple si tu as besoin de la puissance d'un GPU, le Pascal n'est pas la solution même s'il est bien classé par ces testeurs.

[pm42]

Très peu utile, àmha.

Je trouve aussi d'autant plus que pour tout programme réel, pas un petit truc qu'on fait tourner en benchmark, pas mal d'études ont montré que l'architecture globale a une importance beaucoup plus grande coté performances que le choix du langage et même que pas mal d'optimisation.

Il y a même une citation attribuée à Knuth (le monsieur qui a écrit The Art of Computer Programming et aussi TeX) qui dit que la micro-optimisation est la source de tous les maux et cela s'applique ici.

D'autant plus que personne ne va faire de l'IA en Rust ou écrire du soft système en Python...
Idem : Erlang n'est pas bien classé mais il a été utilisé pour écrire du soft ultra-fiable en environnement critique.
Ou pour faire WhatsApp avec d'un coté une petite équipe de 30 à 50 personnes et de l'autre 1.5 milliards d'utilisateurs dont plusieurs centaines de millions quotidien.

[invite6c250b59]

HS Erlang: est-ce que tu as déjà entendu parler de ce truc? https://www.springer.com/la/book/9781461444626

[pm42]

HS Erlang: est-ce que tu as déjà entendu parler de ce truc? https://www.springer.com/la/book/9781461444626

Non. En plus, en ce moment je suis plutôt dans le pas conceptuel du tout à bouffer du Javascript
C'est même la 1ère fois que j'entends parler d'Erlang dans ce contexte.

[invite6c250b59]

OK merci. Sur github le projet semble mort depuis la parution de son livre, ça a probablement jamais pogné.