IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Programmation : une étude révèle les langages les plus voraces en énergie


Sujet :

Débats sur le développement - Le Best Of

  1. #141
    Membre confirmé

    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Février 2005
    Messages
    464
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2005
    Messages : 464
    Points : 646
    Points
    646
    Par défaut
    "De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C."

    Je t'invite à tenter de concurrencer un compilateur C avec ton source en langage d'assemblage.
    Selso.
    Ingénieur/CdP développement systèmes embarqués &

  2. #142
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par vanquish Voir le message
    De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C.
    C'était peut-être vrai aux débuts de l'informatique. Mais avec les processeurs RISC et les architectures matérielles de plus en plus complexes, un compilateur sortira généralement du bytecode mieux optimisé que ce qu'aurait fait un humain en assembleur.

  3. #143
    Membre à l'essai
    Homme Profil pro
    Ingénieur réseaux / télécoms
    Inscrit en
    Avril 2018
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur réseaux / télécoms

    Informations forums :
    Inscription : Avril 2018
    Messages : 12
    Points : 17
    Points
    17
    Par défaut
    Alors je fais peut être des raccourcis naïfs, mais dans les ordres de grandeur je ne pense pas me tromper :
    1. Les résultats de l'étude portugaise, en terme d'efficacité énergétique, sont fortement corrélés à des résultats de perfs de langage.
    2. Avec WASM, par construction JS se retrouve en concurrence avec les autres langages, y compris compilés et de bas niveau.

    Donc pour le point 1, on apprend que plus un langage va vite moins le CPU est utilisé longtemps pour exécuter une tâche : incroyable.
    Et dans le point 2, on apprend qu'un langage compilé & bas-niveau va plus vite qu'un langage scripté & haut-niveau : incroyable.

    Au final j'ai beaucoup plus appris en lisant les commentaires pertinents des personnes ici. ^^

    My 2 cents : ce qu'on voit là est une loi mathématique à l'oeuvre en biologie évolutive.
    • En période d'abondance de ressources, la sélection tend à favoriser d'autres traits avantageux que la chasse aux ressources (i.e. avantages reproductifs).
    • En période de contraction des ressources vitales, la sélection tend à favoriser drastiquement les traits améliorants l'accès aux ressources (i.e. avantages économes).

    La queue du Paon, Python, même combat : c'est parfaitement adapté au contexte. Et le jour où l'économie de ressources sera vital, vous voyez très bien quels langages vont souffrir du nouveau contexte et lesquels vont briller.

  4. #144
    Expert éminent

    Profil pro
    Fabricant et casseur d'avions
    Inscrit en
    Avril 2004
    Messages
    3 807
    Détails du profil
    Informations personnelles :
    Localisation : France, Tarn (Midi Pyrénées)

    Informations professionnelles :
    Activité : Fabricant et casseur d'avions
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Avril 2004
    Messages : 3 807
    Points : 7 613
    Points
    7 613
    Par défaut
    Citation Envoyé par Captain Spic Voir le message
    Est-ce qu'on pourrait, une bonne fois pour toutes, arrêter avec ce genre de remarques inutiles et hostiles ?
    Oui, on peut... mais pas avec JS!

    Après, il y en a plein qui râlent après Rust parce que ça fait la même chose que le C++ et que c'est imbit... super dur à maîtriser.



    Citation Envoyé par henaff Voir le message
    Vous comparez deux langages complètement différent. Si rust avait été plus performant que du c++ ok y'aurait eu un article à faire. JS c'est de l'interprété, ça sert pas à la même chose, d'ailleurs on peut très bien faire des binds vers du c++ ou du rust.
    Ben là justement ça compare des langages pour au final faire la même chose... et ça dit juste que si tu veux "économiser" de l'énergie, il y en a qui sont plus adaptés que d'autres. Ca n'aborde pas les autres critères. Et sauver la planète ça ne veut pas dire uniquement économiser l'énergie...

    C'est quand même incroyable qu'il est toujours des mecs qui encensent des technologies juste pour le plaisir : PHP, JavaScript, Python aussi, etc [plagiat inside, credits: Captain Spic]

    [note] petite précision, je code en python... et en rust... et les deux ensemble...
    "Errare humanum est, sed perseverare diabolicum"

    Ma page sur DVP.com

  5. #145
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2002
    Messages
    272
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 272
    Points : 164
    Points
    164
    Par défaut Optimisations faites par le compilateur.
    De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C.
    Il faut vraiment penser à toutes les optimisations possible à faire, que fait le compilateur fait. Par exemple sur architecture CISC se dire qu'il est moins couteux en nombre de cycle de faire un décalage de bit à gauche (SHL en assembleur 8086) qu'une multiplication par 2 (MUL, en assembleur 8086), etc...

  6. #146
    Expert confirmé

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 317
    Points : 4 124
    Points
    4 124
    Par défaut Oups !
    Bonjour,

    J'ai regardé le code Pascal. Le potentiel d'optimisation est réel.

    Dans certain cas, ce sera difficile. Par exemple, PiDigit utilise essentiellement GMP ce qui transforme une amélioration en la recherche d'une autre bibliothèque ou une réécriture de GMP (sans moi). Mais même cet exemple où le codage est essentiellement des appels à GMP, on trouve dans une boucle un mod 10 sur une variable incrémentée.

    Le seul programme que j'ai un peu modifié est le spectralnorm. J'ai tiqué sur la fonction A qui calcule un inverse qui est ensuite multiplié par une variable. Comme la valeur inverse calculée n'est pas utilisée plusieurs fois (genre invA := 1/A; x:=invA* dx; y:= invA*dy; dz:= invA*dz), il n'y a aucun intérêt à avoir une division et une multiplication. Autant diviser directement cela économise une multiplication de flottants.
    Ensuite on s'aperçoit que le diviseur peut se calculer par simple incrémentation (on économise 2 additions entières, une multiplication entière et un décalage unitaire). Tout cela dans les deux boucles principales. Un gain de plus 30% pour un travail à la paresseuse (sans restructuration) et je n'ai certainement pas tout vu.

    Dans le programme n_body on trouve dans la boucle principale :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    mag := dt / (sqrt(sqr(dx)+sqr(dy)+sqr(dz))*(sqr(dx)+sqr(dy)+sqr(dz)));
    C'est faire une grande confiance au compilateur (peut être légitime) de supposer qu'il ne va pas calculer deux fois les sommes quadratiques.
    J'aurais tendance à essayer ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    mag := dt * power(dx*dx + dy*dy + dz*dz, -1.5);
    Certes, power n'est pas la plus rapide des fonctions mais elle remplace ici une division par une multiplication (bien plus rapide), supprime une racine carrée et une multiplication et lève toute ambiguïté sur l'aptitude du compilateur à éviter des recalculs.

    En résumé, cela confirme ce qui a déjà été dit, les grandes communautés auront toujours plus de potentiel pour trouver le meilleur développeur pour un problème donné.

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  7. #147
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 138
    Points : 406
    Points
    406
    Par défaut
    Le C++ 50% plus lent que C!?

    Là faudrait m'expliquer comment ils arrivent à un chiffre pareil.

  8. #148
    Membre actif
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    71
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 71
    Points : 288
    Points
    288
    Par défaut ou "Retourner à la machine à écrire peut-il sauver la couche d'ozone" ?
    Y'a quand même des mecs qui s'em*** dans la vie à prouver des trucs évidents.

    A mon tour : Au feu Python, JS, PHP, bash, Java, C#, Kotlin, etc. et vive l'asm !

    A l'extreme limite, on garde C/C++, Delphi, Go... et encore je suis sympa, hein )

  9. #149
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    Janvier 2014
    Messages
    1 498
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 498
    Points : 5 678
    Points
    5 678
    Par défaut
    Citation Envoyé par ParseCoder Voir le message
    Le C++ 50% plus lent que C!?
    L'avantage de C++ par rapport à C c'est une programmation OO et de plus haut niveau, pas la rapidité d'exécution.
    Le plus rapide en exécution du code c'est l'assembleur, après le C.
    Le langage Rust est un choix intéressant car c'est un langage de haut niveau, mais qui a de bonnes performances d'exécution, proche du C, et généralement clairement bien meilleures par rapport aux autres langages de haut niveau.

    On pourrais simplifier en disant que la nouvelle mode de Python est une catastrophe écologique, car les performances d'exécution sont dégueulasses, et qu'on pourrait dire à l'extrême qu'on devrait faire une loi mondiale pour interdire Python et obliger les codeurs à utiliser Rust
    « L’humour est une forme d'esprit railleuse qui s'attache à souligner le caractère comique, ridicule, absurde ou insolite de certains aspects de la réalité »

  10. #150
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 412
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 412
    Points : 4 729
    Points
    4 729
    Par défaut
    Citation Envoyé par Captain Spic Voir le message
    Oui le dossier "node_modules" pèse 1to sur ton disque, néanmoins je connais pas un autre langage où tu peux être opérationnel en seule une ligne de commande.
    mvn clean install.

    Ou n'importe quel dependency manager en fait... sur n'importe quel language correctement outillé. Dans mon monde je l'ai constaté en C++ et en Java, j'ai du mal à croire que ça n'existe pas pour du python ou d'autres langages populaires...

    Tous les langages ont leur avantages et leurs inconvénients. Faut arrêter d'être sectaire dans un sens ou dans un autre.
    Il faut également se tenir au courant de ce qui existe à côté pour comprendre que ce qu'on pense être un avantage n'est qu'en fait la norme.

    Et ce genre d'article est intéressant pour garder des ordres de grandeur en tête.

    Personnellement c'est la position de PHP qui m'a étonné. Pour moi il avait fait un sacré bon en perf avec sa version 7, ça ne ressort pas de ouf dans le tableau ici.

  11. #151
    Expert confirmé

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 317
    Points : 4 124
    Points
    4 124
    Par défaut Comment faire moins avec plus (voire plus plus)
    Bonjour ParseCoder,

    Citation Envoyé par ParseCoder Voir le message
    ... 50% plus lent que C!? ...
    Avec le C embarqué dans C++, c'est effectivement surprenant.

    Mais certains s'interdisent d'utiliser les possibilités du C avec C++. Le dogmatisme dans sa splendeur : C++ == objet, C != objet. C'est aussi oublier l'histoire du C++ et le fait que le C embarqué n'est pas seulement un vestige de cette histoire mais un choix délibéré.

    Cependant certaines facilités du C++ sont tentantes et peuvent faire oublier que ces facilités ont un coût je pense, par exemple, à la surcharge des opérateurs qui tendent souvent à multiplier les créations/destructions d'objets. Mais dans un challenge cela ne devrait pas apparaître.

    Salut
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  12. #152
    Expert confirmé Avatar de sergio_is_back
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    Juin 2004
    Messages
    1 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique, développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 076
    Points : 5 541
    Points
    5 541
    Par défaut
    Citation Envoyé par Jeff_67 Voir le message
    C'était peut-être vrai aux débuts de l'informatique. Mais avec les processeurs RISC et les architectures matérielles de plus en plus complexes, un compilateur sortira généralement du bytecode mieux optimisé que ce qu'aurait fait un humain en assembleur.
    C'est vrai avec un code correctement réfléchi et maitrisé, mais si tu codes comme un pied, les meilleurs optimisations du monde ne feront pas de miracle, je pense que tout le monde sera d'accord là dessus

  13. #153
    Membre confirmé
    Inscrit en
    Octobre 2005
    Messages
    239
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 239
    Points : 539
    Points
    539
    Par défaut En complément...
    Je ne sais pas comment ils ont fait leurs tests, rust est effectivement très rapide, peu gourmand mais ce n'est peut-être pas aussi catastrophique pour certains langages (je pense au php notamment).
    La syntaxe du langage semble assez indigeste, surtout pour faire du web...

    En tout cas voici un ensemble assez précis en complément .
    https://github.com/kostya/benchmarks

  14. #154
    Expert confirmé

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 317
    Points : 4 124
    Points
    4 124
    Par défaut Machine vs humain ?
    Bonjour,

    La magie des compilateurs et la magie des processeurs modernes n'existent pas. Ils sont certes de plus en plus sophistiqués et performant mais ils ont beaucoup de handicaps, par exemple :
    • ils ne savent pas à quoi sert le code : l'exemple classique du comptage de bits qui nécessite au moins une dizaine de lignes de code ne sera jamais condensée en un simple popcnt.
    • ils ne connaissent pas les données : par exemple, ils (Comp) ne permuteront pas les cas dans un switch pour mettre les plus probables en début de liste, et l'anticipation des sauts (CPU) trouvera ici très vite sa limite.
    • ils (Comp) n'ont qu'une vision locale du code : certes une division par 2n sera traduite par un sar (décalage droit arithmétique qui conserve le signe) mais une division par une valeur calculée ailleurs qui a l'heur d'être toujours une puissance de 2 ne bénéficiera de cette optimisation.
    • ils n'anticipent pas : par exemple, si vous avez de grande masses de données en mémoire à traiter en séquence, malgré les (très limitées) lignes de cache du processeur, il vous appartiendra d'écrire des instructions de pré-chargement pour éviter un traitement systolique (par à-coup en français ) .

    Je pense qu'il y a deux manières de travailler avec ces "magiciens" :
    • Faire comme s'ils n'apportaient rien et faire le meilleur code possible. Les gains qu'ils apporterons seront le bonus. Entre pas d'optimisation et le niveau maximal d'optimisations, sauf cas particulier, les gains sont souvent assez modérés de 8 à 10%. Mais c'est toujours bon à prendre.
    • Plus difficile mais plus efficace, faire un code qui aide compilateur et processeur à mieux travailler : par exemple, un code en assembleur qui entrelace bien ces instructions de façon à avoir le moins de dépendances entre instructions consécutives sera mieux traité par le processeur (out of order et utilisations des unité uop). Mais, outre que le code devient encore plus difficile à lire, le travail est sensiblement plus lourd.

    Pour les moins convaincus, il y a un petit test qui échoue sur la plupart des compilateurs. Quelquefois des traitements nécessitent d'avoir à la fois le quotient et le reste (modulo) d'une division. On peut voir le code suivant :
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    q = n \ d;   // => une division
    r = n % d;   // => une division
    Or la division produit à la fois q et r. Il est donc possible d'utiliser un petit code assembleur qui évitera une division (Div() en C et C++, DivMod dans d'autre langage). Mais il est aussi possible d'écrire :
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    q = n \ d;  // => une division
    r = n - d*q;  // => une multiplication
    Ce dernier code est à peine moins efficient que le code assembleur (il n'y a pas d'appel de fonction dont l'un des retours ne peut être en registre) et reste presque deux fois meilleur que le premier toutes optimisations actives (la multiplication est bien moins gourmande que la division).

    Il y a aussi la possibilité d'acheter une machine plus puissante

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  15. #155
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    Octobre 2007
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 676
    Points : 2 010
    Points
    2 010
    Par défaut
    Citation Envoyé par Jeff_67 Voir le message
    Il est clair que les codes compilés statiquement apportent un gros plus en terme d'usage CPU et d'empreinte mémoire par rapport aux langages interprétés ou compilés à la volée.

    Mais il est fort illusoire de croire que les devs JS migrent massivement vers Rust. Et JS est une catastrophe à tout point de vue, pas qu'environnementale.
    Evidemment sinon on écrirait Microsoft Office en Lua et d'ailleurs certains a bien tenté de nous vendre les IHM web dans Blackberry puis dans Windows 8 ... avec le succès que l'on a vu.

    Comme si Javascript était responsable du fait qu'il faille 8Go et un processeur Skylake pour faire tourner Photoshop ou Word, ou que 20 ans après, Windows 11 soit encore a se trimbaler des services inutiles comme Superftech et avec des fuites mémoires.
    C'est le modèle multiprocess de Chrome qui pèse le plus lourd dans un browser aujourd'hui, les scripts faisant au pire (youtube) 10% du poid de l'onglet. Une page de développez.com pèse 1Mo de Ram en Script, contre 167Mo pour la page et l'onglet, et chaque extension pèse autant probablement du fait du sandboxing.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  16. #156
    Membre averti
    Homme Profil pro
    Dev
    Inscrit en
    Novembre 2006
    Messages
    112
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev

    Informations forums :
    Inscription : Novembre 2006
    Messages : 112
    Points : 350
    Points
    350
    Par défaut
    il faut comprendre ce que fait un langage ( ses spec , son modèle mémoire ...) et la machine sur laquelle le code est exécuté.

    Il faut aussi comprends les différente structure de donné et leur implentation (a array / list tableau/ list chainé / set / map ....)

    Ex en java :

    le cout d'une ArrayList vs une LinkedList ( Machine d'il y a20ans vs machine Moderne ).

    En C++ :
    * l'héritage virtual est plus couteux que l"héritage non virtual .
    * appel d'une méthode virtuel est plus couteux que l'appel d'une méthode non virtuel

  17. #157
    Membre émérite
    Profil pro
    retraité
    Inscrit en
    Décembre 2010
    Messages
    804
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Décembre 2010
    Messages : 804
    Points : 2 299
    Points
    2 299
    Par défaut
    C plus rapide que le C++, pas si évident que cela
    https://benchmarksgame-team.pages.de...t/gcc-gpp.html

    Ici on dit le contraire

  18. #158
    Inactif  

    Homme Profil pro
    Ingénieur test de performance
    Inscrit en
    Décembre 2003
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur test de performance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 986
    Points : 2 605
    Points
    2 605
    Par défaut
    Bonjour.

    On parle beaucoup de rapidité des langages, sans mettre en parallèle la consommation mémoire de ceux-ci. De plus lorsqu'une instance nécessaire à un langage interprété tourne en fond de tâche, on en tient pas compte dans la rapidité...

  19. #159
    Expert confirmé

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 317
    Points : 4 124
    Points
    4 124
    Par défaut J'ai la priorité
    Bonjour,

    Je n'ai pas regardé tous les sources mais dans ceux que j'ai vu il n'y en pas un qui élève son degré de priorité (peut être est-ce interdit par le bench). Pourtant c'est un moyen assez simple pour grapiller quelques % en étant moins soumis à la concurrence des autres taches.

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  20. #160
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 412
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 412
    Points : 4 729
    Points
    4 729
    Par défaut
    Citation Envoyé par Guesset Voir le message
    Bonjour,

    Je n'ai pas regardé tous les sources mais dans ceux que j'ai vu il n'y en pas un qui élève son degré de priorité (peut être est-ce interdit par le bench). Pourtant c'est un moyen assez simple pour grapiller quelques % en étant moins soumis à la concurrence des autres taches.

    Salutations
    A ma connaissance la manière la plus naïve qui soit de compter le temps utilisé par un processus est d'utiliser la commande time et celle-ci fait déja la différence entre real (temps total ressenti), user(temps réel CPU accordé à l'utilisateur) et sys ( temps utilisé par les IO système).

    En l'occurence jouer leur la prio fera baisser le real mais n'impactera pas user et sys. J'ose espérer qu'un site spécialisé dans le benchmark tien à minima compte de ces valeurs et sinon utilise des outils plus pointus ^^

Discussions similaires

  1. Réponses: 11
    Dernier message: 27/03/2024, 09h39
  2. Réponses: 73
    Dernier message: 23/10/2023, 16h28
  3. Réponses: 16
    Dernier message: 12/09/2022, 20h46
  4. IDC : une étude révèle une addiction des américains pour les smartphones
    Par Stéphane le calme dans le forum Actualités
    Réponses: 7
    Dernier message: 09/04/2013, 09h32
  5. Réponses: 0
    Dernier message: 30/07/2009, 11h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo