je sors agréablement surpris d'une semaine de formation sur .NET en
environnement M$.
J'y ai découvert la programmation en C++.NET (je développe en C/C++
traditionnel sur Mac au boulot et je bidouille sous GNU/Linux à la
maison).
Déjà voir que .NET faisait usage d'un compilo JIT m'a un peu fait revoir
mon appréciation négative sur .NET que je considérais (mal) comme Java
avec son code interprété.
Ensuite la surprise vient que le formateur (qui ne pratique pas Linux) a
su m'indiquer qu'il existait une implémentation pour Linux. Deux en fait
après avoir creusé le sujet : Mono (sponsorisé par Ximian/Novell) et
dotGNU.
Et l'agréable vient qu'après avoir bataillé avec des paquetages un peu
expérimentaux (tout n'est pas encore finalisé) j'ai pu voir que mes
programmes de test fonctionnaient directement sous Linux _et_ sous Win
avec le même exécutable (qui d'ailleurs est aussi un .exe sous Linux).
Tiens d'ailleurs pour ajouter à la surprise, le VB.NET est aussi en
cours de portage, ça fait un peu bizarre :)
Sinon on peut pour le moment partager du C# et de l'assembleur IL en
plus de VB (je pense que d'autres suivront mais je n'ai pas vu de c++)
et l'IDE que j'ai testé (MonoDevelop) bien qu'en v0.5 a l'air pas mal.
J'aime bien la complétion intelligente à la Visual Studio (qui àma est
la seule application vraiment valable chez M$ ;).
D'autres ont-il aussi testé .NET en cross-plateforme et qu'en
pensent-ils ?
Crosspost & Suivi prudent vers fr.comp.os.linux.debats
--
Sébastien Kirche
J'ai fait des benchmark, portant un programme de morphing de C en C#. Exactement le même algo est utilisé. Je suis 20% moins rapide en C# qu'en C.
Tiens en parlant de benchmark : où en est le C/C++ sur cette même plateforme .NET ?
Puisque tous les langages sont censés passer en IL (Intermediate Language) les perfs sont elles comparables ? Un code compilé autrefois en Visual C++ pré-NET devient-il plus lent avec les versions 2003/2005 ?
-- Sébastien Kirche
Le 31 May 2005, Remi Thomas a dit :
J'ai fait des benchmark, portant un programme de morphing de C en C#.
Exactement le même algo est utilisé.
Je suis 20% moins rapide en C# qu'en C.
Tiens en parlant de benchmark : où en est le C/C++ sur cette même
plateforme .NET ?
Puisque tous les langages sont censés passer en IL (Intermediate
Language) les perfs sont elles comparables ? Un code compilé autrefois
en Visual C++ pré-NET devient-il plus lent avec les versions 2003/2005 ?
J'ai fait des benchmark, portant un programme de morphing de C en C#. Exactement le même algo est utilisé. Je suis 20% moins rapide en C# qu'en C.
Tiens en parlant de benchmark : où en est le C/C++ sur cette même plateforme .NET ?
Puisque tous les langages sont censés passer en IL (Intermediate Language) les perfs sont elles comparables ? Un code compilé autrefois en Visual C++ pré-NET devient-il plus lent avec les versions 2003/2005 ?
-- Sébastien Kirche
talon
Remi Thomas wrote:
"Michel Talon" écrivit J'ai fait des benchmark, portant un programme de morphing de C en C#. Exactement le même algo est utilisé. Je suis 20% moins rapide en C# qu'en C. http://www.pixel-technology.com/netmorphing/french/
Rémi
Je ne conteste pas ça, il y a des benchs que j'ai cités qui montrent que Java ou C# arrivent presque à la même vitesse que C sur certains problèmes. En tout cas sur ce que j'ai cité, faire du TeX dans sa version Java, c'est 10 fois plus lent, ce qui n'est pas dramatique, car ma machine compile de l'ordre de 100 pages à la seconde.
Remi Thomas <remi@xtware.com> wrote:
"Michel Talon" écrivit
J'ai fait des benchmark, portant un programme de morphing de C en C#.
Exactement le même algo est utilisé.
Je suis 20% moins rapide en C# qu'en C.
http://www.pixel-technology.com/netmorphing/french/
Rémi
Je ne conteste pas ça, il y a des benchs que j'ai cités qui montrent
que Java ou C# arrivent presque à la même vitesse que C sur certains
problèmes. En tout cas sur ce que j'ai cité, faire du TeX dans sa version
Java, c'est 10 fois plus lent, ce qui n'est pas dramatique, car ma machine
compile de l'ordre de 100 pages à la seconde.
"Michel Talon" écrivit J'ai fait des benchmark, portant un programme de morphing de C en C#. Exactement le même algo est utilisé. Je suis 20% moins rapide en C# qu'en C. http://www.pixel-technology.com/netmorphing/french/
Rémi
Je ne conteste pas ça, il y a des benchs que j'ai cités qui montrent que Java ou C# arrivent presque à la même vitesse que C sur certains problèmes. En tout cas sur ce que j'ai cité, faire du TeX dans sa version Java, c'est 10 fois plus lent, ce qui n'est pas dramatique, car ma machine compile de l'ordre de 100 pages à la seconde.
Michel Billaud
jul writes:
Le Tue, 31 May 2005 13:55:54 +0200, Michel Billaud a écrit :
... extasie ... Un signe.
Quand à descendre C# sans l'avoir utilisé, ça ne me parait pas des plus sérieux.
Justement, quasi-personne ne l'utilise, ça ne tourne décemment que sous Windows, alors en vanter la portabilité et l'interopérabilité, c'est ça qui n'est pas sérieux.
C'est comme dire que le crack ou l'héroïne c'est pas dangereux sans avoir essayé, c'est pas sérieux.
Que je sache, le crack et l'héroine ne sont pas vendus avec la mention "bon pour la santé".
La portabilité et l'intéropérabilité, ça ne se décrête pas, ça se constate. Dans le temps on disait "il n'y a pas de programmes portables, il n'y a que des programmes qui ont été portés".
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
jul <saponific@ti0n.net> writes:
Le Tue, 31 May 2005 13:55:54 +0200, Michel Billaud a écrit :
... extasie ...
Un signe.
Quand à descendre C# sans l'avoir utilisé, ça ne me parait pas des
plus sérieux.
Justement, quasi-personne ne l'utilise, ça ne tourne décemment que
sous Windows, alors en vanter la portabilité et l'interopérabilité,
c'est ça qui n'est pas sérieux.
C'est comme dire que le crack ou l'héroïne c'est pas dangereux sans
avoir essayé, c'est pas sérieux.
Que je sache, le crack et l'héroine ne sont pas vendus avec la mention
"bon pour la santé".
La portabilité et l'intéropérabilité, ça ne se décrête pas, ça se
constate. Dans le temps on disait "il n'y a pas de programmes
portables, il n'y a que des programmes qui ont été portés".
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Le Tue, 31 May 2005 13:55:54 +0200, Michel Billaud a écrit :
... extasie ... Un signe.
Quand à descendre C# sans l'avoir utilisé, ça ne me parait pas des plus sérieux.
Justement, quasi-personne ne l'utilise, ça ne tourne décemment que sous Windows, alors en vanter la portabilité et l'interopérabilité, c'est ça qui n'est pas sérieux.
C'est comme dire que le crack ou l'héroïne c'est pas dangereux sans avoir essayé, c'est pas sérieux.
Que je sache, le crack et l'héroine ne sont pas vendus avec la mention "bon pour la santé".
La portabilité et l'intéropérabilité, ça ne se décrête pas, ça se constate. Dans le temps on disait "il n'y a pas de programmes portables, il n'y a que des programmes qui ont été portés".
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Eric Jacoboni
"Remi Thomas" writes:
J'ai fait des benchmark, portant un programme de morphing de C en C#. Exactement le même algo est utilisé.
Ca ne veut rien dire...
L'algo suivant :
chaine <- ''; pour i de 1 à 1000 faire chaine <- chaine + x; fin pour
implémenté en Java peut varier d'un facteur de 1 à 100 (voire plus) en temps d'exécution si on n'utilise pas les bonnes classes (un String à la place d'un StringBuilder, par exemple). J'imagine que c'est pareil en C#.
Je ne veux pas dire que c'est le cas en ce qui te concerne, c'était juste pour faire remarquer que la notion de "même algo" n'était pas suffisante pour juger d'un code exécutable.
-- Éric Jacoboni, né il y a 1421002173 secondes
"Remi Thomas" <remi@xtware.com> writes:
J'ai fait des benchmark, portant un programme de morphing de C en C#.
Exactement le même algo est utilisé.
Ca ne veut rien dire...
L'algo suivant :
chaine <- '';
pour i de 1 à 1000 faire
chaine <- chaine + x;
fin pour
implémenté en Java peut varier d'un facteur de 1 à 100 (voire plus) en
temps d'exécution si on n'utilise pas les bonnes classes (un String à
la place d'un StringBuilder, par exemple). J'imagine que c'est pareil
en C#.
Je ne veux pas dire que c'est le cas en ce qui te concerne, c'était
juste pour faire remarquer que la notion de "même algo" n'était pas
suffisante pour juger d'un code exécutable.
J'ai fait des benchmark, portant un programme de morphing de C en C#. Exactement le même algo est utilisé.
Ca ne veut rien dire...
L'algo suivant :
chaine <- ''; pour i de 1 à 1000 faire chaine <- chaine + x; fin pour
implémenté en Java peut varier d'un facteur de 1 à 100 (voire plus) en temps d'exécution si on n'utilise pas les bonnes classes (un String à la place d'un StringBuilder, par exemple). J'imagine que c'est pareil en C#.
Je ne veux pas dire que c'est le cas en ce qui te concerne, c'était juste pour faire remarquer que la notion de "même algo" n'était pas suffisante pour juger d'un code exécutable.
-- Éric Jacoboni, né il y a 1421002173 secondes
Remi Thomas
"Sébastien Kirche" écrivit
Le 31 May 2005, Remi Thomas a dit :
J'ai fait des benchmark, portant un programme de morphing de C en C#. Exactement le même algo est utilisé. Je suis 20% moins rapide en C# qu'en C.
Tiens en parlant de benchmark : où en est le C/C++ sur cette même plateforme .NET ?
Puisque tous les langages sont censés passer en IL (Intermediate Language) les perfs sont elles comparables ? Un code compilé autrefois en Visual C++ pré-NET devient-il plus lent avec les versions 2003/2005 ?
-- Sébastien Kirche
Visual Studio .NET renferme en réalité deux compilateurs C++ Celui qui génére de l'IL et celui ,classique, qui génére de l'assembleur. Cela se nomme Managed (MC++) ou Unmanaged (C++)
La syntaxe C++ pour exploiter le framework .NET est assez spécifique et c'est un poil lourd comparé au même code C#. Par contre le compilateur MC++ est le meilleur pour produire du code MSIL (le pcode) car il s'appuie sur pas mal d'année d'expérience.
Le compilateur C++ natif essaye de coller au maximum à la norme ANSI et il y a un an c'était la meilleur implémentation de cette norme sur le marché. L'optimisateur à également bien progréssé et exploite bien les spécificités des proc Intel. Il est toujours d'actualité de faire des projets en MFC ou ATL, qui ont tout deux évolués. Microsoft a ajouté pas mal d'outils pour écrire du code "safe", cad où exploiter le bug des dépassements de buffer est casi impossible.
Enfin le fait de pouvoir mixer MC++ et C++ est assez intéressant. Tu peux par exemple ouvrir une forme C# depuis une application MFC en deux lignes de code. L'idéal pour faire évoluer les gros projets. Bien entendu appeler du C++ depuis un langage .NET est encore plus simple.
Rémi
"Sébastien Kirche" écrivit
Le 31 May 2005, Remi Thomas a dit :
J'ai fait des benchmark, portant un programme de morphing de C en C#.
Exactement le même algo est utilisé.
Je suis 20% moins rapide en C# qu'en C.
Tiens en parlant de benchmark : où en est le C/C++ sur cette même
plateforme .NET ?
Puisque tous les langages sont censés passer en IL (Intermediate
Language) les perfs sont elles comparables ? Un code compilé autrefois
en Visual C++ pré-NET devient-il plus lent avec les versions 2003/2005 ?
--
Sébastien Kirche
Visual Studio .NET renferme en réalité deux compilateurs C++
Celui qui génére de l'IL et celui ,classique, qui génére de l'assembleur.
Cela se nomme Managed (MC++) ou Unmanaged (C++)
La syntaxe C++ pour exploiter le framework .NET est assez spécifique et
c'est un poil lourd comparé au même code C#.
Par contre le compilateur MC++ est le meilleur pour produire du code MSIL
(le pcode) car il s'appuie sur pas mal d'année d'expérience.
Le compilateur C++ natif essaye de coller au maximum à la norme ANSI et il y
a un an c'était la meilleur implémentation de cette norme sur le marché.
L'optimisateur à également bien progréssé et exploite bien les spécificités
des proc Intel.
Il est toujours d'actualité de faire des projets en MFC ou ATL, qui ont tout
deux évolués.
Microsoft a ajouté pas mal d'outils pour écrire du code "safe", cad où
exploiter le bug des dépassements de buffer est casi impossible.
Enfin le fait de pouvoir mixer MC++ et C++ est assez intéressant.
Tu peux par exemple ouvrir une forme C# depuis une application MFC en deux
lignes de code. L'idéal pour faire évoluer les gros projets.
Bien entendu appeler du C++ depuis un langage .NET est encore plus simple.
J'ai fait des benchmark, portant un programme de morphing de C en C#. Exactement le même algo est utilisé. Je suis 20% moins rapide en C# qu'en C.
Tiens en parlant de benchmark : où en est le C/C++ sur cette même plateforme .NET ?
Puisque tous les langages sont censés passer en IL (Intermediate Language) les perfs sont elles comparables ? Un code compilé autrefois en Visual C++ pré-NET devient-il plus lent avec les versions 2003/2005 ?
-- Sébastien Kirche
Visual Studio .NET renferme en réalité deux compilateurs C++ Celui qui génére de l'IL et celui ,classique, qui génére de l'assembleur. Cela se nomme Managed (MC++) ou Unmanaged (C++)
La syntaxe C++ pour exploiter le framework .NET est assez spécifique et c'est un poil lourd comparé au même code C#. Par contre le compilateur MC++ est le meilleur pour produire du code MSIL (le pcode) car il s'appuie sur pas mal d'année d'expérience.
Le compilateur C++ natif essaye de coller au maximum à la norme ANSI et il y a un an c'était la meilleur implémentation de cette norme sur le marché. L'optimisateur à également bien progréssé et exploite bien les spécificités des proc Intel. Il est toujours d'actualité de faire des projets en MFC ou ATL, qui ont tout deux évolués. Microsoft a ajouté pas mal d'outils pour écrire du code "safe", cad où exploiter le bug des dépassements de buffer est casi impossible.
Enfin le fait de pouvoir mixer MC++ et C++ est assez intéressant. Tu peux par exemple ouvrir une forme C# depuis une application MFC en deux lignes de code. L'idéal pour faire évoluer les gros projets. Bien entendu appeler du C++ depuis un langage .NET est encore plus simple.
Rémi
seb666fr2
Sam Hocevar <sam+ wrote in message news:<slrnd9ob1p.gui.sam+...
On Mon, 30 May 2005 18:46:08 +0000 (UTC), Michel Talon wrote:
www.shudo.net je l'ai cité moi même et tu as des benchs qui montrent la VM de Sun meilleure que celle de IBM et d'autres ou c'est le contraire. Dans tous les cas il ne s'agit pas d'écarts qui justifient le terme "ridiculiser".
Désolé, quand on crée un langage, qu'on fait tout son possible pour le protéger, empêcher sa normalisation,
tu fais référence à quoi là ? une normalisation __ISO_truc_machin_bidule__ qui ne sert à rien si ce n'est à figer les choses et rendre l'évolution quasi impossible. De plus la normalisation n'a jamais empécher les dérives, il n'y a qu'a voir ce qu'est devenu Pascal avec Borland. Sun étant le concepteur/mainteneur de java, il est tout à fait légitime que celui-ci le protège et souhaite en tirer des bénéfices tout en restant ouvert à toute proposition d'évolution/correction (cf http://www.jcp.org/en/home/index et http://bugs.sun.com/bugdatabase/index.jsp)
et qu'un concurrent a de meilleures performances sur le benchmark le plus proche de la vraie vie (SPEC JVM98), alors on est un peu ridicule.
Sam.
Tu mélanges tout là. Il y a une différence fondamentale entre la conception d'un langage et l'implémentation du compilateur et/ou de la vm permettant d'exploiter effectivement ce langage.
Sam Hocevar <sam+news@zoy.org> wrote in message news:<slrnd9ob1p.gui.sam+news@poulet.zoy.org>...
On Mon, 30 May 2005 18:46:08 +0000 (UTC), Michel Talon wrote:
www.shudo.net je l'ai cité moi même et tu as des benchs qui montrent
la VM de Sun meilleure que celle de IBM et d'autres ou c'est le contraire.
Dans tous les cas il ne s'agit pas d'écarts qui justifient le terme
"ridiculiser".
Désolé, quand on crée un langage, qu'on fait tout son possible
pour le protéger, empêcher sa normalisation,
tu fais référence à quoi là ? une normalisation
__ISO_truc_machin_bidule__ qui ne sert à rien si ce n'est à figer les
choses et rendre l'évolution quasi impossible. De plus la
normalisation n'a jamais empécher les dérives, il n'y a qu'a voir ce
qu'est devenu Pascal avec Borland. Sun étant le concepteur/mainteneur
de java, il est tout à fait légitime que celui-ci le protège et
souhaite en tirer des bénéfices tout en restant ouvert à toute
proposition d'évolution/correction (cf
http://www.jcp.org/en/home/index et
http://bugs.sun.com/bugdatabase/index.jsp)
et qu'un concurrent a de
meilleures performances sur le benchmark le plus proche de la vraie vie
(SPEC JVM98), alors on est un peu ridicule.
Sam.
Tu mélanges tout là. Il y a une différence fondamentale entre la
conception d'un langage et l'implémentation du compilateur et/ou de la
vm permettant d'exploiter effectivement ce langage.
Sam Hocevar <sam+ wrote in message news:<slrnd9ob1p.gui.sam+...
On Mon, 30 May 2005 18:46:08 +0000 (UTC), Michel Talon wrote:
www.shudo.net je l'ai cité moi même et tu as des benchs qui montrent la VM de Sun meilleure que celle de IBM et d'autres ou c'est le contraire. Dans tous les cas il ne s'agit pas d'écarts qui justifient le terme "ridiculiser".
Désolé, quand on crée un langage, qu'on fait tout son possible pour le protéger, empêcher sa normalisation,
tu fais référence à quoi là ? une normalisation __ISO_truc_machin_bidule__ qui ne sert à rien si ce n'est à figer les choses et rendre l'évolution quasi impossible. De plus la normalisation n'a jamais empécher les dérives, il n'y a qu'a voir ce qu'est devenu Pascal avec Borland. Sun étant le concepteur/mainteneur de java, il est tout à fait légitime que celui-ci le protège et souhaite en tirer des bénéfices tout en restant ouvert à toute proposition d'évolution/correction (cf http://www.jcp.org/en/home/index et http://bugs.sun.com/bugdatabase/index.jsp)
et qu'un concurrent a de meilleures performances sur le benchmark le plus proche de la vraie vie (SPEC JVM98), alors on est un peu ridicule.
Sam.
Tu mélanges tout là. Il y a une différence fondamentale entre la conception d'un langage et l'implémentation du compilateur et/ou de la vm permettant d'exploiter effectivement ce langage.
Luc Hermitte
"Remi Thomas" wrote in news:429ca454$0$163$:
Visual Studio .NET renferme en réalité deux compilateurs C++ Celui qui génére de l'IL et celui ,classique, qui génére de l'assembleur. Cela se nomme Managed (MC++) ou Unmanaged (C++)
Il semblerait que MC++ devienne C++/CLI. L'interfaçage avec .NET est simplifié. Plein de trucs à lire sur les blogs de Herb Sutters et ailleurs.
La syntaxe C++ pour exploiter le framework .NET est assez spécifique et c'est un poil lourd comparé au même code C#.
Cela change donc avec C++/CLI. Et ils vendent (dans les blogs des gens qui bossent sur C++/CLI) C# pour l'assemblage et C++/CLI pour les composants/bibliothèques qui doivent être rapides/critiques/métier/... (liste issue de mon appréciation subjective de ce que j'avais lu)
Le compilateur C++ natif essaye de coller au maximum à la norme ANSI et il y a un an c'était la meilleur implémentation de cette norme sur le marché.
Meilleur que les compilos qui reposent sur EDG ? J'ai un petit doute -- ceci dit, ils se tiennent (quand on compare avec les trucs plus anciens)
-- Luc Hermitte
"Remi Thomas" <remi@xtware.com> wrote in
news:429ca454$0$163$a3f2974a@nnrp1.numericable.fr:
Visual Studio .NET renferme en réalité deux compilateurs C++
Celui qui génére de l'IL et celui ,classique, qui génére de
l'assembleur. Cela se nomme Managed (MC++) ou Unmanaged (C++)
Il semblerait que MC++ devienne C++/CLI. L'interfaçage avec .NET est
simplifié. Plein de trucs à lire sur les blogs de Herb Sutters et
ailleurs.
La syntaxe C++ pour exploiter le framework .NET est assez spécifique
et c'est un poil lourd comparé au même code C#.
Cela change donc avec C++/CLI.
Et ils vendent (dans les blogs des gens qui bossent sur C++/CLI) C# pour
l'assemblage et C++/CLI pour les composants/bibliothèques qui doivent
être rapides/critiques/métier/... (liste issue de mon appréciation
subjective de ce que j'avais lu)
Le compilateur C++ natif essaye de coller au maximum à la norme ANSI
et il y a un an c'était la meilleur implémentation de cette norme sur
le marché.
Meilleur que les compilos qui reposent sur EDG ? J'ai un petit doute --
ceci dit, ils se tiennent (quand on compare avec les trucs plus anciens)
Visual Studio .NET renferme en réalité deux compilateurs C++ Celui qui génére de l'IL et celui ,classique, qui génére de l'assembleur. Cela se nomme Managed (MC++) ou Unmanaged (C++)
Il semblerait que MC++ devienne C++/CLI. L'interfaçage avec .NET est simplifié. Plein de trucs à lire sur les blogs de Herb Sutters et ailleurs.
La syntaxe C++ pour exploiter le framework .NET est assez spécifique et c'est un poil lourd comparé au même code C#.
Cela change donc avec C++/CLI. Et ils vendent (dans les blogs des gens qui bossent sur C++/CLI) C# pour l'assemblage et C++/CLI pour les composants/bibliothèques qui doivent être rapides/critiques/métier/... (liste issue de mon appréciation subjective de ce que j'avais lu)
Le compilateur C++ natif essaye de coller au maximum à la norme ANSI et il y a un an c'était la meilleur implémentation de cette norme sur le marché.
Meilleur que les compilos qui reposent sur EDG ? J'ai un petit doute -- ceci dit, ils se tiennent (quand on compare avec les trucs plus anciens)
-- Luc Hermitte
Manuel Leclerc
D'autres ont-il aussi testé .NET en cross-plateforme et qu'en pensent-ils ?
Wikipedia vient de remplacer son moteur de recherche/indexation en Java par une version .NET sous Mono.
