Sont généreux chez Microsoft - Page 3

java nécessite l'installation d'une VM aussi
java se compile en jesaispasquoi code (code pour VM)
bon que ce soit propriétaire ou pas on verra ce que ça donnera
Sinon moi on m'a beaucoup vanté la puissance du C# et du .NEt en général, et la plupart des gens avec qui j'en ai parlé étaient plutôt optimistes à ce sijet... Advienne que pourra ...

bah oui c une version limitée à 60 jours.
faut lire...

PpHd
: Parce qu'il y a rien de neuf, et que c'est proprietaire.

Il y a quelques ajouts par rapport à Java qui sont pas mal.
Et C# en soit n'est pas plus propriétaire que Java, tout est normalisé ISO/ECMA, et Microsoft fournit toutes les spécifications et même des codes sources de CLR, de compilateur et de désassembleur pour plusieurs plateformes.

Mono tourne déjà pas trop mal sur *nix, sans problèmes de propriété.
Et Sun tient autant les ficelles de J2SEE que Microsoft tient celles de .NET. Le dernier JavaONE ne consistait qu'en de la pub pour les futurs produits dérivés Java de Sun, il parait.

Ximoon
: java se compile en jesaispasquoi code (code pour VM)

Java bytecodes.

J'espère que le C# ne vas pas remplacer le C++... j'ai peur de l'informatique de demain : si les programmes en code machine seront proscrits (comme l'accès direct au hardware sous Win NT et dérivés aujourd'hui), on n'exploitera pas à fond les capacités des processeurs.

Déjà actuellement la situation est assez grave : si on programmait avec autant d'attention qu'à l'époque des 386, les logiciels et jeux serait bien plus rapides. Les codeurs optimisent de moins en moins.

Ca va être encore pire si le code machine n'est plus autorisé.

Faut que je 'aille le chercher a Chronopost ..

Thibaut B
: J'espère que le C# ne vas pas remplacer le C++... j'ai peur de l'informatique de demain : si les programmes en code machine seront proscrits (comme l'accès direct au hardware sous Win NT et dérivés aujourd'hui), on n'exploitera pas à fond les capacités des processeurs.

ca existera toujours, ne serait-ce que pour les drivers, les librairies graphiques, etc...
Mais tu sais, on ne peut pas en meme temps vouloir etre compatible sur plusieur plateforme et etre optimisé... A part etre a chaque fois recompilé pour chaque machine : mais la , j'imagine meme pas le temps qu'il faudrait pour les grosses appli...

Déjà actuellement la situation est assez grave : si on programmait avec autant d'attention qu'à l'époque des 386, les logiciels et jeux serait bien plus rapides. Les codeurs optimisent de moins en moins.

tu oublie le parametre du temps mis pour coder le jeux... et le temps c'est de l'argent Tu oublie aussi que les jeux d'aujourd'hui ne sont meme pas compatibles sur plusieurs plateformes, ni meme autre chose que du x86... Ils sont deja un peu "optimisé". Mais il sont en meme temps compatibles avec toute sortes de cartes graphiques, ce qu'il fait qu'ils passent par des lib graphiques génériques : ca les "ralenti" p-e un peu mais je vois pas comment on peut imaginer faire autrement.

Ca va être encore pire si le code machine n'est plus autorisé.

pour les "simples stations de travail personnelles", je ne pense pas qu'il y est de soucis a se faire, ne serait-ce que pour les jeux

Je suis assez d'accord avec hibou : vu la vitesse d'amélioration du hardware, si il fallait garder le même rapport "effort humain/effort machine", on aurait besoin de légions entières de développeurs...


Au fait je ne sais pas si vous avez remarqué, mais on ne peut pas compiler en mode Release avec les optimisations, sur la version de VS qu'ils donnent

lol ou comment augmenter de 50% la taille

Frachement, la peur de thibaut b est vraiment justifiée, on le vois en ce mmt et depuis queleques années ... l'informatique maintenant bah tout le monde s'en bat les c******* d'optimiser en taille les logiciels (cf gcc avec -Os qu'il viennent uniquement de reprendre )

Je ne vois pas le rapport entre ce qu'a dit Thibaut et l'optimisation en taille (dont seul timad a parlé). Il y a même des chances qu'un prog C# soit plus petit que le même prog en C++ (si on n'inclut pas le framework, bien sûr )

Mais effectivement, l'optimisation en taille, on s'en fout un peu sur PC, parce que 90% de la capacité d'un disque dur moyen n'est pas constitué de progs mais de mp3/vidéos/espace libre. Bon après, il y a le temps de téléchargement, mais ça ne s'applique pas pour tous les progs (par exemple pas à windows ni à visual studio )

bouhhh j'espérais avoir au moins 1 personne d'accord avec moi

Bah, programmer en assembleur, ça fait des programmes susceptibles d'être buggés (ou alors, il faut multiplier par beaucoup le temps de développement), et pas portables du tout.

