Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 165 sur 165 PremièrePremière ... 65115155157158159160161162163164165
Affichage des résultats 4 921 à 4 940 sur 4940
  1. #4921
    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.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  2. #4922
    Citation Envoyé par Donald Knuth
    On devrait oublier les petites optimisations locales, disons, 97 % du temps : l'optimisation prématurée est la source de tous les maux.

  3. #4923
    Citation Envoyé par Lazyjoe Voir le message
    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.

  4. #4924
    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é...

  5. #4925
    Citation Envoyé par Nilsou Voir le message
    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.

    Mon blog figurines: UglyMiniatures

  6. #4926
    Citation Envoyé par Kesitem Voir le message
    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 ^^

  7. #4927
    Oui, c'est vrai que c'est déjà un bon début

    Mon blog figurines: UglyMiniatures

  8. #4928
    Citation Envoyé par Nilsou Voir le message
    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...
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  9. #4929
    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.


  10. #4930
    Citation Envoyé par gros_bidule Voir le message
    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.
    Rien ne me choque moi, je suis un scientifique ! - I. Jones

  11. #4931
    Ça l'est, on l'a en javascript
    Citation Envoyé par ExpertCPC Voir le message
    J'ai vu le monde éveillé. J'ai vu le monde endormi. J'ai vu le monde en rêve.

  12. #4932
    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).


  13. #4933
    Citation Envoyé par Lazyjoe Voir le message
    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.

  14. #4934
    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...

  15. #4935
    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).
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  16. #4936
    Citation Envoyé par Nilsou Voir le message
    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.

  17. #4937
    Citation Envoyé par Nilsou Voir le message
    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.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  18. #4938
    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.


  19. #4939
    Citation Envoyé par rOut Voir le message
    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 ...

    Citation Envoyé par Dross Voir le message
    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.

  20. #4940
    OpenMP c'est juste une abstraction, normalement devrait pas y avoir de grosse diff vs. une 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
    Dernière modification par Kamikaze ; Aujourd'hui à 13h48.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •