Le topic de la programmation: Et envoyez des sioux!

[Lazyjoe]

Ahah ok. Après s'intéresser à la complexité globale des algos (comme dans ton exemple du n-body) c'est assez fondamental, par contre dans le code en pratique vouloir réfléchir au coût individuel de chaque opération c'est un peu couper les cheveux en 4. Déjà à moins de faire de l'assembleur hardcore les compilos se débrouillent pas mal pour réordonnancer les opérations et cacher sous le tapis les grosses latences, et sur les archis de maintenant la latence mémoire domine très largement la latence des opérations donc il faut avant tout se poser la question de si la valeur que tu calcules est dans les registres ou le cache.

[GrandFather]

On devrait oublier les petites optimisations locales, disons, 97 % du temps : l'optimisation prématurée est la source de tous les maux.

[Nilsou]

Ahah ok. Après s'intéresser à la complexité globale des algos (comme dans ton exemple du n-body) c'est assez fondamental, par contre dans le code en pratique vouloir réfléchir au coût individuel de chaque opération c'est un peu couper les cheveux en 4. Déjà à moins de faire de l'assembleur hardcore les compilos se débrouillent pas mal pour réordonnancer les opérations et cacher sous le tapis les grosses latences, et sur les archis de maintenant la latence mémoire domine très largement la latence des opérations donc il faut avant tout se poser la question de si la valeur que tu calcules est dans les registres ou le cache.

Ouais enfin, faut un minimum de comportement sain quand on code, sinon tu fais du python cracra, ça tourne 800 fois moins vite qu'un code codé proprement dans un autre langage, on s'en fout et puis voila.

Sauf qu'il y a plein de domaine ou on s'en fout pas du tout ^^.

C'est plus de bons comportement et une habitude lorsqu'on code qu'une traque du petit détail.

[William Vaurien]

Avec le prix de l'énergie qui augmente les besoins en dev "eco" (nomique|logique) vont peut être se faire sentir de plus en plus... j'ai déjà vu des présentations sur ce sujet.
Avoir un truc dans l'IDE qui te donne directement l'efficacité en terme d'énergie de ton algo est peut être un peu plus concret qu'un indice de complexité...

[Kesitem]

Ouais enfin, faut un minimum de comportement sain quand on code, sinon tu fais du python cracra, ça tourne 800 fois moins vite qu'un code codé proprement dans un autre langage, on s'en fout et puis voila.

Sauf qu'il y a plein de domaine ou on s'en fout pas du tout ^^.

C'est plus de bons comportement et une habitude lorsqu'on code qu'une traque du petit détail.

Je me permets de reformuler ta phrase, je dirais plutôt qu'il vaut mieux un code bien écrit en python que du code cracra en C++ avec des micro optimisations illisibles et des algo métiers pourris (je viens de passer 3 ans sur un projet java de ce style poussé à l'extrême, une horreur).

Quand à avoir des info dans l'IDE, je pense que ce n'est pas évident. Notamment, paracerque ton jeu de données en dev n'est pas forcement le même qu'en prod. Et donc l'efficacité de tes algo ne sera pas forcement représentatif.
Y a un moment, on est quand même obligé de faire un peu de théorie avec la complexité et les plages d'efficacité des algo.

[Nilsou]

Quand à avoir des info dans l'IDE, je pense que ce n'est pas évident. Notamment, paracerque ton jeu de données en dev n'est pas forcement le même qu'en prod. Et donc l'efficacité de tes algo ne sera pas forcement représentatif.
Y a un moment, on est quand même obligé de faire un peu de théorie avec la complexité et les plages d'efficacité des algo.

Oui enfin bon, c'est mieux que rien ^^

[Kesitem]

Oui, c'est vrai que c'est déjà un bon début

[Lazyjoe]

Ouais enfin, faut un minimum de comportement sain quand on code, sinon tu fais du python cracra, ça tourne 800 fois moins vite qu'un code codé proprement dans un autre langage, on s'en fout et puis voila.

