ff9098 a écrit :



En tout cas, on reconnaît volontier ton côté fanboy a 200% " />





Dit le hateboy ms le plus virulent de PCI " />

Etrangement je t’ai pas entendu me traiter de fanboy MS quand je critiquais Modern UI. Je suis surement 10000 fois plus objectif que toi " />

ff9098 a écrit :



Tu crois que je m’abonne a tes messages ?





Tu les a très bien vu ,vu que tu trolles systématiquement dans toutes les news Windows. Espèce de menteur…

ff9098 a écrit :



Le problème c’est que tu ne fais que ça, et on a bien remarqué que tu n’intervient nulle part ailleurs.





Et toi tu trolles systematiquement sur toutes les news PCI. Si je préfères intervenir sur les news Microsoft c’est mon droit. J’ai pas du tout le temps de faire toutes les news.

fraoch a écrit :



J’ai du mal a croire que du code managé aille plus vite que du compilé….



Apres, d’un point de vue humain, peut être que le résultat sera pareil, et que l’expérience utilisateur sera bonne.



Mais je doute … En tout cas, je serais bien content si c’etait possible. Le code managé pouvant etre plus facilement exporté





Et avant de hurler, je developpe en enviro MS…..





C’est ce qu’annonce Microsoft:

source





Our goal is make the performance of managed languages exceed that of traditional unmanaged languages.





source 2

En réalite M# est un langage compilé directement en code natif. Tu n’as pas de runtime Ils ont poussé pas mal d’optimisation en particulier pour le code parallele.

il y a donc de fortes chances pour qu’il ait contribué activement à Midori



Je confirme…. " />

lossendae a écrit :



Midori… il y a des chances qu’MS propose bientot un truc vraiment sympa qui fera grincer des dents tous les libristes persuadés qu’MS est incapable de faire mieux…





Ouh la tu pêches à la dynamite tu vas les attirer " />

Sinon quand midori sortira ils resteront dans le deni,tu es un peu trop optimiste. Il y a plusieurs informations qui laisse entendre que Microsoft bosse une évolution de C#(M#) annoncé comme étant plus rapide que le C++. Quand ça sortira des benchmarks suivront et ils continueront à nier l’évidence…

lossendae a écrit :



Midori… il y a des chances qu’MS propose bientot un truc vraiment sympa qui fera grincer des dents tous les libristes persuadés qu’MS est incapable de faire mieux…





Tu sais je pense que le cas est telllement désespéré, si Microsoft devait ouvrir le code source de Windows sur une licence libre, ils continueraient à basher Microsoft

lossendae a écrit :



Oh j’ai googlé M#, on parle même d’une possibilité que le langage soit open source.

ça promet en tout cas " />





Oui c’est prévu

source





In the months to come, I will start sharing more details. My goal is to eventually open source this thing, but before we can do that we need to button up a few aspects of the language and, more importantly, move to the Roslyn code-base so the C# relationship is more elegant. Hopefully in 2014.

lossendae a écrit :



Désolé que tu te sois senti visé, comme Charon je pensais au haters, qui malheureusement sont aussi les plus bruyants.





+1 Le problème des libristes haters ils ont choisi linux d’abord par idéologie. C’est pour çà que ce sont les plus virulents et bruyants.

Il y aussi quelques maceux et une grande partie de windowiens qui bashent sur ms. Mais la plupart du temps ces windowiens ramènent la discussion sur linux et disent utiliser Linux ou vouloir y passer(ce qu’ils font le plus souvent jamais)

Khalev a écrit :



Il faut aussi noter la différence entre Microsoft en tant que boite, ses employé et ses produits.



On peut ne pas aimer MS en tant que boite mais apprécier leurs produits et être neutres vis-à-vis de leurs employés.



Je suis capable de reconnaître toutes les qualités des produits MS et de ce qu’ils ont fait pour l’informatique grand public. Par contre ça reste pour moi une boite dangereuse que j’évite d’utiliser et que je déconseille à titre personnel. Dans le cadre professionnel je prends aussi en compte l’existant et les besoins de productivité pour proposer la meilleure solutions à mes clients, je suis payé pour ça donc je fait mon boulot comme attendu.



Mais effectivement tu as raison beaucoup de libristes sont bouchés. Même RMS n’est pas aussi bouché qu’eux. Autant il est extrémistes dans ses positions politique, autant niveau technique il a un regard plutôt neutre et lucide.





" />

HarmattanBlow a écrit :



Tu ne trouveras pas de réponse dans les sources fournies mais je peux t’éclairer, sachant que je trouve pour ma part l’affirmation de MS très exagérée même si dans certaines situations ils feront effectivement mieux que le C++.





Le premier principe c’est que l’essentiel des surcoûts imputables au code managé peuvent être virés :

* Les vérifications des bornes des tableaux peuvent bien souvent être éliminées (c’est déjà le cas dans les situations les plus simples). Soit parce qu’on peut déterminer qu’elles ne seront jamais violées, soit en effectuant un seul test au début.



* La plupart des objet une vie courte se limitant à la méthode et pourraient être rendues locales, voire allouées sur la pile, en zappant le GC.





Le second principe c’est que le C++ a ses propres limites :

* Le comptage de références est réalisé au moyen d’opérations atomiques à chaque assignation qui sont coûteuses en temps CPU. A contrario un GC qui met en pause le thread n’a rien à faire lors des assignations et peut éviter tout mécanisme de synchronisation, ce qui lui permet souvent de consommer moins de CPU. Plus généralement le C++ moderne tel qu’il est utilisé en pratique est riche de motifs qui le rendent finalement aussi lourd qu’un langage managé. Le C++ moderne doit beaucoup à la qualité de ses compilateurs pour éviter ces surcoûts, or ces possibilités d’optimisation sont identiques à celles des langages managés.



* Du fait de la gestion libérale des pointeurs en C++ il faut toujours considérer qu’un emplacement mémoire peut être modifié à n’importe quel moment, ce qui empêche par exemple de conserver une valeur dans les registres. D’où le mot clé “restrict” et certaines options de compilation. Or en C# il est beaucoup plus facile pour le compilateur de déterminer qu’un emplacement mémoire n’est référencé que par telle variable locale.



* Le fait que le C++ ne compacte pas les données en mémoire ralentit l’exécution des programmes sur le long terme du fait de la fragmentation, surtout sur serveurs.





Sur ce que j’ai pu lire de diverses sources. Le compilateur C# sur lequel ils travaillent est décrit comme un compilateur optimiseur avancé.

Source1





On the C# side, we are building an advanced optimizing compiler that translates MSIL to native code. Managed code can be much higher performing when it is compiled by an ahead-of-time advanced optimizing compiler to native code.





sur le lien du blog de joe duffy cité plus haut il dit ceci:





It’s commonly claimed that with type-safety comes an inherent loss of performance. It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here, versus JIT compiling.





J’avais lu aussi un vieil article sur bartok qui expliquait qu’ils comptaient effectuer certaines optimisations avancées rendues possibles uniquement par l’utilisation d’un “safe langage” .Je ne le retrouve plus mais je le posterai si je remet la main dessus.

En fait je pense que la plupart des gains de performances sur M# sont dus à une forte optimisation du compilateur. Tu en as d’ailleurs cité quelques unes.



L’autre aspect est que ce langage serait optimisé pour le many core. Joe duffy a pas mal travaillé sur ces problématiques par le passé.