Si tu programmes en C++, tu peux réutiliser pas mal de code tel quel, alors que si tu programmes en ASM, tu es obligé de tout transposer (utilisation des registres, variables globales vs locales, types de données fixés par opposition aux templates). Ou alors, si tu ne veux pas tout transposer, tu es obligé de te fixer un style de programmation très rigide, et qui te donnera du code certainement bien moins efficace que du C++ compilé avec un bon compilo.

Le C# continue cette logique (+ des gains en portabilité, en sécurité...). En plus, avec un bon JIT, tu dois pouvoir faire du profiling "à la volée" et le compilo JIT doit pouvoir faire des optimisations de malade en exploitant ça

Bah, programmer en assembleur, ça fait des programmes susceptibles d'être buggés (ou alors, il faut multiplier par beaucoup le temps de développement), et pas portables du tout.

C'est pas ça que j'ai dit !
J'ai dit que je crains que seuls les programmes en byte-code soient autorisés à l'avenir. Donc adieu le C et le C++ qui génèrent du bon vieil ASM bien rapide.
Déjà que les programmeurs optimisent de moins en moins, alors si en plus le code généré est un ASM générique plus ou moins interprété...

Voilà ce que je voulais dire.

Thibaut>Mais ne t'inquiète pas, l'asm x86 généré par .net est tout de même de bonne qualité

J'ai dit que je crains que seuls les programmes en byte-code soient autorisés à l'avenir.

Ah, OK. Oui effectivement, je ne suis pas sûr que les outils d'analyse sémantique du code soient assez efficaces pour permettre à du code C/C++ d'être recompilés en bytecode puis (de manière efficace, i.e. sans trop de sanity checks) recompilés à partir du bytecode. En même temps ça assure une stabilité/sécurité à toute épreuve

Sauf si la VM est buggée :/

Evidemment

Thibaut B
: J'ai dit que je crains que seuls les programmes en byte-code soient autorisés à l'avenir. Donc adieu le C et le C++ qui génèrent du bon vieil ASM bien rapide.

Je pense qu'il faut que tu te dise que l'on va passé du C vers du bytecode de la même maniere qu'on est passé de l'asm pur au C.
Les appli deviennent de plus en plus grosse, performantes, etc... que tout programmer en C (resp. en asm) est plus long et plus buggé que si l'on code en bytecode (resp. en C)
je pense que le C ne sera pas interdit comme tu le sous entends, mais que l'on préfèrera naturellement générer du bytecode pour les grosses applis. Bien sur, pour les drivers ou pour nos chere petites calculatrices, le C et l'asm sont bien plus adapté.
En fait plus ca va, plus on va programmer en haut niveau, un prof nous dit meme qu'un jour on programmera mathématiquement !

Je pense qu'il faut que tu te dise que l'on va passé du C vers du bytecode de la même maniere qu'on est passé de l'asm pur au C.

Je ne suis pas absolument d'accord. Il y a une grosse différence entre le C# et le C(++), c'est que le C# permet à l'OS de lui garantir qu'il aura toujours un contrôle total de la machine (ce qui n'est absolument pas le cas du C, qui n'est en somme qu'un "assembleur portable"). Microsoft pourrait parfaitement avoir envie de faire tourner uniquement son kernel, sa VM et les drivers qu'il a certifiés en code natif, et en ajoutant une couche de compatibilité pour tout le reste des progs natifs (couche de compatibilité qui pourrait se traduire par une conversion en bytecode). Pour l'utilisateur, il n'y aurait qu'un ralentissement minime (-30% ?) de ses progs (et encore, les jeux en 3D ne seront pas plus lents), mais comme de toute façon il aura profité du changement de hardware pour changer windows (différence de prix OEM/boîte oblige...), il n'y verra que du feu.
Evidemment, je pense que Microsoft pèse savamment le pour et le contre dans ce genre de décisions, donc c'est difficile de prévoir, mais on peut raisonnablement penser qu'ils se penchent sérieusement sur la question.

arf, j'avais pas pensé a l'aspect MS du pb
et la effectivement ca m'inquiete autant que le projet palladium

Beaucoup moins, quand même (dans le sens où sans Palladium, une telle limitation n'est pas un vrai pb puisqu'on peut la contourner).
Mais effectivement ça a un rapport avec TCPA et Palladium, puisque ultimement (i.e. si TCPA marche) on ne pourra probablement exécuter que du code "Managed".

Oui, je pense que Pollux a raison, et qu'on peut craindre (mais craindre est-il vraiment le mot exact ?) un changement radical au niveau du noyau de Windows. L'utilisation d'une VM permettrait donc aux applications écrites aujourd'hui de pouvoir tourner quand même sous la nouvelle structure.

