( 8- Choisir, si possible, avec qui on travaille. )
Version imprimable
( 8- Choisir, si possible, avec qui on travaille. )
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+.Citation:
Envoyé par fcharton
J'ajouterai que tes conseils fonctionnent pour tout langage :D
Ces langages devraient alors produire des codes plus rapides, non? ;)Citation:
Envoyé par 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".
Pour tout langage compilé et d'assez bas niveau (et de bonne qualité), et sur des machines de type PC...Citation:
J'ajouterai que tes conseils fonctionnent pour tout langage :D
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
Ca compile en langage machine, avec l'avantage de la plateforme utilisée, avec potentiellement de l'instrumentation, ...Citation:
Envoyé par fcharton
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.
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)
J'utilise sans vergogne dans mon projet libre les fonctionnalités de C++0x implémentées dans GCC 4.4.Citation:
Envoyé par Alp
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 ;)
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 :aie:)
C'est vrai que ça s'ancre bien dans le C++ moderne cette histoire de move semantics.Citation:
Envoyé par Florian Goo
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 ).
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 !
Malheureusement, je ne connais pas assez bien les membres du comité, et ma boule de crystal est en panne pour l'instant :aie:Citation:
Envoyé par Florian Goo
Et je crains que ce ne soit le cas de la plupart des gens d'ici :D:dehors:
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 :aie:
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 ;)
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 ;)
Oui, tout peut se trouver à partir de cette page : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/Citation:
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...
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 :roll:
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.
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.Citation:
Envoyé par Florian Goo
Il y a donc 80% du travail de fait :)