La décision du Gnome release team vient de tomber : Avec la sortie d'ici quelques mois de Gnome 2.16 une nouvelle dépendance va être introduite.
Je colle l'extrait :"New modules may be accepted into the desktop or admin releases with a dependency on gtk#/mono"
Le mail : http://mail.gnome.org/archives/devel-announce-list/2006-Augu(...)
Et en français ça veut dire quoi ?
Cela signifie que si un soft utilisant Mono est jugé assez bien par la release team il pourra être inclu dans Gnome (c'est d'ores et déjà le cas avec Tomboy). Cela va donc obliger les utilisateurs de Gnome à avoir Mono et le binding GTK# sur leur ordi.
C'est une décision très controversé du fait de l'incertitude juridique et technique autour de Mono (lire à ce sujet l'article de Fabrice Rossi : http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf ).
Pour les irréductibles réfractaires à Mono il reste XFCE qui devient vraiment bien et dont la release 4.4 promet de roxer.
Il va également y avoir beaucoup de changements dans KDE avec le passage en version 4.0 et les gnomistes réfugiés peuvent espérer une grosse refonte de l'interface utilisateur afin de se rapprocher de la simplicité de Gnome.
Journal Mono et Gnome
2
août
2006
# maxi-Troll
Posté par patrick_g (site web personnel) . Évalué à -1.
# pour ou contre ?
Posté par dinomasque . Évalué à 3.
J'ai tendance à ne voir que les aspects sympathiques de Mono (les applications que j'aime bien comme Tomboy ou Muine et tous leurs copains http://www.osnews.com/story.php?news_id=9780 ).
Quelle est cette incertitude juridique et technique autour de .NET ?
BeOS le faisait il y a 20 ans !
[^] # Re: pour ou contre ?
Posté par patrick_g (site web personnel) . Évalué à 5.
http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf
C'est long mais ça vaut vraiment le coup de le lire.
[^] # Re: pour ou contre ?
Posté par romain . Évalué à -9.
Je n'irai pas lire cette article, pour deux simples raisons :
* c'est un pdf ; juste la paresse d'ouvrir un logiciel supplémentaire pour le lire ;
* c'est long (tu le dis toi-même), et j'ai autre chose à faire que de la lecture rapide.
Dommage. Pour moi, peut être, mais aussi surtout pour le message à faire passer.
[^] # Re: pour ou contre ?
Posté par plagiats . Évalué à 5.
[^] # Re: pour ou contre ?
Posté par Nap . Évalué à 1.
Ton navigateur ne l'ouvre pas via un plugin ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pour ou contre ?
Posté par Sylvain Sauvage . Évalué à 0.
[^] # Re: pour ou contre ?
Posté par dinomasque . Évalué à 4.
BeOS le faisait il y a 20 ans !
[^] # Re: pour ou contre ?
Posté par TImaniac (site web personnel) . Évalué à 5.
Moi je reprocherai à cet article de ne pas comparer avec les autres logiciels libres. En effet, il peut y avoir des problèmes juridiques avec Mono, mais il ne démontre à aucun moment qu'il n'y a aucun problème avec les autres logiciels libre.
De plus cet article n'est plus à jour (et c'est fort dommage vu qu'il sert souvent de "référence"). Hors depuis sa rédaction, Mono est protégé par l'Open Inventive Network, sorte de gros sac à brevets alimentés par IBM, Philips et autre Novell ou Red Hat pour riposter contre d'éventuelle attaque.
De plus Novell détient aujourd'hui les brevets les plus dangereux sur .NET : ceux sur les web-services, ca encore c'est pas dans l'article, alors que c'est une des clés de la sécurité juridique de Mono.
Au final j'ai envie de dire qu'avec tout le rafus juridique autour de Mono, c'est une des plateformes où l'on a paradoxalement le plus de certitudes.
[^] # Re: pour ou contre ?
Posté par boris . Évalué à 3.
Novell reste une bonne grosse boite, et si en ce moment linux à la côte chez eux, un changement dans l'équipe de direction pourrait fort bien tout remettre en question. Là je pense evidemment à SCO, qui à une époque soutenait plutôt ce qui tournait autour de Linux, et maintenant tout le monde sait ce que c'est devenu...
Alors, ceci dit je n'ai pas non plus analysé en détail la "profondeur" de l'implication de Novell, càd à quel point suse+ximian comptent dans leur balance.
Simplement le fait qu'ils fassent un tel "pushing" de Mono au sein de Gnome m'incite à la prudence. Mais c'est mon avis qui n'engage que moi ^^
# Le passage Mono dans le document
Posté par plagiats . Évalué à 9.
(Page 14).
Le problème est donc simple :
* Pour les US, est-ce que ce fameux brevet a été validé ? L'article date de 2004.
* Pour le reste, est-ce qu'il y a un autre problème que ce brevet ? Nan ? Bah alors ?
[^] # Re: Le passage Mono dans le document
Posté par patrick_g (site web personnel) . Évalué à 10.
Mais il ne faut pas oublier le problème technique : alors que les utilisateurs supplient les devs de faire quelque chose à propos de la lourdeur de Gnome, alors que KDE écrase Gnome sur le plan de la rapidité et de la fluidité, quelle est la réction des devs et quelle est la direction qui est empruntée ? Ajouter une bonne grosse machine virtuelle dans Gnome !!!!!!!!!
Il est évident que cette dépendance introduite ici va être utilisée par pleins de logiciels et qu'il va devenir impossible d'être un gnomiste sans utiliser Mono.
Conclusion : Vivement KDE 4.0. Le seul truc qui me retenait d'avoir une Kubuntu au lieu d'une Ubuntu c'est le fouillis bordélique que constitue KDE. Si ça s'améliore radicalement avec la 4.0 je switcherais sans regret.
[^] # Re: Le passage Mono dans le document
Posté par plagiats . Évalué à 1.
[^] # Re: Le passage Mono dans le document
Posté par Nap . Évalué à 1.
[^] # Re: Le passage Mono dans le document
Posté par Nicolas Schoonbroodt . Évalué à 5.
(je suis déjà très, très loin, dehors)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le passage Mono dans le document
Posté par kraman . Évalué à 2.
Et pas la peine de me sortir une appli java avec gui AWT ou SWING codee avec les pieds qui tourne sur une jvm 1.2, parce que sinon je vous ressort des applis codee en C avec les pieds qui seg fault toutes les 5 minutes.
Et pas du "mais c'est compile a la volee, c'est forcement plus lent" non plus, du concret avec des chiffres, qui prouvent qqchose.
Niveau ram, ca c'est clair, ca bouffe beaucoup plus. Mais avec des machines milieu de gamme qui approche les 2Go c'est beaucoup moins problematique.
Niveau CPU, bof. Pas convaincu non plus.
Et quand on voit le temps gagne en dev a utiliser des langages haut niveau, ca ne peut que etre benefique.
[^] # Performance des langages
Posté par viking . Évalué à 10.
http://shootout.alioth.debian.org/
c++ vs C# mono par exemple.
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
Après je te laisse tirer les conclusions que tu veux.
[^] # Re: Performance des langages
Posté par kraman . Évalué à 3.
Et surtout ne passent pas la plupart du temps en attente d'input dans la gui...
[^] # Re: Performance des langages
Posté par mickabouille . Évalué à -3.
[^] # Re: Performance des langages
Posté par kraman . Évalué à -4.
qu'est ce qu'on entends par complexite en algorithmique en general?
[^] # Re: Performance des langages
Posté par Yusei (Mastodon) . Évalué à 3.
Après, je suppose que dans le bench c'est codé récursivement, donc que c'est un peu plus lourd. En même temps, la récursivité est pas mal utilisée, donc c'est bien de savoir si une plateforme la gère bien.
[^] # Re: Performance des langages
Posté par Gof (site web personnel) . Évalué à 1.
(dont tout le monde sait qu'il est en O(log n) )
http://linuxfr.org/comments/714501.html#714501
[^] # Re: Performance des langages
Posté par kraman . Évalué à 1.
[^] # Re: Performance des langages
Posté par kahal (site web personnel) . Évalué à 2.
-g++ x times better
Program & Logs : Faster | Smaller: Memory Use | Smaller: Code Lines
startup : -15 | -3.5 | 1.3
Ah oui, startup c'est juste un hello world :
using System;
class hello {
public static void Main(String[] args) {
Console.WriteLine("hello world");
}
}
Ça te va comme opération de base ?
[^] # Re: Performance des langages
Posté par kraman . Évalué à -7.
mais c'est vachement interessant dis moi!!!
et dis moi, mon canard, t'en connais beaucoup des programmes a une (1) ligne de code?
t'en fais quoi de ce truc?
concretement, mis a part enculer des mouche et te branler sur la tete de ton compilo C, t'essayes de dire quoi?
qu'une vm ca met du temps a partir? Supeeeeer, kahal viens nous eclairer de sa grande lumiere, il lui a fallu le bench shootout en 2006 pour qu'il decouvre le temps de chauffe, merci de cette intervention.
T'as quelque chose d'autre a rajouter ou il te faut encore 6 mois pour decouvrir qu'une vm consomme plus de ram que l'equivalent en natif?
[^] # Re: Performance des langages
Posté par Duncan Idaho . Évalué à 9.
Et j'en passe.
Non seulement tu nages dans la mauvaise foi (l'algorithme est trop compliqué/trop simple/pas adapté pour montrer que mono est mieux), mais tu es carrément malpoli.
Je t'invite à te taire et à te faire oublier rapidement.
[^] # Re: Performance des langages
Posté par kraman . Évalué à -6.
Je voudrais bien avoir une explication de ce que bench hello world. On va voir s'il fera autant le malin
mais tu es carrément malpoli.
quitte a troller autant faire les choses correctement et en profiter pour une jolie joute verbale. M'enfin tout se perd ma bonne dame.
[^] # Re: Performance des langages
Posté par Goth . Évalué à 2.
tous les programmes en console : c'est agréable quand ils répondent directement, s'ils mettent 15x plus de temps pour juste afficher une ligne comme quoi on s'est trompé d'argument c'est génant, enfin pour moi surtout :)
[^] # Re: Performance des langages
Posté par kraman . Évalué à 1.
pis bon, on parle de desktop la...
[^] # Re: Performance des langages
Posté par Goth . Évalué à 3.
Par exemple, pour compiler des documents latex avec des figures aux formats multiples dont le SVG, Inkscape [C++/Gtkmm] fourni des options en lignes de commandes pour convertir les fichiers SVG en PS ou EPS. Très pratique pour mettre dans les makefiles.
% inkscape --export-text-to-path --export-eps=toto.eps toto.svg
% inkscape --export-text-to-path --export-eps $@ $<
Un lancement rapide (voir très rapide) est alors nécessaire pour convertir plusieurs dizaines de fichiers.
[^] # Re: Performance des langages
Posté par Yusei (Mastodon) . Évalué à 2.
Je n'étais pas au courant que la complexité de fibo était un sujet de troll... tu ne confondrais pas trolls et erreurs ?
[^] # Re: Performance des langages
Posté par Nicolas Schoonbroodt . Évalué à 9.
Certains pense que dire "Gnome est mieux que KDE" est un troll, alors qu'en fait, c'est une erreur.
[^] # Re: Performance des langages
Posté par viking . Évalué à 4.
Certes ce ne sont que des tests de bases. Mais si tu as un vrai benchmark (pas un fait par bibi, quoi), je n'attends que cela. Je veux bien te croire mais ils faudrait trouver des benchmarks qui vont comparer d'une manière significative des librairies différentes.
Comme je le pensais, je vois que tu as déjà tes propres conclusions indéboulonnables. Et je me demande bien qui tu essaies de convaincre, toi ou les autres ?
PS. tu n'es pas obligé d'insulter les autres forumeurs.
[^] # Re: Performance des langages
Posté par Jux (site web personnel) . Évalué à 1.
[1]http://jasondclinton.livejournal.com/52994.html
[2]http://www.beatniksoftware.com/tomboy/
[^] # Re: Performance des langages
Posté par Éric (site web personnel) . Évalué à 10.
[^] # Re: Performance des langages
Posté par Agalaz . Évalué à 7.
Et sinon, c'est un peu facile de dire "java c'est pas plus lent" pour après se rétracter "mais heu, les applis attendent un input donc ça change rien". Faut savoir. Java c'est pas plus lent, ou sa lenteur est tolérable dans l'idée que tu te fais des applications desktop ?
Soit honnête. Dis-le ouvertement, comme tu viens de le faire, "les applis attendent une input donc on peut tolérer la lenteur de java", mais ne viens pas dire ça :
"Perso, j'attends toujours qu'on me prouve que les applis ecrites dans des langages a vm sont *vraiment* plus lentes que les applis natives."
[^] # Re: Performance des langages
Posté par kraman . Évalué à 1.
[^] # Re: Performance des langages
Posté par lezardbreton . Évalué à 6.
[^] # Re: Performance des langages
Posté par kraman . Évalué à -2.
1) java n'est pas lent dans l'absolu. Qu'il mette 0.7 ms a faire un truc la ou C++ en mettra 0.6, de toutes facon j'ai pas une horloge bionique dans la tete donc je verrais pas la difference.
2) De toutes facons on s'en cogne passque l'application va passer la plupart du temps a rien branler.
Une application swing bien codee ou SWT pas trop mal codee sera reactive. J'ai deja fait du swt, faut qu'on te dise que c'est du java pour que tu t'en doutes.
Regarde eclipse sous windows, sous reserve que tu aies suffisament de ram (un bon 512 si le projet est pas trop gros) ca reagit tres vite, au moins autant qu'un visual studio (et pourtant il fait bien plus de choses). Ca met beaucoup plus de temps a se lancer par contre, ca ya pas photo.
[^] # Re: Performance des langages
Posté par Volnai . Évalué à 9.
Par contre est-ce que le fait que la consommation mémoire soit importante ne pose un problème ? Par exemple, si tu mets ton appli en tache de fond, que la jvm ne fait plus rien, quand tu vas vouloir l'utiliser à nouveau, l'os risque de devoir la remonter de la swap avec toute ses pages mémoires, et là, question réactivité, ça peut faire mal, non ?
[^] # Re: Performance des langages
Posté par kraman . Évalué à 2.
Sans compter qu'il faut prendre en compte l'etat d'esprit de l'utilisateur (stresse et a la bourre le matin au taff avant un reunion super importante ou sortant du bar plein comme une loutre avec un 4 feuilles dans les mains a 2h30 du tinma un 'medi soir en trainde troller sur dlfp).
Une appli bien designee mais lente paraitra plus reactive qu'une appli rapide sans aucun feedback.
Bon, ca marche dans l'autre sens aussi, une appli rapide avec un bon feedback paraitra plus rapide qu'un truc lent sans feedback.
Tout ca pour dire : savior que C# execute mandelbrot en 34.75 secondes la ou C++ le fait en 29, on s'en contrebalance, nanapété.
On peut tout a fait utiliser un langage a vm pour faire des applis desktops agreables et c'est tout ce qui importe.
Bref, le choix du langage tient plus dans les contraintes du projet (besoin d'acces a un bas niveau, maintenabilite, rapidite de dev etc.) que dans un concours de grosse teub de mec qui arrive a optimiser au max un algo qui ne sera jamais utilise par personne.
[^] # Re: Performance des langages
Posté par Agalaz . Évalué à 7.
Picasa sous wine est plus rapide qu'f-spot.
[^] # Re: Performance des langages
Posté par kraman . Évalué à 2.
Maintenant si tu veux des applis lourde et lente ecrite en C, je peux t'en sortir aussi.
J'ai vu pas mal d'appli reactives dans des langages a vm, et pas forcement codee par des gurus, c'est donc que c'est possible, quoiqu'en disent les refractaires aux technos qui ont moins de 15 ans.
[^] # Re: Performance des langages
Posté par Agalaz . Évalué à 6.
Si ça multiplie tant que ça la productivité vos nouveaux langages pourquoi les développeurs mono font que des trucs tout pourri ? pourquoi depuis le temps qu'existe java on a pas de GIMP-like ou de bonne appli de gestion de photo ? les développeurs java sont-ils condamnés à faire des trucs quick&dirty pour les entreprises, n'atteindront jamais le desktop ?
Des applis lentes en C/C++ j'en connais. OpenOffice en est le meilleur représentant. Ou Nautilus. Le problème, c'est que je connais aussi d'excellentes applis dans des domaines tous très différents en C/C++. Je ne connais pas d'excellente appli desktop en java.
[^] # Re: Performance des langages
Posté par kraman . Évalué à 2.
Deployer une appli desktop java, faut avoir la jvm sur le poste client, ca pese 40Mo et c'est un peu lourd a faire.
Moins chiant de deployer une appli linkee en statique que de devoir presuposer de la capacite a installer une jvm.
Pour le graphisme, java est plombe par swing qui est une mauvaise api de gui (trop lourd et complexe, faut etre expert pour en faire qqchose). Swt est trop jeune a mon gout et assez recent dnas le monde java, mais tres prometteur.
Pour mono, j'ai installe, j'ai regarde monodevelop je crois qui est l'ide. Ben j'ai passe a la soiree prit d'un fou rire monstrueux. Va leur falloir un ide aux bonhommes, passque la ils vont pas aller tres loin avec ce qu'ils ont. Ceci explique peut etre cela.
Pour les perfs, voir aussi l'implem du runtime (regarde la jvm linux qui est clairement a chier : je le dit haut et fort java sun sous linux ca vaut pas tripette. Par contre sous windows ca tourne tres tres bien).
[^] # Re: Performance des langages
Posté par Florent Bayle (site web personnel) . Évalué à 1.
Euh... Le déploiement et la portabilité, c'était pas censé être les points forts des langages interprétés (et de java en particulier) ?
[^] # Re: Performance des langages
Posté par kraman . Évalué à 3.
[^] # Re: Performance des langages
Posté par TImaniac (site web personnel) . Évalué à 6.
Ca c'est un très mauvais exemple, vu que le control d'affichage d'une image dans f-spot est écrit en... C. Comme quoi le problème ne vient pas du langage mais du codeur.
[^] # Re: Performance des langages
Posté par Agalaz . Évalué à 2.
Mais maintenant que tu dis ça.. ils n'ont pas confiance en mono pour coder l'affichage en c# ?
[^] # Re: Performance des langages
Posté par Yusei (Mastodon) . Évalué à 5.
[^] # Re: Performance des langages
Posté par kraman . Évalué à 3.
Mais faut vraiment maitriser l'api.
Bon, perso je suis davis a mettre swing a la poubelle et le remplacer par swt qui est quand meme nettement plus agreable a coder et avec un meilleur rendu visuel.
[^] # Re: Performance des langages
Posté par dinomasque . Évalué à 2.
Ou alors c'est juste que tous les développeurs Java sont complètement nuls en Swing ...
BeOS le faisait il y a 20 ans !
[^] # Re: Performance des langages
Posté par golum . Évalué à 6.
Tu crois pas qu'il y a assez de trolls là au milieur pour ne pas en lancer un autre. Je t'ai à l'oeil, ca fait 2 fois ;-)
[^] # Re: Performance des langages
Posté par kraman . Évalué à 2.
ouais, mais bon, j'en ai marre que swing et les gens qui l'utilisent mal (sont nombreux, j'en fait partie) contribuent a ce que la reputation de lenteur de java 1.2 dure jusqu'a java 7.
Alors si je peux en profiter pour lui casser du suc' sur le dos, je vais pa me gener.
faut juste que swt murisse encore un touuuut p'ti peu et ca serait nickel.
[^] # Re: Performance des langages
Posté par viking . Évalué à 2.
La réactivité d'Eclipse serait donc plutot à mettre sur le compte de l'API graphique de l'OS.
Et comme tu le dis Swing écrit en Java est à mettre à la poubelle. ;)
[^] # Re: Performance des langages
Posté par golum . Évalué à 4.
La portion de binding de SwT est négligeable par rapport à l'ensemble de la lib.
Swing ou plutôt AWT aussi fait appel aux primitives graphiques de l'OS.
Le problème de Swing vient surtout du cahier des charges originel.
La lib devait être thémable en dynamique. Donc le code est plus conséquent plus difficile à faire évoluer ....
[^] # Re: Performance des langages
Posté par kraman . Évalué à 2.
L'interet de swt (et de toute lib de GUI en general) c'est pas les widgets en soi, c'est le modele derriere, comment tu stockes les objets dans tes widgets, les layouts, ce genre de chose. Et tout ca ben c'est du java. La partie native c'est juste l'affichage des widgets, soit pas grand chose au final (316ko de dll, 1.5Mo de jar).
Quand a la reactivite d'eclipse, SWT ne s'occupe pas de la compile a la volee, du refactoring, des wizards de creations de projets et d'autres trucs de ce genre.
Et c'est ca qui bouffe des ressources, pas les 3 fenetres et les 2 onglets affiches.
[^] # Re: Performance des langages
Posté par Agalaz . Évalué à 3.
Rien. Dans un autre message j'ai déjà fait remarqué que j'ai vu de très bonnes apps avec une interface scriptée et un coeur en C.
Le problème c'est que des gens ici, et ailleurs sur le net, essaient de faire croire que Java ou c# c'est proche de la rapidité du C. Si c'est tant proche de la rapidité du C, j'attends des apologistes autre chose que des biblio C.
[^] # Re: Performance des langages
Posté par kraman . Évalué à 2.
pour faire tout et rien, une floppee de choses diverses et variees.
On utilise assez peu le natif en java pour deux raisons tres simples :
1) jni, c'est tres chiant a mettre en place et ca pete tres vite.
2) c'est un peu con vu que l'interet meme de java est justement de pas avoir de natif.
En gros ca se fait quand vraiment tu peux pas faire autrement.
Je t'invite a jeter un oeil a apache commons, jdom, json, tout ce qui se fait sur les serveurs d'appli (jsp/jsf tout ce genre de conneries et les machins qui gravitent autour) etc.
Google n'est pas ton ami vu que t'as pas du trop chercher.
Maintenant, c'est sur que si t'attends une glibc ou libstdc++ en java, t'es pas pret de la voir arriver.
[^] # Re: Performance des langages
Posté par golum . Évalué à 1.
et si ca avait ete le contraire tu nous qurait sorti
"Pourquoi ils recodent dasn leur coin des libs qui existent déjà? Ils connaissent pas la réutilsation ?".
Puis après tu nous sors un peu qu'il avancent pas dans leur projet.
Donc ils sont déjà à la bourre mais il faudrait tout réecrire.
Dans le genre trolleur toi !
[^] # Re: Performance des langages
Posté par kraman . Évalué à 2.
ca met du temps a partir, mais une fois que 'est parti ca tourne aussi vite.
Teste de visu par bibi sur du java, c'est impressionant (un facteur 2 (ie passe de 3 fois plus lent que la ref en fortran a 1.4 fois plus lent) sur des applis scientifique en fonction de la taille des donnees en input).
Bref, c'est sur que bencher un langage comme ca sur des tirs ultra court, ca va te donner des perfs de merde.
Maintenant, j'ai pas l'impression qu'en desktop je passe mon temps a lancer une appli pour l'arreter 2.5 secondes apres.
Sans compter que je suis loin d'etre convaincu que la vm mono soit au top, il aurait ete plus judicieux de prendre celle de microsoft en reference.
[^] # Re: Performance des langages
Posté par scand1sk (site web personnel) . Évalué à 2.
La plupart des solveurs de CSP sont codés en Java, bien que ce soient par essence des programmes purement algorithmiques et forçant fortement sur le CPU.
Le principe est simple : un millier de problèmes différents sont donnés en entrée au solveur, le solveur a un temps défini pour résoudre le problème (10 minutes pour la compétition il me semble). Le programme ayant résolu le plus de problèmes est le vainqueur.
Il faut regarder la Table 4 page 12 du PDF pour voir les résultats généraux.
Les deux solveurs vainqueurs sont deux variantes du même solveur, codé en C. Les deux suivants sont deux variantes d'un solveur Java (la différence tient dans un mouchoir de poche, et vient plus de problèmes d'occupation mémoire que de temps, si on regarde les résultats de plus près), le 5e est en C, le 6e en Java. Les autres je ne sais pas, mais les deux derniers solveurs au classement étaient buggés, et étaient codés en C++...
[^] # Re: Performance des langages
Posté par viking . Évalué à 5.
Ou alors, j'ai rien compris ;) ce qui serait pas étonnant pour un vendredi soir (enfin presque pour moi c'est mon dernier jour de la semaine)
[^] # Re: Performance des langages
Posté par scand1sk (site web personnel) . Évalué à 3.
[^] # Re: Le passage Mono dans le document
Posté par Agalaz . Évalué à 9.
Je veux un exemple d'une suite office, d'un moteur d'affichage HTML, d'un The GIMP/photoshop killer, explorateur de fichiers [...] rapide. mais ça n'existe pas. L'industrie est-elle stupide ? les programmeurs se font-ils chier avec C/C++ uniquement pour le plaisir ? je ne crois pas. Les faits sont là : que ce soit les applis de musique assistée par ordi, de graphisme etc qu'il m'ai été donné de toucher, à part jMax, je n'ai jamais vu une appli en java/dotnet/python/perl/ruby. Certaines applis ont un langage de script pour l'interface, mais le coeur de l'appli est codé en C/C++.
Les langages à VM ou ceux scriptés, ça va pour faire quelques interfaces graphiques, à la limite. Mais il doit y avoir un coeur natif pour avoir une appli agréable à utiliser.
[^] # Re: Le passage Mono dans le document
Posté par kraman . Évalué à -1.
dans le genre gros costaud et rapide, dur de trouver mieux.
Ca bouffe beaucoup de ram mais tourne tres bien sur un proco lent/moyen, preuve en est que le probleme n'est pas la rapidite mais la quantite de ram utilisee.
Pour les ihm, je conviens que swing est au mieux particulierement dur a utiliser correctement, au pire une bouse sans nom.
Swt corrige le tir mais n'est pas encore assez mur a mon gout.
Maintenant, ya pas que java comme langage a VM, hein, je doute pas que .Net va percer sur le desktop.
Pour les applis de musique, le gros probleme vient surement du besoin d'etre proche du matos (la latence est tres critique dans ces applis).
[^] # Re: Le passage Mono dans le document
Posté par Éric (site web personnel) . Évalué à 9.
> dans le genre gros costaud et rapide, dur de trouver mieux.
On ne doit franchement pas avoir le même ressenti, j'aurai d'ailleurs presque pu donner eclipse comme nom de gros truc énorme en java.
[^] # Re: Le passage Mono dans le document
Posté par kraman . Évalué à 2.
La faute a la jvm sun qui est a chier.
Sous windows c'est assez etonnant de rapidite.
[^] # Re: Le passage Mono dans le document
Posté par Jean-Philippe (site web personnel) . Évalué à 1.
http://www.jokosher.org/ (ok, c'est basé sur gstreamer quand même)
[^] # Re: Le passage Mono dans le document
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 3.
;-)
[^] # Re: Le passage Mono dans le document
Posté par golum . Évalué à 2.
http://codespeak.net/pypy/dist/pypy/doc/news.html
[^] # Re: Le passage Mono dans le document
Posté par dinomasque . Évalué à 6.
BeOS le faisait il y a 20 ans !
[^] # Re: Le passage Mono dans le document
Posté par Hojo . Évalué à 1.
Par contre, c'est au niveau CPU et memoire que cela peut etre embettant je trouve, j'ai pas vraiment regarde mais si c'est trop a mon gout, a mois d'etre une appli critique, direction /dev/null
En meme temps on rale pour les appli mono, mais les applis python et consort, je les trouve "pas mal" aussi...
[^] # Re: Le passage Mono dans le document
Posté par lolop (site web personnel) . Évalué à 2.
Ce qui fait qu'il n'y a plus que la logique de haut niveau qui passe par la machine virtuelle (bon, c'est sûr qu'un lourd calcul dans cette couche... et ça s'écroule - mais bonne nouvelle, il y a aussi des bindings vers des librairies de calcul en natif genre traitement d'image & Co).
De plus, pour Java (et je pense C# - faut voir ce qui en est pour Mono), il y a la possibilité de compilation à la volée (ie. le byte code est compilé en natif lors du premier appel, après c'est direct). Ca améliore nettement les perfs.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Le passage Mono dans le document
Posté par reg . Évalué à -4.
Ensuite, à l'heure ou tout le monde ici pleure pour que Linux s'impose sur le desktop, tu veux fermer cette possibilité de developper des applis (géniales, tu l'a dit toit même) facilement gràce à gtk#, ou que l'on attende des millenaires qu'un désoeuvré passe 3 mois pour refaire un simple magnétophone en C/Gtk ?
Bref, bonne nouvelle, de mon point de vue ; cela dit, je n'utilise pas Gnome :)
[^] # Re: Le passage Mono dans le document
Posté par patrick_g (site web personnel) . Évalué à 10.
Oui et j'ai viré Beagle vite fait.
>> tu veux fermer cette possibilité de developper des applis (géniales, tu l'a dit toit même) facilement gràce à gtk#
Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ? Sans compter le fait d'utiliser une techno Microsoft dangeureuse sur le plan juridique.
Avec le binding Python il est possible de créer facilement une appli Gnome donc l'argument de la simplicité ne tient pas une atto-seconde.
[^] # Re: Le passage Mono dans le document
Posté par lezardbreton . Évalué à 9.
Si python/GTK avait déroulé le même plan marketing, les choses auraient surement été différentes.
[^] # Re: Le passage Mono dans le document
Posté par Yusei (Mastodon) . Évalué à 1.
Ça fait plusieurs fois que je vois des gens juger Mono à partir de Beagle ou F-Spot... vous avez vu le numéro de version de ces logiciels ? Beagle est une 0.2.x, et fspot une 0.1.x.
Python est interprété. Il n'y a aucune différence entre un interpréteur et une machine virtuelle. Généralement, on dit "interpréteur" quand le langage est interprété tel quel, et "machine virtuelle" quand il est d'abord traduit en "bytecode" qui est ensuite interprété, mais la séparation entre les deux est très floue. Quand tu fais du Python, du Ruby, du PHP... tu utilises une machine virtuelle (ce n'est pas sale).
Par contre, c'est sûr qu'un desktop qui utilise des applis Python, Ruby et Mono doit charger trois machines virtuelles, et c'est d'autant plus lourd. Moralité: il faut que tout le monde utilise Python.NET et Ruby.NET, pour n'avoir que Mono :)
(je rigole, utilisez Parott)
[^] # Re: Le passage Mono dans le document
Posté par lezardbreton . Évalué à 5.
[^] # Re: Le passage Mono dans le document
Posté par Yusei (Mastodon) . Évalué à 6.
Après, pour le deuxième point, j'ai brièvement regardé C# et les libs fournies par Mono, et ça n'a pas l'air moins bien que Java, mais ça n'a rien de transcendant non plus. Je ne suis pas allé très loin dans mon expérience, mais je pense que si Beagle traine c'est plutôt:
1- parce que c'est difficile à faire
2- parce que ça manque de devs, ou bien que ça en a manqué pendant longtemps
3- à cause de problèmes d'organisation
Pendant longtemps, pour tester Beagle il fallait patcher le noyau, activer des options au niveau du système de fichiers, bref, ça n'aidait pas à s'impliquer. Je pense qu'il y a eu trop de buzz autour de ce truc avant qu'il soit suffisamment avancé.
[^] # Re: Le passage Mono dans le document
Posté par TImaniac (site web personnel) . Évalué à 0.
Et t'as mis quoi à la place ? T'as une autre solution moins buggué/moins consommatrice de ressources ?
Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ?
Ben pour justement laisser le choix aux développeurs ? Pourquoi accuser la lourdeur et la lenteur d'une appli Mono quand une appli Python a les mêmes désavantages en plus accentués ?
Ensuite ca serait bien d'arrêter de parler d'une "bonne grosse" machine virtuelle de la "lourdeur" d'une machine virtuelle, on parle d'un truc "virtuel", ca serait bien de le rappeler, concrêtement elle n'existe pas, c'est un concept purement intellectuel pour le développeur, c'est une couche d'abstraction lors de la phase de développement. D'ailleur on peut dire que GCC a une machine virtuelle qui est représenté par l'ensemble des instructions disponibles dans son langage intermédiaire "indépendant" du processeur.
Il y a un aspect plus "lourd" mais il ne vient pas de la machine virtuelle en soit, mais des services fournis par l'environnement d'exécution : garbage collector, isolation mémoire, sécurité, etc. On a beau dire tout ce qu'on veut, ces services contribuent à la qualité d'un soft, tous les langages modernes l'ont compris. De plus de nombreuses applis écritent dans des langages comme C/C++ réinventent la roue et "simulent" ces services, introduisant la même lourdeur.
Sans compter le fait d'utiliser une techno Microsoft dangeureuse sur le plan juridique.
Faut arrêter le FUD à 2 balles. Je vais donc recommencer : si y'a des brevets dangereux sur .NET, et qui existent, ils sont sur les web-services... et c'est Novell qui les détient. Ensuite Mono est protégé par l'initiative des éditeurs du monde open-source visant à offrir une sécurité juridique à ces solutions. Au même titre que Python d'ailleur. Tous les projets Open-Source sont potentiellement jurdiquement attaquables.
Avec le binding Python il est possible de créer facilement une appli Gnome donc l'argument de la simplicité ne tient pas une atto-seconde.
J'ai l'impression que tu n'as jamais codé en Python et en Mono. "oué y'a un binding GTK donc c'est pareil". Ce n'est pas que la présence d'un binding GTK qui en fait une plateforme "simple". Mono offre des services avancés d'intégration avec des libs existantes écritent en langage natif qui facilite grandement l'écriture de nouveaux bindings. C'est pas pour rien que .NET a un gros succès sous Windows par rapport à Java : l'intégration dans l'environement natif et avec l'existant est bien plus facile à mettre en oeuvre.
[^] # Re: Le passage Mono dans le document
Posté par lezardbreton . Évalué à 2.
Strigi : http://www.vandenoever.info/software/strigi/
http://strigi.sourceforge.net/index.php/Main_Page
Je l'ai testé, ça marche très bien (pas de bugs apparents), l'interface est sûrement à retravailler, et la taille de l'index est important. Utilisation du CPU<1%, consommation mémoire <10Mo (impressionnant, je n'ai rien senti).
Par contre, je n'en ai toujours pas l'utilisation
Kio-lucene : http://kioclucene.objectis.net/ , pas testé mais j'en ai entendu du bien.
[^] # Re: Le passage Mono dans le document
Posté par Juke (site web personnel) . Évalué à 2.
http://freedesktop.org/wiki/Software_2fTracker
[^] # Re: Le passage Mono dans le document
Posté par Jean-Philippe (site web personnel) . Évalué à 3.
J'ai pas vraiment d'info sur tracker mais il semble être très performant (et codé en C en passant)
[^] # Re: Le passage Mono dans le document
Posté par Ontologia (site web personnel) . Évalué à 2.
TImaniac, c'est pas la première fois que je te surprend à dire une connerie, et en proférant souvent moi aussi, je décèle chez toi une certaine incompréhension sur la compilation et sa théorie.
Il y a machine virtuelle et machine virtuelle. Dans le cas qui nous préoccupe ici, Java et Mono, il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
Voir pout Java : http://java.sun.com/docs/books/vmspec/html/Overview.doc.html
Donc, même si le pseudo compilateur java produit un pseudo assembleur, il faut le traduire cet assembleur, surtout qu'il est d'assez haut niveau. Ca prend du temps, tout ça
Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.
Alors certes, dans une machine virtuelle, tu peux gagner du temps en faisant des tables de hashage sur des appels de fonctions très utilisées, tu peux réutiliser du code déjà "compilé". Mais toute la phase de compilation à la volée du pseudo-code (code objet) est à faire. Le compilateur est en quelques sorte dans ton programme, d'autant plus lourd que la machine virtuelle est haut niveau. La Java Virtual Machine, est assez haut niveau j'en veux pour preuve l'exemple
void createBuffer() {
int buffer[];
int bufsz = 100;
int value = 12;
buffer = new int[bufsz];
buffer[10] = value;
value = buffer[11];
}
might be compiled to
Method void createBuffer()
0
bipush 100
// Push bufsz
2
istore_2
// Store bufsz in local 2
3
bipush 12
// Push value
5
istore_3
// Store value in local 3
6
iload_2
// Push bufsz...
7
newarray int
// ...and create new array of int
9
astore_1
// Store new array in buffer
10
aload_1
// Push buffer
11
bipush 10
// Push constant 10
13
iload_3
// Push value
14
iastore
// Store value at buffer[10]
15
aload_1
// Push buffer
16
bipush 11
// Push constant 11
18
iaload
// Push value at buffer[11]
19
istore_3
// ...and store it in value
20
return
trouvé ici http://java.sun.com/docs/books/vmspec/html/Compiling.doc.htm(...)
J'ose pas imaginer ça en asm x86, avec toute la gestion de la mémoire derrière... (et la super instruction "newarray int").
Conclusion, la bataille entre compilateur et machine virtuelle fait rage depuis 20 ans, voire plus, avec les mêmes arguments.
Je pense que le futur est à une synthèse entre les deux, ou plutôt à une intégration de concepts issu de l'interprétation dans la compilation : On peut imaginer un langage dans lequel on spécifie les intervales de définition les plus probables, où l'analse de flot détecterait des fonctions souvent rappelées et peu susceptibles de donner des résultats changeant en squeezant les appels et les remplaçant par des tables de hash. OU encore, mais ça me plait moins, d'entraîner le code sur des données et de recompiler sur des statistiques (Intel le fait).
Bref une belle thèse de doctorat (s'il y a des étudiants en Master 2 ou 1 prometeur dans la salle, contactez moi, je ferai passer) en perspective.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le passage Mono dans le document
Posté par TImaniac (site web personnel) . Évalué à 3.
Je persiste et je signe, la notion de machine virtuelle est une notion abstraite. Certes, avec certains environnement d'exécution, la dernière phase de compilation est effectuée "juste à temps", mais que ce soit pour Java ou à plus forte raison pour .NET, il est tout à fait possible de compiler dès le départ en natif, bref, au final ca prend pas plus de temps.
Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.
C'est pourquoi Mono implémente les spécifications d'une machine virtuelle qui a été conçue en vue de produire du code compilable à l'avance en code natif (que ce soit au dernier moment, 1h avant, ou 1 mois avant) Le résultat est identique : c'est de l'assembleur qui s'exécute, et il n'y a aucune phase de traduction/interprétation une fois la dernière phase de compilation effectuée.
il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
C'est rigolo de parler d'une "vraie" machine virtuelle... Une machine virtuelle est... virtuelle, elle n'existe pas. Une machine c'est quelque chose de physique. Le jour où t'auras une vraie machine qui existe pour .NET ou Java, ca sera un proc dédié pour exécuter les instructions du langage intermédiaire. Ce dont tu parles c'est l'environnement d'exécution et plus particulièrement de son compilateur JIT.
Pas la peine de réciter ton blabla théorique habituel, t'as beau affirmer des vérités générales, ca ne change strictement rien à ce que j'ai dis : le problème de la lourdeur vient des nombreux services offerts que n'offrent pas les langages "traditionnels" orientés machine physique sans limitations. C'est services ont un coup, c'est évident et n'importe quel bench peut le montrer, mais ils participent à la qualité du soft, tout est alors une question de juste équilibre.
Comme je l'ai déjà dis, même GCC propose une machine virtuelle, mais ne propose pas tous les services qu'offre Mono/Java, ce qui lui permet de produire du code machine plus rapide et plus optimisé.
Conclusion, la bataille entre compilateur et machine virtuelle fait rage depuis 20 ans, voire plus, avec les mêmes arguments.
Sauf que depuis 20 ans pleins de choses ont évoluées : les machines sont plus puissantes, offrant la possibilité de fournir des services supplémentaires à l'exécution sans vraiment pénaliser l'application qui s'exécute, les techniques de compilation JIT ont largement évoluées pour remplacer la traditionnelle phase d'interprétation du langage intermédiaire, qui elle était réellement lente, et surtout le plus important, les programmes ont changé de taille : on ne parle plus de quelques milliers de lignes mais plutôt de millions de lignes. Et là de nombreux programmeurs ont compris l'intérêt que pouvait apporter les environnements riches en services "ajoutés", ce qui leur permet globalement d'améliorer grandement la qualité de leur code, mais aussi de faciliter la programmation à plusieurs (composants, versionning, signature numérique, introspection et j'en passe).
Alors oué t'as raison, les pro langage natif "à l'ancienne" utilisent toujours les mêmes arguments, et pendant ce temps d'autres bossent, codent, et certains leurs offrent des outils/langages/bibliothèques/compilateurs qui leur rendent réellement services. Va coder une application d'entreprise devant facilement monter en charge en répartissant ses composants sur différentes machines dans un langage comme C/C++, bon courage.
PS : Je ne suis pas spécialement contre le code "superoptimisédelamortquitue" écrit en assembleur, ca a toujours son intérêt pour de nombeuses applications (couches bassent de l'OS, embarqué, etc.)
PS2 : tiens au fait, on attend toujours une release GPL de votre langage...
[^] # Re: Le passage Mono dans le document
Posté par Yusei (Mastodon) . Évalué à 1.
Tout le monde est d'accord pour dire qu'une machine virtuelle (MV) n'est pas une machine physique, mais il y a plusieurs manières de concrétiser les machines virtuelles. Le language C décrit une MV (une couche d'abstraction par rapport aux vraies machines), mais quand on compile un programme C vers du code natif, on obtient un programme pour une MV de niveau plus bas que quand on compile un programme en Java. Simplement pare qu'avec gcc la MV est une abstraction utilisée pendant la traduction, alors qu'avec java, la MV est une abstraction utilisée pendant l'exécution.
Tu fais la leçon en expliquant (tout à fait justement) que même GCC possède une machine virtuelle, mais tu oublies que même les machines physiques sont construites en couches logiques (électronique -> logique -> microinstructions -> système d'exploitation, quelque chose comme ça). À partir de quand est-ce qu'on a une machine réelle ? Est-ce qu'une machine avec un processeur x86 dédié qui ne fait qu'exécuter une JVM, c'est une machine (java) réelle ? Pourtant, vu de l'extérieur (vu de l'OS), impossible de faire la différence avec un processeur spécialisé qui comprend le bytecode java directement.
Au final, je n'ai pas l'impression que la distinction entre langage natif et langage à MV soit fixe, ou qu'on puisse en tirer quelque chose d'intéressant. Plus on a de couches à traverser, plus ça prendra de temps de les traverser, mais le nombre de couches à traverser dépend grandement du contexte (et de toutes façons, la traduction d'un langage à l'autre n'est pas nécessairement la partie la plus coûteuse en temps).
[^] # Re: Le passage Mono dans le document
Posté par Ontologia (site web personnel) . Évalué à 2.
Alors oué t'as raison, les pro langage natif "à l'ancienne" utilisent toujours les mêmes arguments, et pendant ce temps d'autres bossent, codent, et certains leurs offrent des outils/langages/bibliothèques/compilateurs qui leur rendent réellement services. Va coder une application d'entreprise devant facilement monter en charge en répartissant ses composants sur différentes machines dans un langage comme C/C++, bon courage.
Je suis d'accord que l'important est de disposer de langage évolué disposant donc de primitives tout aussi évolué.
Je suis le premier à militer" pour la montée en niveau des langages. J'ai même fait une publi là dessus.
Le fait que, ces services soient pour le moment offerts sur des machines virtuelles prouvent que compiler la même chose est trop compliqué, qu'on ne sait pas le faire, mais personne n'a prouvé que c'est impossible !
Je suis totalement d'accord avec toi dans le refus catégorique d'obliger le programmeur à l'ancienne pour utiliser un code compîlé, pour le plaisir d'avoir du code compilé. En terme de rationalité économique c'est effectivement stupide.
Quand je parlai de "vrai" machine virtuelle, je parle d'un programme exécutant un pseudo assembleur. Ca prend du temps de le compiler, même si c'est beaucoup plus rapide que de compiler du C++ ou du C.
En admettant que ce soit compilé intelligement, et souvent une bonne fois pour toute, une fois le code compilé, il n'est plus adaptable, spécialisable au contexte. On retombe toujours dans le même problème.
Ce que je veux simplement dire, c'est qu'il y a des recherches à faire là dedans pour essayer de synthétiser les avantages des deux, d'imaginer du code automodifiant, de l'analyse de chemin d'exécution, de contexte de données, toussa. On en parle.
nicO a pas mal d'idée sur le sujet, qu'il a posé ici (avec d'autres) :
http://wiki.loria.fr/wiki/Lisaac/Optimisation_en_taille
http://wiki.loria.fr/wiki/Lisaac/Optimisation_en_performance
http://wiki.loria.fr/wiki/Lisaac/WishList
http://wiki.loria.fr/wiki/Lisaac/Fonctionnalit%C3%A9_du_lang(...)
Les techniques d'analyse de flots le permettent. Comme je le disais c'est un beau sujet de thèse.
PS2 : J'ai déjà expliqué 5000 fois que je n'ai pas le pouvoir, et Benoit non plus quand à la libération du code source de Lisaac. Nous avons l'autorisation de libérer IsaacOS, ce que nous préparons dans les mois à venir (on travaille à faire une distrib pour développeur absolument impeccable, avec de la doc, des explications, le tout nouveau compilateur, etc...).
Mais pour Lisaac, nous n'avons pas le pouvoir de le libérer. J'aimairai beaucoup le voir en GPL crois moi.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le passage Mono dans le document
Posté par TImaniac (site web personnel) . Évalué à 2.
Je me tue à t'expliquer qu'une plateforme comme Mono tu produits un code compilé en natif et qui s'exécute comme tout autre exécutable générés par un compilateur traditionnel ! Donc oui c'est possible, mono le fait. GCJ aussi, .NET ngen aussi.
Si ces services sont associés à une machine virtuelle, c'est qu'il est impossible d'offrir les mêmes services associés au jeu d'instruction des machines physiques que nous connaissons, il est donc nécessaire d'introduire une couche d'abstraction purement virtuelle mais offrant un ensemble de services/instructions cohérent et intégré.
Quand je parlai de "vrai" machine virtuelle, je parle d'un programme exécutant un pseudo assembleur.
Si tu veux, et moi j'essai justement de t'expliquer qu'avec des environnement modernes comme Mono, ce n'est plus comme ca que ca marche :)
En admettant que ce soit compilé intelligement, et souvent une bonne fois pour toute, une fois le code compilé, il n'est plus adaptable, spécialisable au contexte. On retombe toujours dans le même problème.
Toutafé. Un programme compilé en code natif dès le départ (ala C) a ce problème. Mais c'est là que le fait de retarder la dernière étape de compilation au dernier moment (JIT) apporte une grande souplesse : on peut compiler à l'avance, mais aussi le faire "en live", la refaire si nécessaire, etc.
Ce que je veux simplement dire, c'est qu'il y a des recherches à faire là dedans pour essayer de synthétiser les avantages des deux, d'imaginer du code automodifiant, de l'analyse de chemin d'exécution, de contexte de données, toussa. On en parle.
Oué ca c'est cool, mais j'ai l'impression que tu n'as qu'un objectif : les performances. Ce après quoi court Lisaac (avec aussi bien sûr quelques paradigmes objets originaux et une meilleure abstraction), mais en laissant de côté tous les services qu'offrent les plateformes modernes de style .NET/Mono. Sans doute parcque ce n'est pas la même utilisation visée.
Ah oui, et puis bon, je sais pas si ca sert à grand chose de se "prendre" le choux pour obtenir des gains de performances générales sur l'ensemble d'un programme qui vont s'évaluer à quelques pourcent de temps d'exécution... A mon avis, à l'heure actuelle si tu veux améliorer les perfs va falloir "inventer" un langage où les concepts de parrallèlismes seront simples à appréhender et à utiliser. Je ne parle pas de la parrallèlisation automatique qui sera toujours limités, je parle d'offrir une sémantique élégante et intuitive au programmeur. Il y a de nombreux essais, mais je n'ai pas encore trouvé de langage vraiment convaincant...
PS2 : J'ai déjà expliqué 5000 fois que je n'ai pas le pouvoir,
C'était juste une question pour savoir où ca en était... Pour la libération de LisaacOS, franchement, perso je m'en tape royalement si les outils pour le compiler ne le sont pas...
[^] # Re: Le passage Mono dans le document
Posté par Yusei (Mastodon) . Évalué à 2.
Simplement produire du code natif, ce n'est pas difficile: au pire il suffit d'embarquer des bouts de l'interpréteur dans l'exécutable et pouf, tu as un programme natif. Ce qui est plus intéressant, c'est de savoir à quel point l'abstraction de la VM a été traduite et adaptée vers le niveau inférieur pendant l'opération.
Par exemple, si tu prends un langage comme Ruby qui te permet de rajouter des méthodes aux objets quand tu veux, ça complique beaucoup l'optimisation, parce que tu ne peux pas savoir quelles sont les méthodes d'un objet à l'avance. Tu n'auras aucun mal à produire un exécutable natif si ça t'amuse, mais tu ne gagneras pas automatiquement en efficacité, si pour conserver cette fonctionnalité tu as été obligé de n'inliner aucun appel de méthode.
[^] # Re: Le passage Mono dans le document
Posté par TImaniac (site web personnel) . Évalué à 3.
Sur des plateformes comme Mono, la VM a été conçu pour autoriser cette compilation, tout le code intermédiaire est donc traduisible avant exécution. l'environnement d'exécution n'est alors là plus qu'un framework sous forme de bibliothèque. Le code intermédiaire reste présent pour autoriser l'introspection, mais ce n'est plus vraiment du code exécutable, plutôt un ensemble de méta-données manipulables.
Par exemple, si tu prends un langage comme Ruby qui te permet de rajouter des méthodes aux objets quand tu veux, ça complique beaucoup l'optimisation, parce que tu ne peux pas savoir quelles sont les méthodes d'un objet à l'avance.
Effectivement, ces langages n'ont pas été prévu pour être compilé, et ont un modèle de machine virtuelle qui se prête mal à la compilation post-exécution. D'ailleur Java a le même problème, pendant de nombreuses années les JVM ont continués à interpréter le bytecode (même si la compilation JIT était de plus en plus présente), seul GCJ a réussi récemment à se passer de toute phase d'interprétation autorisant la compilation en code natif. C'est un des intérêt de Mono/.NET de proposer ce support en standard. D'ailleur certains en on profité pour en déduire que la plateforme .NET n'était pas adapté aux langages dynamiques. Elle n'a effectivement pas été conçu dans ce sens, mais ca reste possible comme le montre IronPython par exemple. D'ailleur la prochaine CLR-2 vise à mieux intégrer ces langages dynamiques.
[^] # Re: Le passage Mono dans le document
Posté par benoar . Évalué à 2.
Pour ceux qui s'intéressent à l'aspect théorique de la construction de compilateurs à partir d'interpréteurs, voire ce lien qui parle d'évaluation partielle et surtout des différentes projections Futurama :
http://www.jadetower.org/muses/archives/000419.html
La notation utilisée est du genre Haskell, et ça fait se tordre l'esprit assez longtemps avant de capter quelque chose.
[^] # Re: Le passage Mono dans le document
Posté par Ontologia (site web personnel) . Évalué à 3.
Le source généré en C est en Cecill, afin qu'il soit librement distribuable sans problèmes.
Je sais bien que ce sera un frein aux désirs de contribuer, mais peut être que Lisaac sera devenu libre d'ici là (ie, qu'ils auront changé d'avis).
Mais je pense que l'intérêt pour un OS à l'archi radicalement nouvelle et qui plus est parfaitement fonctionnel, sera quand même assez fort.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le passage Mono dans le document
Posté par Jb Evain (site web personnel) . Évalué à 4.
Oui oui.
Non, il n'y a pas "machine virtuelle et machine virtuelle". Il y a le concept de machine virtuelle, point. Par contre on va parler d'environnement d'exécution virtuel. Le fameux VES de la CLI de .net. L'espèce d'assembleur ça s'appelle du code intermédiaire, et c'est un point commun à toutes les machines virtuelles. Dans la théorie qui t'es chère on attache à une machine virtuelle un langage, et on empile ces machines virtuelles. Pour Mono, le langage c'est donc du CIL.
Donc dans ce sens, le commentaire auquel tu réponds n'a pas tout à fait tord. En créant une représentation abstraite sous la forme d'un langage particulier (le fameux RTL) pour les machines basées sur des registres, gcc devient donc l'hôte d'une machine virtuelle.
C'est d'ailleurs ce qui permet de faire de la cross-compilation si je ne m'abuse.
Tout à fait. Ça prend du temps, ce que quelqu'un a appellé ici "le temps de chauffe".
Modulo les relocations, tout à fait. Mais c'est oublié tous les avantages que fournissent les environnements modernes.
Là on entre dans le moi je.
Concernant la synthèse issu de l'interprétation, je n'y crois pas. On n'interprète plus vraiment quoi que ce soit. Même la JVM qui pouvait balancer entre l'interprétation et la JIT compilation ne fait maintenant presque plus que de la compilation.
Cela dit, je pense qu'on tend vers quelque chose d'encore plus dynamique. Mais encore plus dynamique que ce qu'on a dans nos environnement d'exécution. Il y a des travaux sur les JITs pour pouvoir instrumenter le code assembleur émit pour pouvoir le regénérer en optimisant les portions les plus utilisées. Mais on va mettre ça dans les environnements d'exécution, et pas dans les langages. Sinon ça va devenir encore un langage que personne n'utilisera, un de plus.
Oh moi ces trucs là j'ai arrêté à cause de la théorie que tu nous tartines.
[^] # Re: Le passage Mono dans le document
Posté par golum . Évalué à 2.
Tu as raison et pendant qu'ils y sont pourquoi pas rajouter un interprète Perl ou Lisp. Y a vraiment que python qui mérite sa place en tant qu'interpèteur ultra-rapide dans une distrib ou un desktop.
D'ailleurs Ironpython qui tourne sur la CLR .NET de M$ explose le python C de notre cher Guido.
Comme quoi derrière les allergique à Java ou C# dégainent plus vite que leur ombre, quitte à réfléchir après.
Autant j'essaie de comprendre l'argument des langages compilés mais la c'est du nimportnawak.
Et pour les langages compilés, sachez que les VM modernes sont maintenant capable de faire de l'optim à a volée en se basant sur les statistiques à l'exécution. Chose impossible en natif. Donc les différences entre les 2 tendent à s'attenuer.
[^] # Re: Le passage Mono dans le document
Posté par fredix . Évalué à 2.
En même temps il y a de plus en plus de programmes en python/gtk et ce n'est pas prêt de s'arrêter ....
De plus si un dev préfère développer en Mono, c'est toujours mieux que pas de soft du tout ? A moins de croire que celui-ci aurait utilisé le C, ce qui est une illusion. Un développeur qui utilise Mono, Python ou Ruby a ses raisons propres qu'il faudrait respecter ...
Bref l'essentiel pour Linux est d'avoir des applications desktop.
[^] # Re: Le passage Mono dans le document
Posté par kraman . Évalué à 2.
qui a sorti un langage non interprete (que ce soit du script ou du bytecode) dans les, disons, 10 dernieres annees?
caml?
ouais, ca reste cantonne au monde universitaire et ca propose du bytecode.
La comme ca j'ai pas d'autres exemples qui me viennent en tete.
[^] # Re: Le passage Mono dans le document
Posté par fredix . Évalué à 1.
Mais bon rien empêche quelqu'un de coder une killerapp avec, histoire de montrer les capacités de ce langage.
[^] # Re: Le passage Mono dans le document
Posté par kraman . Évalué à 2.
Mais c'est effectivement connu pour ses features fonctionnel (j'ai code un compilo avec a la fac, c'est assez fabuleux de puissance et de concision. Par contre pour faire du code metier dans l'industrie ou de la gui, ca doit etre assez catastrophique.)
[^] # Re: Le passage Mono dans le document
Posté par benja . Évalué à 2.
http://nemerle.org/Main_Page :
[^] # Re: Le passage Mono dans le document
Posté par Sufflope (site web personnel) . Évalué à 2.
[^] # Re: Le passage Mono dans le document
Posté par 태 (site web personnel) . Évalué à 2.
caml a 20 ans
[^] # Re: Le passage Mono dans le document
Posté par kraman . Évalué à 2.
bon ben c'est encore pire : de tete, j'ai pas un seul exemple de langage purement natif qui soit sorti depuis C++ en 88.
[^] # Re: Le passage Mono dans le document
Posté par dinomasque . Évalué à 2.
A quand des VM dans les cartes graphiques pour exécuter des shaders portables ?
Oh la porte ! -> []
BeOS le faisait il y a 20 ans !
[^] # Re: Le passage Mono dans le document
Posté par Thana Raymond . Évalué à 2.
[^] # Re: Le passage Mono dans le document
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le passage Mono dans le document
Posté par Thana Raymond . Évalué à -1.
# Bindings
Posté par EmmanuelP . Évalué à 10.
- Java-gnome (Java)
- gtkmm (C++)
- pygtk (Python)
- gtk2-perl (Perl)
Maintenant il y a en plus gtk# (C#).
La belle affaire...
[^] # Re: Bindings
Posté par Thana Raymond . Évalué à 5.
# Beuurkkk
Posté par Christophe Merlet (site web personnel) . Évalué à 6.
Voilà qu'il vire l'applet pense-bête pour la remplacer par tomboy et sa dépendances à mono.
et en plus, imposer ces mastodonde au coeur du projet GNOME :((
Il y a des décisions qui mérite des coups de pieds au cul. Pendant que des devs s'escrime a optimiser les bibliothèques, a gagner quelques centaines de ko par ci par là, à améliorer les performances, faut toujours qu'il y en ai d'autres derrière pour rajouter un bloat gigantesque sous la forme d'une dépendances de plusieurs dizaines de Mo et 10 fois moins performants que ce qu'il remplace. juste pour être hipe et dans le buzz.
[^] # Re: Beuurkkk
Posté par sylware . Évalué à 5.
Le principe est simple: tu prends un composant logiciel qui marchent (sticky notes), tu le re-écrits en ajoutant 3 features à 2 balles mais avec le framework qui arrange tes affaires (tomboy)... et SURTOUT tu n'améliores pas la version qui existe en avançant des arguments coup de point, genre "je sais pas coder, alors j'utilise mono.net!". Résultat, tu fais dégager une appli qui marche et tu imposes ton framework... magie!
En plus, beaucoup occultent le côté promotion du logiciel libre dans les entreprises.
Dans une grosse entreprise, disons que tu veux "vendre" (et oui... il faut bouffer un jour) du desktop libre... bin avec mono dans gnome tu te retrouves sur le terrain technique où Crosoft est leader dans l'esprit des décideurs (.NET=Crosoft, JAVA=Sun)... résultat, tu donnes un paquet de billes pour te faire orbitaliser par les commerciaux de Crosoft... mais ça, j'ai l'impression que peu de gens comprennent.
Sérieux, si on doit choisir un framework, lourd, lent, inutilement complexe, c'est-à-dire du bloat, pour développer une application, pourquoi s'embêter avec ceux qui posent des pbs juridico-stratégico-commercio-andco? En plus ces derniers n'apportent rien de significatif par rapport à leur alter-ego à part ces derniers pbs et ils sont bien plus dans l'esprit d'une évolution et d'un développement "à la libre" (et oui, le libre ça n'est pas que des licences...).
Perso, tant que gnome est packagé de telle manière que je ne suis pas forcé d'installer mono (dans les distros les plus répandues), ça ne me gène pas que le Novell Blog System s'énerve tout seul dans son coin avec son morceau de desktop gnome officiel. J'utiliserai gedit ou le stick notes qui sera peut-être maintenus par d'autres.
[^] # Re: Beuurkkk
Posté par kraman . Évalué à 0.
ya pas de raison, une vm ca reste une vm et tout le monde utilise en gros les meme technos.
Donc si ca touche .net ca touche les autres aussi.
[^] # Re: Beuurkkk
Posté par Yusei (Mastodon) . Évalué à 2.
Dans le cas de Mono, ce qui fait peur à beaucoup de gens c'est que MS a breveté des morceaux de .NET, donc il y a des chances pour que ces brevets là s'appliquent aussi à Mono.
# Forte dépendance ou dépendance relative ?
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 4.
En effet, tant que le coeur du système reste en C/C++ et que le seul problème soit que les nouvelles killer-apps (genre beagle) utilisent Mono, il me semble que l'ampleur des dégats est toute relative. Cela signifie juste pour moi (qui ait une petite conf.) que j'installerai pas ces killer-apps. Si je suis pas seul, y'a des chances pour que des dev. se mettent à porter des (bouts de) killer-apps en C/C++ car ils les veulent sans Mono.
Par contre, si l'objectif c'est d'utiliser Mono comme langage de référence pour implémenter le coeur de Gnome (par exemple recoder nautilus en Mono), là c'est un peu plus génant.
[^] # Re: Forte dépendance ou dépendance relative ?
Posté par Thomas Maurin (site web personnel) . Évalué à 3.
Par contre en faisant entrer Mono par la petite porte, il y a des chances que certains essaient d'en profiter pour l'imposer comme pilier de Gnome 3.
# Il est temps de passer à e17
Posté par Frédéric-Emmanuel Picca . Évalué à 3.
[^] # Re: Il est temps de passer à e17
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Re: Il est temps de passer à e17
Posté par pasBill pasGates . Évalué à 5.
C'est pratique, au moins ca m'occupera pendant un petit moment.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.