Bof, ces histoires d'optimisations, ça n'a existé que pour les informaticiens... - c'est pas des blagues, regardez avant le C -
Perso, je trouve VS très performant, et comme dit, on est assuré du non plantage de tout le PC de manière définitive, ce qui est rassurant, tout de même.

Thibaut: Va donc programmer pour la FSF. Ils adorent le C et l'ASM. Comment ca ? Un gain de 1% ? Mais bien sur, vas-y. . Je les adore

Pollux a parlé de 30%. Tu sais bien que le Java (càd C#) est plus lent que le C++, et de plus de 1%...
Je souhaite qu'on puisse continuer à coder en C++ -> asm natif à l'avenir. C'est idiot de s'inquiéter que "dans 10 ans on ne pourra plus augmenter la fréquence des processeurs" si on fait des programmes de plus en plus lents !

Je dis 30%, mais ça peut être plus (gros programmes avec une boucle énorme répétée un faible nombre de fois) comme ça peut être beaucoup moins (programme avec des boucles très répétitives). Et dans le cas de boucles répétitives la compilation just-in-time peut adapter sa qualité au nombre d'exécutions prévues du code : une boucle exécutée un million de fois vaut probablement le coup d'activer toutes les optimisations, y compris des gros trade-offs vitesse/mémoire s'il y a assez de RAM ou si le contenu de la boucle n'est pas gigantesque. Ce n'est pas possible dans le cas d'une compilation statique, ou alors le programme sera plus gros et demandera plus de RAM / mémoire virtuelle, parce que le compilo ne peut pas savoir à l'avance quels sont les endroits critiques (à moins de faire du profiling, mais ce n'est jamais parfait parce que certains endroits ne seront pas explorés au moment du profiling mais seront quand même critiques s'ils sont exécutés [par exemple, IA d'un boss de fin de niveau, etc...]).


Je comprends bien ce que tu veux dire, et ce serait effectivement complètement ridicule d'arrêter du jour au lendemain le support des programmes "natifs".

C'est idiot de s'inquiéter que "dans 10 ans on ne pourra plus augmenter la fréquence des processeurs" si on fait des programmes de plus en plus lents !

Oui, mais dans 10 ans, d'une part les compilateurs just-in-time seront bien plus efficace, et réserver 1% du processeur à la compilation dynamique permettra des trucs bien plus puissants qu'aujourd'hui. Ensuite, rien ne dit qu'on n'aura pas trouvé des manières d'employer des architectures parallèles qui permettraient de faire des procs plus puissants, ou bien d'utiliser une technologie, mais bon on dérive là Si on utilise un truc du genre FPGA, ce serait ultra puissant que le compilo puisse allouer dynamiquement une partie de l'espace du FPGA à certains progs, reconfigurer le FPGA quand il faut, etc... (donc là une compilation statique n'est pas adaptée, sauf si on est en mono-tâche [ce qui est assez limitatif ] ou si on reconfigure tout à chaque task switch, mais ce n'est pas forcément très satisfaisant parce que l'espace alloué au prog est fixé...)

Mais pourquoi un programme en byte code est-il plus incapable de planter un OS qu'un programme en ASM sous un OS très sécurisé comme Window$ XP ?
Aucun programme ne m'a jamais planté Window$ XP !

Côté sécurité, je ne sais pas trop, peut-être tout simplement le fait qu'on puisse vérifier de manière sûre (en option, bien sûr ) qu'on ne déborde pas d'un array (même sous un OS bien fait, un dépassement de tableau peut aboutir à un endroit dont l'accès est autorisé, par exemple la pile ). Et l'analyse sémantique de code permet de ne pas avoir à faire systématiquement une vérification par accès au tableau.

Il y a probablement d'autres choses que je ne vois pas.

certes les systemes d'exploit sont de plus en plus robustes, mais c'est qd meme mieux quand le programme reconnait lui meme qu'il fait n'importe quoi : il le détecte bien plus facilement, car il peu par exemple rester dans son espace mémoire et faire n'importe quoi sans que l'OS ne s'apercoive de rien. Ca peut p-e éviter que des prog bloque l'OS parce qu'ils utilise tout le proc : t'es obligé d'attendre que ta fenetre de fermeture de prog s'ouvre pendant 5 min pour pouvoir enfin le tuer.
Comme tu dis, le byte code n'est pas plus "incapable de planter un OS qu'un programme en ASM sous un OS", il détecte ses propres débordement, ce qui est plus fin. Je pense que c'est ce dont tu parles Pollux.

Pour le traitement parallèle, c'est pas demain la veille - on a pu voir ça en cours, le problème n'étant pas de réaliser ces monstres, mais bel et bien de les programmer et de les alimenter en données... -

Quant aux FPGA, quand on voit les monstres qui sont créés et qui ne peuvent pas être programmés en C ou autre sous peine de pertes immenses, à la limite, le langage de macro, c'est tout - voir la puce utilisée en recherche sur les modem il y a 10 ans -