800 fois moins vite c'est pas déjà un code python très efficace ?

Mais j'ai du mal à saisir le fond là.... Tu voudrais que l'IDE te donne une estimation du coût d'une opération ou une fonction ?
Ca me semble assez impossible, comme le dit Kesitem déjà dynamiquement tu ne peux pas prédire grand-chose sur les conditions d'exécution, et même statiquement ça impliquerait de prévoir comment le code va être transformé par le compilateur.

Bref, le boulot d'un profileur, qui peut déjà être une bonne usine à gaz sur en cours d'exécution, alors si en plus il doit faire de la voyance...

[gros_bidule]

Nan mais tu pourrais imaginer faire tourner un microbenchmark (ou juste surveiller ton appli qui tourne) puis surligner tes blocs de code avec un code couleur. A défaut d'être parfait, ça te donnerait toute de même une petite idée du code considéré comme consommateur de temps et, selon sa nature, si ça vaut le coup de se pencher dessus.
On a ça pour la couverture de code, ça pourrait peut être se faire selon les langages de programmation.

Parmi les alternatives on a évidemment les profileurs, mais cela n'interdit pas de chercher des outils plus faciles à utiliser, sinon complémentaires.

[Helix]

Nan mais tu pourrais imaginer faire tourner un microbenchmark (ou juste surveiller ton appli qui tourne) puis surligner tes blocs de code avec un code couleur. A défaut d'être parfait, ça te donnerait toute de même une petite idée du code considéré comme consommateur de temps et, selon sa nature, si ça vaut le coup de se pencher dessus.

Ce n'est pas en gros ce que font les profileurs ?
Je suis un vilain codeur pour mes recherches, mais par exemple le profileur Matlab donne exactement cette indication : le listing avec une précision dans la marge du temps passé pour chaque ligne. Je pensais que c'était qq chose de commun.

[Awake]

Ça l'est, on l'a en javascript

[gros_bidule]

Oui c'est le boulot des profileurs. Je pare juste d'un outil complémentaire, qui donnerait une vue d'ensemble des perfs de ton programme. Une vue simplifié quoi. Parce que devoir se plonger dans le profiler, ce n'est pas toujours la joie (pour du Java en tous cas).
Ca serait un peu comme la couverture de code actuellement : on peut très bien aller lire le rapport, mais avoir la coloration directement dans l'IDE c'est tellement mieux.

Nota : j'ai toujours utilisé les profilers fournis gratos avec les IDE. Mais j'entends du bien de YourKit. J'ai même des contributeurs qui m'ont sorti des rapports bien sympa grâce celui-ci. Faudrait que je me penche davantage sur le sujet, tant sur les gratos que sur YourKit (payant).

[Nilsou]

800 fois moins vite c'est pas déjà un code python très efficace ?

Mais j'ai du mal à saisir le fond là.... Tu voudrais que l'IDE te donne une estimation du coût d'une opération ou une fonction ?
Ca me semble assez impossible, comme le dit Kesitem déjà dynamiquement tu ne peux pas prédire grand-chose sur les conditions d'exécution, et même statiquement ça impliquerait de prévoir comment le code va être transformé par le compilateur.

Bref, le boulot d'un profileur, qui peut déjà être une bonne usine à gaz sur en cours d'exécution, alors si en plus il doit faire de la voyance...

Nan mais j'ai jamais dit qu'on ne devrais pas faire tourner le code, je le voyait plus comme un profileur avec un jolie affichage dans le code une fois qu'on a exécuté X fois le programme en amont.

[Nilsou]

Dites, est-ce que vous connaîtriez des ressources qui aide à comparer le coût de création / destruction d'un thread et le coût de sa mise en sommeil/reactivation via des mutex ?
J'imagine qu'il y a un seuil ou il vaut mieux utiliser une solution plutôt que l'autre, mais je n'ai rien trouvé de probant...

[rOut]

