Discussion :

[hiura]

( 8- Choisir, si possible, avec qui on travaille. )

[Matthieu Brucher]

C'est le vieux débat entre langages compilés et interprétés... Au fur et à mesure que la puissance de calcul augmente, les interpréteurs vont plus vite, mais les processeurs aussi quand ils exécutent un code compilé. C'est pareil pour les progrès théoriques : meilleurs interpréteurs, meilleurs compilateurs.

Attention, quand on parle de Java et de .Net, on ne parle pas d'interprété versus compilé. Dans les deux cas, il y a compilations en bytecode et compilation à la volée à l'exécution. Donc potentiellement lus adapté à ta machine que C/C+.

J'ajouterai que tes conseils fonctionnent pour tout langage

[Invité]

Dans les deux cas, il y a compilations en bytecode et compilation à la volée à l'exécution. Donc potentiellement lus adapté à ta machine que C/C+.

Ces langages devraient alors produire des codes plus rapides, non?

Sérieusement, je ne suis pas certain qu'il y ait une telle différence entre "compilation juste à temps" (c'est à dire transformation d'un code intermédiaire en un code machine à l'exécution) et interprétation (qui veut dire, transformation d'un code en instructions machine à l'exécution).

Les bytecodes, le JIT, ou les VM c'est un raffinement des interpréteurs d'autrefois (même si des langages très anciens, comme APL ou LISP utilisaient parfois des représentations intermédiaires).

Mais ce qui fait la force des langages compilés, ca reste la capacité donnée au compilateur d'optimiser à l'avance, sur un programme complet, dans un temps non limité, et pour une machine précise, un code qu'elle exécutera directement. Je ne pense pas que ce soit "battable".

J'ajouterai que tes conseils fonctionnent pour tout langage

Pour tout langage compilé et d'assez bas niveau (et de bonne qualité), et sur des machines de type PC...

Dans un langage comme l'Action Script d'Adobe, la recommandation 1 est suicidaire, dans d'autres systèmes, en particulier certain langages interprétés (allez je vais reciter l'APL...) la 6 n'est pas une bonne idée.

Mais oui, l'optimisation c'est plus des principes sains que des astuces propres au langage ou au système...

Francois

[Matthieu Brucher]

Sérieusement, je ne suis pas certain qu'il y ait une telle différence entre "compilation juste à temps" (c'est à dire transformation d'un code intermédiaire en un code machine à l'exécution) et interprétation (qui veut dire, transformation d'un code en instructions machine à l'exécution).

Les bytecodes, le JIT, ou les VM c'est un raffinement des interpréteurs d'autrefois (même si des langages très anciens, comme APL ou LISP utilisaient parfois des représentations intermédiaires).

Mais ce qui fait la force des langages compilés, ca reste la capacité donnée au compilateur d'optimiser à l'avance, sur un programme complet, dans un temps non limité, et pour une machine précise, un code qu'elle exécutera directement. Je ne pense pas que ce soit "battable".

Ca compile en langage machine, avec l'avantage de la plateforme utilisée, avec potentiellement de l'instrumentation, ...
Pour l'instant, ce n'est pas optimal, mais il y a déjà des cas où cela fonctionne mieux que le code compilé uniquement.

[screetch]

en théorie, le code compilé apres profiling (profile guided optimization sous msvc, gcc et intel ont la meme chose) est ausi rapide que le code instrumentalisé et compilé par une VM mais la VM ajoute le code pour l'instrumentalisation, plus le code pour la generation de code (quelques "if"), plus la recompilation dynamique qui n'est pas gratuite.
Globalement, rien ne peut battre le C++ complètement optimisé mais une VM automatise et rend plus simple beaucoup de ces taches
enfin, moi perso j'attends toujours un programme de grande envergure avec une VM qui ne "rame" pas. car au dela de l'aspect theorique, dans la pratique, les programmes codés dans un langage de plus haut niveau ont toujours été plus lents que leurs equivalents compilés (je ne veux pas commencer un troll, il s'agit de la pratique c'est tout)

[Florian Goo]

Depuis les derniers messages, on en sait plus sur C++0x, on a des nouvelles versions de compilos, etc.

Vous avez d'autres conseils pour ceux qui voudraient accélérer leur code ?

J'utilise sans vergogne dans mon projet libre les fonctionnalités de C++0x implémentées dans GCC 4.4.
Je pense que la nouvelle fonctionnalité la plus encline à accélérer le code est la sémantique de mouvement. À niveau d'abstraction égal, on se retrouve avec un code plus rapide car beaucoup de copies vont se changer en déplacements.
De plus, j'utilise désormais sans scrupule des objets (par opposition aux pointeurs nus/intelligents) pour les compositions ET pour les agrégations non-polymorphes.
J'en suis même à me demander si les collections de pointeurs servent encore à quelque chose.
Donc en ce qui me concerne, le conseil serait : implémentez le constructeur et l'assignation par mouvement !

