"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.
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
Discussion :
"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.
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.Envoyé par vanquish
Alors je fais peut être des raccourcis naïfs, mais dans les ordres de grandeur je ne pense pas me tromper :
- 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.
- 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.
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.
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...
Optimisations faites par le compilateur.
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...De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C.
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 :
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.
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)));
J'aurais tendance à essayer ceci :
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part mag := dt * power(dx*dx + dy*dy + dz*dz, -1.5);
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
Le C++ 50% plus lent que C!?
Là faudrait m'expliquer comment ils arrivent à un chiffre pareil.
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)
L'avantage de C++ par rapport à C c'est une programmation OO et de plus haut niveau, pas la rapidité d'exécution.Le C++ 50% plus lent que C!?
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
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.
Comment faire moins avec plus (voire plus plus)
Bonjour ParseCoder,
Avec le C embarqué dans C++, c'est effectivement surprenant.... 50% plus lent que C!?...
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
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
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
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 :
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
2
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).
Code C : Sélectionner tout - Visualiser dans une fenêtre à part
2
Il y a aussi la possibilité d'acheter une machine plus puissante
Salutations
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.
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
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
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é...
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
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
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 ^^
Répondre avec citation
Partager