Dans tous les cas ça sera plus rapide de réveiller un thread existant vu que la création implique plus de choses. Ensuite un context switch c'est de l'ordre de la microseconde (au mieux).

[Dross]

Dites, est-ce que vous connaîtriez des ressources qui aide à comparer le coût de création / destruction d'un thread et le coût de sa mise en sommeil/reactivation via des mutex ?
J'imagine qu'il y a un seuil ou il vaut mieux utiliser une solution plutôt que l'autre, mais je n'ai rien trouvé de probant...

En .NET on utilise une encapsulation (Task, TPL, etc) qui recycle (entre autre) les threads d'un thread pool pour des questions de performances, donc plutôt réveiller que créer en effet.
D'ailleurs c'est la raison pour laquelle si vous êtes en .NET, n'utilisez jamais les Threads directement : utilisez l'encapsulation.

[Lazyjoe]

Nan mais j'ai jamais dit qu'on ne devrais pas faire tourner le code, je le voyait plus comme un profileur avec un jolie affichage dans le code une fois qu'on a exécuté X fois le programme en amont.

Moui vu comme ça pourquoi pas... Après c'est une question de philosophie, pour moi l'IDE doit plutôt fournir des infos à priori et plus ou moins instantanément, si il faut faire tourner un profileur des heures pour enrichir l'affichage du code qui peut être aussitôt modifié ça me semble un peu bancal.

Sinon à ce niveau l'Intel Advisor est pas mal, avec une visualisation hiérarchique des temps de calcul dans la pile des appels, et il arrive généralement à faire un plutôt bon mapping entre le code assembleur exécuté et leur source correspondant.

[gros_bidule]

L'IDE peut fournir les deux : des infos instantanées, mais aussi différées. Un des meilleurs exemple est la couverture de code Et tu lui demandes de la calculer seulement si tu veux, ça ne contraint personne. Je préfère un IDE qui laisse le choix, quitte à ce que certains utilisateurs le sous-utilisent, plutôt qu'un IDE qui manque de fonctionnalités.

[Nilsou]

Dans tous les cas ça sera plus rapide de réveiller un thread existant vu que la création implique plus de choses. Ensuite un context switch c'est de l'ordre de la microseconde (au mieux).

Ok, mais c'est vrai que j'aurais bien aimé avoir quelques ordres de grandeur des deux...

Maintenant, suite de la question : aujourd'hui pour paralléliser, auriez vous tendance à passer préférentiellement par OPENMP ou par faire du thread à la main ?
Moi j'ai l'habitude du thread à la main mais je me dit que c'est peut être un brin inutile maintenant pour pas mal de cas vu qu'OPENMP gère pas mal de chose tout seul ...

En .NET on utilise une encapsulation (Task, TPL, etc) qui recycle (entre autre) les threads d'un thread pool pour des questions de performances, donc plutôt réveiller que créer en effet.
D'ailleurs c'est la raison pour laquelle si vous êtes en .NET, n'utilisez jamais les Threads directement : utilisez l'encapsulation.

Ok, de toute façon c'est bel et bien ce que je faisais au départ. Donc c'est OK.
Je vois qu'OPENMP fonctionne aussi par thread pool.

[Anonyme20240202]

OpenMP c'est juste une abstraction, normalement devrait pas y avoir de grosse diff vs. un thread pool que t'implémentes toi même.

Pour les threads ce qui est couteux c'est leur création/destruction, donc il faut les réutiliser ouais (et créer tout ce dont t'as besoin dès le début, pas à la volée).