Toutes ces affirmations sont bien entendu ouvertes au débat

[Alp]

Je pense être dans une large mesure d'accord avec toi. La sémantique de mouvement va jouer un rôle capital. Pouvoir transférer une ressource sans mal va apporter beaucoup ! Le seul soucis est que certains vont s'emmêler les pinceaux, surtout quand ils vont jouer avec les primitives de multithreading de la bibliothèque standard de C++0X.... (il y a un bouquin qui est en train d'être écrit sur le sujet, et il utilise les lambdas et la sémantique de mouvement, j'ai peur pour ceux qui prendront std::move pour une fonction qui ne fait rien )

[Goten]

J'utilise sans vergogne dans mon projet libre les fonctionnalités de C++0x implémentées dans GCC 4.4.
Je pense que la nouvelle fonctionnalité la plus encline à accélérer le code est la sémantique de mouvement. À niveau d'abstraction égal, on se retrouve avec un code plus rapide car beaucoup de copies vont se changer en déplacements.
De plus, j'utilise désormais sans scrupule des objets (par opposition aux pointeurs nus/intelligents) pour les compositions ET pour les agrégations non-polymorphes.
J'en suis même à me demander si les collections de pointeurs servent encore à quelque chose.
Donc en ce qui me concerne, le conseil serait : implémentez le constructeur et l'assignation par mouvement !

Toutes ces affirmations sont bien entendu ouvertes au débat

C'est vrai que ça s'ancre bien dans le C++ moderne cette histoire de move semantics.
Seulement quant à l'utilitasion dès maintenant y'a juste quelques petites réserves, d'un c'est pas encore très bien documenté et de deux c'est sujets à des modifications assez importante. (je crois que c'est dans un de tes topics qu'on avait parlé d'un changement ).

[Florian Goo]

Oui, on avait parlé de cette histoire de « dégradation ». D'ailleurs j'aimerais bien être fixé avec assurance sur ce point.
J'utilise C++0x dès maintenant car il s'agit d'un projet libre. Les linuxiens seront les plus enclins à y contribuer dans un premier temps.
Et une fois que le projet aura atteint la maturité nécessaire à une plus large distribution, j'imagine que davantage de compilateurs auront implémenté ces fonctionnalités.

Pour un projet en entreprise, je ne me serais pas permis !

[koala01]

Oui, on avait parlé de cette histoire de « dégradation ». D'ailleurs j'aimerais bien être fixé avec assurance sur ce point.

Malheureusement, je ne connais pas assez bien les membres du comité, et ma boule de crystal est en panne pour l'instant

Et je crains que ce ne soit le cas de la plupart des gens d'ici

Peut être trouvera tu quelqu'un qui "a une idée plus ou moins précise" de ce qui sera en définitive décidé par le comité, mais, tant que la norme n'est pas officiellement parue, il y a effectivement risque de modifications...

Je *présumes* que, la deadline approchant, nous risquons encore de voir des décisions non finalisées être abandonnées par manque de temps pour leur intégration

Mais il y a, me semble-t-il, sur le site même du comité une liste des propositions et leur état d'intégration dans la norme...

Tu peux peut être déjà te baser sur celles qui ont été totalement intégrées

[Florian Goo]

Je précise que quand je dis « j'aimerais bien être fixé avec assurance sur ce point », je veux dire que j'aimerais bien savoir si le mécanisme de « dégradation » évoqué dans ce topic : http://www.developpez.net/forums/d73...antics-p-nrvo/ a bien été supprimé dans les derniers drafts.
Je suis bien conscient que le standard n'est pas finalisé et que nul ne peut prétendre savoir ce que contiendra précisément la version finale

Mais il y a, me semble-t-il, sur le site même du comité une liste des propositions et leur état d'intégration dans la norme...

Oui, tout peut se trouver à partir de cette page : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
Plus particulièrement, la liste actuellement la plus à jour est ici : http://www.open-std.org/jtc1/sc22/wg...009/n2869.html

Enfin, nous sommes légèrement hors-sujet

[JolyLoic]

Le papier 2831, qui propose une solution au problème, en question a été discuté lors de la dernière réunion du comité, sachant qu'une contre proposition existe (2835). Je n'étais pas à cette réunion, New Jersey, c'est un peu loin, et il n'y a pas eu de vote sur son inclusion dans le standard. Je ne sais pas pour quelle raison. Et j'avoue ne pas trop avoir suivi ce sujet.

[Florian Goo]

D'accord, cela n'est donc pas assuré non plus.
Merci pour l'info

[JolyLoic]

D'accord, cela n'est donc pas assuré non plus.
Merci pour l'info

Ce qui est clair, c'est que le problème est connu et admis. Ce qui n'est pas clair, c'est la manière de le résoudre, d'après ce que j'ai vu.

Il y a donc 80% du travail de fait