Si tu utilises une condition variable (https://en.cppreference.com/w/cpp/th...ition_variable) pour attendre dans un thread ça coute (quasiment) rien (ça dépend un peu des OS et des CPUs). Donc tu peux attendre d'avoir du travail, et dépiler quand tu reçois le signal, tu donnes ça à un thread existant (donc un thread du pool de thread).

Donc bref pour répondre directement à la question d'origine, il est toujours plus couteux de créer/détruire que d'attendre (proprement).

Je dis proprement car même dans des boites supposées prestigieuses, je vois des mecs implémenter ça avec des "sleep" dans le code, et là on oublie les perfs avec ce genre de truc dégueu

Et c'est ce que fait OpenMP, ça crée une thread pool, et ça dispatch à des threads existants

----

EDIT: 'Fin y'a absolument pas besoin de condition variable pour un thread pool de base, là je partais un peu plus loin, juste pour dire qu'attendre du travail avec une condition variable c'est très peu coûteux, par opposition à un busy loop avec du sleep ou autre implém pas propre

[rOut]

Ok, mais c'est vrai que j'aurais bien aimé avoir quelques ordres de grandeur des deux...

Maintenant, suite de la question : aujourd'hui pour paralléliser, auriez vous tendance à passer préférentiellement par OPENMP ou par faire du thread à la main ?
Moi j'ai l'habitude du thread à la main mais je me dit que c'est peut être un brin inutile maintenant pour pas mal de cas vu qu'OPENMP gère pas mal de chose tout seul ...



Ok, de toute façon c'est bel et bien ce que je faisais au départ. Donc c'est OK.
Je vois qu'OPENMP fonctionne aussi par thread pool.

https://eli.thegreenplace.net/2018/m...linux-threads/

[Lazyjoe]

Je dis proprement car même dans des boites supposées prestigieuses, je vois des mecs implémenter ça avec des "sleep" dans le code, et là on oublie les perfs avec ce genre de truc dégueu

Sinon je plussoie, dans la grande majorité des cas à moins d'avoir un besoin de synchronisation très très particulier faire des threads à la main au lieu d'utiliser OpenMP c'est se faire du mal pour rien.

Par contre l'OpenMP pour offload GPU évitez d'y toucher c'est encore pas franchement au point.

[Nilsou]

https://eli.thegreenplace.net/2018/m...linux-threads/

Merci,
Je vais lire ça en détail.

- - - Mise à jour - - -

Sinon je plussoie, dans la grande majorité des cas à moins d'avoir un besoin de synchronisation très très particulier faire des threads à la main au lieu d'utiliser OpenMP c'est se faire du mal pour rien.

Bah perso ça ne change pas grand chose : mon truc est déjà hautement parallèle (groupe totalement indépendant) donc le code que ça change (balancer le pool de thread et gerer les mutex) est vraiment court.

[Lazyjoe]

https://marketplace.visualstudio.com...-cpp-formatter

Je me sens partagé entre le révulsion et la goleri.

[GrandFather]

Le meilleur des deux mondes !

[Kesitem]

Je regardais vite les screenshots, c'est pas parfait, on voit des accolades fermantes sur les "else".

Purée, s'il y a un truc qui me manque pour facilité la lecture du code en python, c'est bien les accolades.
Et avec le formatage C++ (les accolades d'un bloc à la même indentation) pas le formatage Java caca.

[Orhin]

J'ai eu une mini attaque rien qu'en lisant le code.

[Foksadure]

Purée, s'il y a un truc qui me manque pour facilité la lecture du code en python, c'est bien les accolades.

C'est surtout la syntaxe Python le problème.

Du VBScript bien indenté reste parfaitement lisible sans ces fichues accolades, particulièrement pénibles à saisir sur les claviers AZERTY, comme les [].
Et pas besoin de : ou de ; non plus. Dommage que ce soit ECMAScript qui ait gagné la bataille.

[Orhin]

Et pas besoin de : ou de ; non plus. Dommage que ce soit ECMAScript qui ait gagné la bataille.

Les ";" ne sont pas obligatoires en JS hein.

[Cwningen]

Et avec le formatage C++ (les accolades d'un bloc à la même indentation) pas le formatage Java caca.

C'est quoi le "formatage C++" et le "formatage Java" ? Parce qu'il y a plein de styles d'indentation des accolades et ce n'est pas lié au langage. Le style GNU est connu pour ne pas mettre les accolades à la même indentation et il a été conçu pour du C.