Tient, je ne comprend pas le moinsage, j'avais essayé d'argumenter un minimum.
Je ne suis en rien contre la diversité (si peux etre, n'étant absolument pas creatif j'aimerais que tous le monde ai un site aussi moche que ce que je pourrais faire), cependant cette diversité devient nefaste à partir du moment ou elle nuit à l'accès à l'information.
Quand l'effet artistique constitue l'information, alors oui, lachez vous ! Mais quand l'information est constituée par le texte, les images/videos/sons, je trouve que l'interface devrait etre la plus simple possible.
Actuelement, la seule application que je ne trouve pas integrée ni utilisable facilement, c'est le navigateur web. Ce n'est pas homogene, c'est pas pratique, il y a toujours des sites differents. Si mon bureau a un theme lumineux, il y a des sites tout noirs. Si mon bureau a un theme noir, il y a des sites tout blancs qui me brulent les yeux. Et malheureusement je passe la moitié de ma journée à me balader sur internet. C'est aussi la seule application qui me force a utiliser une souris pour naviguer.
Donc autant je trouve interessant que l'on creuse des technologies marrantes et qui ont leur utilitées dans bien des cas. Mais j'aurais aimé qu'il y ai plus de boulot fait en direction de l'ergonomie de l'utilisation du web. Et je pense que cette ergonomie doit passer par un moyen simple de rendre la navigation uniforme. En rendant le html encore plus semantique qu'il n'est (avec des balises navigation, contenu, pied de page, ...) l'on pourrait faire des lecteurs plus integrés qui formatent le contenu en fonction des preferences utilisateurs (avec les couleurs qui me fatiguent le moins), avec une navigation qui correspond à ce que souhaite l'utilisateur, et ainsi de suite.
Le web actuellement me rappel un peu trop les applications spécifiques sous windows. Les apps pour scanner/graver/ecouter de la musque pour peu qu'elle viennent de differents constructeurs ne sont pas du tout homogenes, est-ce une bonne chose pour la diversité ?
Snif Snif, cela marche PAS du tout chez moi (genre super lent et pas ce qui est sensé s'afficher), c'est du webkit sur un athlon xp 1500+ (un peu vieux mais rien de dramatique).
Si autant je trouve ces technos techniquement superbes, ce qui me fait peur c'est que le web devienne de plus en plus dependant d'elles.
Le danger vient du fait que meme si il s'agit de format ouvert et documentés, ceux-ci sont tellement complexes que les chances d'etre suportés a 100% par plusieurs navigateurs sont proches de 0.
Et c'est là qu'il y a un soucis a mon avis. Le web devrait rester une chose tres simple (on nivelle par le bas), du contenu. Bref, du texte, des images, des videos, du son, et tout cela presenté de facon simple.
Je souffre tous les jours des sites qui demandent des fonctionalités trop complexes pour mon browser ou pire, trop complexes pour mon cpu. J'accepte de m'acheter un ordinateur plus récent si je veux faire tourner une application particuliere, mais dois-je vraiment changer d'ordinateur parce que le site de ma banque utilise une technologie tellement complexe (et pourtant libre) qu'elle ne peut pas m'afficher mes comptes en ligne ?
Je vais meme pousser le vice un peu plus loin. Toutes ces technologies d'animation (animation SVG), de style (css) et de 3D (webgl) font qu'aucun site ne se ressemble ni ne s'utilise d'une facon homogene. Chaqu'un des sites de mes onglets force mes yeux a une luminosité differente (couleurs), à un effort different (taille et forme de police), a une logique differente (position des menus, elements de la page, logique de navigation). Et je m'y pert, et pourtant je suis un geek de 23 ans, j'avoue que je ne sais pas comment font mes parents qui en ont 60 et qui n'ont jamais rien pigé à l'informatique pour s'en sortir sur internet, ils m'epatent !
Bref, ce sont des techno super interessantes (oui, oui, moi aussi je m'amuse avec), mais par pitier, laisser les là où elles sont necessaires et utiles.
Un logiciel de presentation animé avec des transitions ? C'est beau, j'avoue. La prouesse technologique est interessante, j'avoue, mais l'interet ? Que cela apporte-il par rapport a une presentation avec 5 slides clairs ?
Sinon, cela n'enleve en rien le fait que je trouve l'outil très sympa et que je m'en servirais sans doute pour frimer 5 minutes devant mes collegues ;)
La news a été écrite AVANT la sortie de blender 2.5 alpha 0, mais temps de modération oblige, cela arrive après.
Sinon, pour 2.5 ou 2.5 alpha 0, le nom correct est bien 2.5 alpha 0, mais en pratique la 2.5 n'existera pas. C'est 2.5 alpha, beta puis 2.6.
En clair, c'est bien la serie 2.5 (ou 2.50, c'est la même chose), mais du fait de la recriture complete, il a été décider de la nommer alpha 0 pour decourager l'utilisation en environnement de production.
Si l'on doit récuperer 50 elements sur une page, imaginons le scénario :
# envoi de la requete de la page, tout a fait normal, avec une unique entete en plus :
GET /mapage HTTP/1.0
Speedy-Accept: Version; multiples_get, push, truc;
Le serveur repond :
200 OK
Speedy-Accept: multiples_get
// ici il envoie le contenu de la page /mapage et reste en attente
Ici, le client sait maintenant qu'il peut faire ses multiples requetes, toujours sur la meme connexion, entre temps il a chargé mapage et sait donc quelles ressources suplementaires il doit traiter.
On a donc une requete http classique pour la premiere page (dont le contenu de retour peut etre compressé), mais ensuite, en reutiliant la meme socket, on fait une operation pour recuperer les ressources necessaires)
Donc la requete de la page initiale est au meme prix qu'avant, mais les requetes suivantes (les images/styles/videos/...) de la page sont bien moins lourdes, puisque elles se font en une unique requete sur le meme canal.
Et comme cela, on peut dès demain avoir du speedy sur nos machines. C'est rétro compatible, mais si le serveur gere et le browser gere, on y gagne.
HTTP reste un protocole texte sur une socket qui reçois des entêtes (une requêtes) et répond avec des entêtes + un corps.
On peut mettre ce que l'on veut dans les entêtes non ? Exemple dernièrement de la nouvelle entête pour permettre au xmlhttprequest d'aller taper à la porte d'un serveur distant.
Ne serait-il pas possible de faire évoluer HTTP en ajoutant de nouvelles entêtes qui seraient simplement ignorées par les serveurs ne gérant pas ? C'est bien ce qui se passe pour le Content-Machin: gzip non ?
Si le client n'accepte pas speedy, il n'envoie pas la première entête. Si le serveur n'accepte pas speedy, il ne renvoie pas la réponse speedy puisqu'il ignore tout bêtement l'entente envoyée. On ne casse pas la compatibilité avec http, on peut avoir une transition en douceur et cela peut permettre :
1) entêtes réduites à partir de la deuxième requête (la première devant être compatible http standard)
2) plusieurs get dans la même requête à partir de la deuxième requête (ce qui consomme ce n'est pas la première requête, c'est les 400 autres pour l'xmlhttprequest ou les dizaines d'images
3) compression des entêtes à partir de la deuxième requête.
Ensuite, c'est quoi qui pose problème actuellement pour le push. Si on ouvre la socket et qu'elle reste ouverte, pourquoi le serveur ne peut pas envoyer de son plein gré des données ?
Si le problème c'est de demander au serveur d'ouvrir lui même la connexion, comme ces choses là vont passer les NAT et comment ces choses là vont s'assurer que l'ordinateur qui répond derrière est toujours le bon ?
Je n'ai sûrement rien compris au protocole, mais là comme cela je ne vois pas l'intérêt de casser le web (ou de créer un web 2.0 ;) pour ces points particuliers qui, j'ai l'impression, peuvent être règles avec http.
Quand je lis en général quand le dd meurt, le pc n'est pas loin d'être obsolète par chez moi je me demande ce que tu vas faire de ton ancienne config qui pourrait certainement intéresser un LUG, une école ou un utilisateur de linuxfr. Je m'explique, je suis particulièrement peu chanceux, mais je pète un disque dur par an en moyenne repartie sur 3 ordinateurs (desktop du travail, desktop de la maison et laptop du travail). Donc j'en déduis que ta dernière config doit avoir au pire 3 ans ;)
Bon, je ne dis rien et je retourne jouer a liquidwar sur mon athlon XP 1600+.
C'est un exemple simple, mais il est possible de spécifier des alignements, des structs et pleins de choses joyeuses.
Le binding python opengl a été intégralement réalisé avec cela. Par contre il est vrai que tout est au runtime et non pas lors de la "compilation", d'où des perfs pas forcement géniales.
Le pire dans ce débat c'est qu'il y a des gens avec des vrais arguments (enfin). Merci beaucoup.
Au final je comprend les 3/4 de tes arguments et je ne peux rien y dire, c'est plus un débat typage statique/dynamique et la il est clair que c'est affaire de préferences personelles. Je n'aime pas cela (le typage statique), mais je comprend tout à fait les arguments en sa faveur.
Au final, je ferais peut etre du c# le jour ou le typage statique me convaicra ;)
Simple question, pour les PInvoke, j'ai l'impression que c'est juste la capacité de charger une librairie dynamique à la volée et d'appeler les fonctions qui se trouvent dedans. Si c'est cela, c'est tout à fait faisable en python via la lib ctypes. Si ce n'est pas le cas et que j'ai mal compris, merci de m'eclairé un peu plus ;)
```Je veux un langage relativement performant parcque mon application fait un minimum de traitement : C# est plus rapide que Python.```
Je serais presque d'accord avec cela. Tres souvent j'aimerais un peu plus de vitesse en python, et puis finalement je me rend compte qu'une utilisation plus inteligente de ma librairie (scipy par example), un petit bout de cython (qui n'est autre que du code python statiquement typé), ou un chargement rapide d'un bout de C avec ctypes et tout est reglé. Le plus crade c'est ctypes, et j'avoue que c'est une solution peu elegante. Mais cython cela revient exactement à ecrire du code python statiquement typé, et c'est rapide, tout en restant du python.
Pour la documentation complète, Ok. Je n'ai jamais eu de problème avec la doc python et j'ai toujours galeré dans la doc microsoft pour trouver ce dont j'avais besoin, mais c'est surement subjectif.
Pour la pérenité et la standardisation, rien à dire, cet argument est tres recevable (mais par contre il ne s'applique qu'à .net et pas à mono, et rien ne garantie que cela durera)
Pour le langage sur. Si tu veux du typage statique, fait du cython et le probleme est "presque reglé". D'experience personel (et encore ici, c'est subjectif), je ne pense pas que le passage de l'etape de "compilation/check des types" soit une securité. Un code qui n'a pas un minimum de couverture (et je ne parle meme pas de tests unitaire) ne peut pas fonctioner correctement.
Pour LINQ, c'est encore subjectif, mais en pratique c'est quelque chose qui se reecrit en python pur en peu de temps grace au generateurs et autres. Cela fournit les memes fonctionalitées sans complexifier le langage. C'est subjectif, mais je n'aime pas les langages avec une syntaxe complexe et plein de mot-clés.
Pour les methodes d'extension, je trouve le concept genial, mais j'aime pas, ce n'est pas explicite et c'est trop magique (par contre c'est faisable en ruby, en python et certainement dans d'autres langage. J'avoue, pour python on ne peut pas le faire avec les types de bases)
Et pour les Pinvoke que l'on site deux lignes plus bas, cela existe aussi en python et certainement dans pleins d'autres langages. Mais j'avoue, cela ne fait pas partie de la syntaxe du langage, mais d'une librairie.
Merci pour tes arguments, maintenant je vois ce qui peut plaire.
L'insistance sur le moi était une "figure de style" pour insister sur le fait que j'aimerais (moi) etre convaincu.
Pour la perte de temps, j'avoue que si ils aiment ca, je n'ai rien à dire (sauf peut etre si il s'agit de non assistance a personne en danger, mais je m'egare ;) On va en revenir à ce que disait stallman, concretement je n'ai rien contre Mono et contre les gens qui font du Mono, je voudrais juste qu'il reste dans leur coin. Actuellement je ne vois pas l'interet de cet environnement pour Gnome et pour le libre et je trouve qu'il est dommage de "perdre du temps" à coder des applications en Mono alors qu'elles existaient deja avant dans d'autres technologie et ne demandaient qu'a etre ameliorer. Je trouve qu'il est dommage de disperser les efforts de la comunauté pour faire deux applications qui font la meme chose dans deux langage different. Apres il est vrai qu'en pratique, ces gens contribue au libre et que il ne le font pas sur le temps ou je les paye, donc je n'ai peu etre pas mon mot à dire, si ce n'est que je pense que c'est dommage.
Pour l'argument sur Java il s'agissait d'un example simple d'argument pour lancer la machine. Et finalement cela marche bien, CF le poste de TImaniac qui suis ou la reponse que vous me faites plus haut dans la discussion.
Enfin des arguments, et plutot interessants en plus ;)
1) oui, je suis parfaitement d'accord, j'aimerais bien voir ce que ce genre de concepts peut donner. Le probleme qui se pose ici c'est que (cf un de mes postes précedents), je doute de la capacité de ce genre d'outil à fonctionner correctement, implementation differente, fonctionnement different. De plus, chaque langage a ces specificités et j'ai vraiment du mal à imaginer une VM tellement generique qu'elle peut couvrir efficacement plusieurs langages (j'avoue que à ce niveau je n'y connais pas grand chose).
2) oui.
3) Personellement je ne trouve pas. Hormis le fait que Mono possede un IDE tres sympa, je trouve que python/Gnome est vraiment exceptionel. Mais bon, ici on est dans le subjectif ;)
Le but n'est pas de ne pas soutenir une technologie d'un vilain méchant qui n'aime pas le libre. Le but est de faire de la discrimination positive. Si une technologie libre venant du libre est au moins aussi bonne que Mono, il faut la privilegier. Quand tu as un choix à faire qui ne se fait pas sur des questions technique (puisque ici l'on parle bien de technique finalement, Mono peut il répondre a mon besoin de devellopeur mieux qu'une autre solution ?), et bien tu fais un choix suivant tes convictions. C'est la même chose dans la vie, quand tu as un choix à faire et que des arguments valables ne sont pas presents pour faire la difference, et bien tu choisis sur des arguments subjectifs. Et ce que j'attend depuis le debut de cette discussion c'est quelqu'un qui pourra me donner des arguments valables sur la superiorité de Mono vis à vis de certains de ces concurents. De ce que j'en vois, Mono est une technologie moins bonne que celle que j'utilise actuellement, donc j'ai toutes les raisons de penser que c'est une betise de gaspiller des ressources dessus. Montrez moi que j'ai tord.
Example d'argument dans un débat equivalent. Je n'aime pas Java, je trouve que c'est un langage moche avec une syntaxe proche de C# (;)) vraiment lourde et qu'il n'apporte rien pour mon plaisir ou ma productivité. Mais par contre il est vrai que Java est present sur tous les téléphones portables du marché, c'est un aventage certain pour deployer des applications mobiles. Donc Java possede un avantage vis à vis de ces concurents.
Depuis le debut de ce debat les gens qui sont en faveur de Mono n'ont aucun argument, si ce n'est dire "regardez, ils font du racisme contre microsoft, bouh, les vilains !". On se croirait en politique...
Et pour la question "Ça sert à quoi Mono ? On a déjà Python et QT.", je t'invites à repondre a une question un tout petit peut differentes. J'ai python, j'ai QT (ou gtk), pourquoi devrais-je utiliser Mono ? Cela m'apportera il quelque chose ? (tu notes la difference, ici je ne crache pas sur Mono, je demande juste les aventages que cela m'apporterais).
Parce que si techniquement cela n'apporte rien, mais pourquoi on s'embete et on perd du temps à develloper cela ? Et si cela apporte quelque chose, mais pourquoi personne n'est capable de dire ce que cela apporte de bien, techniquement ?
Je saurais dire pourquoi Perl sur le C, langage interprété, orienté script administration et traitement de chaîne. Je saurais dire pourquoi python, syntaxe plus explicite, se voulant plus clair, J'ai toujours considéré perl comme la boite à outil du programme d'admin vite fait bien fait qui répond au besoin du moment, mais je n'envisagerais jamais un gros développement en Perl, là où python fait plus propre (ici encore c'est une affaire subjective qui résulte de préférences personnelles). Je saurais aussi dire pourquoi je fais du C de temps en temps, principalement le contrôle que cela m'apporte sur mon code, les performances aussi, lorsque c'est vraiment nécessaire (ce qui arrive bien moins souvent que ce que la plupart des gens pensent)
Mais vraiment, qu'apporte Mono, c'est une vrai question ?
Personnellement, pour avoir fait du C# lors d'un projet il y a 3 ans, j'y ai vu un langage avec une syntaxe que je n'apprécie pas, plutôt complexe. Des fois la complexité apporte de la fonctionnalité, ici je n'ai vu aucune fonctionnalité dans le langage que je puisse qualifier de "killer feature" et qui justifie la complexité de la syntaxe.
Après, certaines personne défendent les performances de mono qui surpassent celle de python par exemple. C'est vrai. Je m'en cogne. Pourquoi ?
<attention>Dans la suite du texte, 99.9% représente une valeur fortement élevée et proche de 100%</attention>
Dans 99.9% des cas, les besoins en performances sont une vaste blague, F-spot a besoin de performance ? Banshee aussi ? Tomboy ? Presque tous le temps de calcul est passé dans GTK, gstreamer ou X. Ici le langage fait plutôt office de colle glu entre ces différents composants et la seule performance ayant de l'importance tient dans le temps de chargement de la VM. Ici 16ms pour python, 100ms pour le chargement d'une petite application GTK, qui va sûrement rester affichée plusieurs minutes. Mono démarre plus vite, franchement, c'est une bonne nouvelle, cela change quoi ?
Lorsque l'on a besoin de performance dans une application, soit toute l'application se doit d'être performante (et la on écrira le code en C car de toute manière Mono est trop lent), soit il s'agit (comme dans 99.9% des cas) d'un petit bout de l'application, qu'il est facile de réécrire en C pour que toute l'application en profite (pareil, si cette partie avait été écrite en Mono, il aurait fallu la réécrire)
Le pire c'est que bien souvent le problème de performance vient d'un algorithme mal pensé ou d'une mauvaise libraire, ou d'entrées sorties. Et cela, j'ai du mal à croire que Mono s'en sorte mieux sur les entrée sortie qu'un autre langage, puisque de la même manière, tous le temps est passé dans le même traitement au sein du kernel et du hardware.
Maintenant vient l'argument de la probabilité et de l'interoperabilité que Mono apporte avec les technologie .Net. Je n'y crois presque pas. A partir du moment ou il y a deux implementations différentes, la portabilité ne peut pas être aisée. Il y a qu'à voir Java sur téléphones portables, C sur les différents compilateurs ou aussi les différentes implementations de python (Cpython, Jpython, IronPython, Stackless, Pypy...). A mon sens Mono est un environnement de développement portable, mais il n'assure pas la portabilité des applis écrites pour .Net sur d'autres plates-formes. (c'est du vécu, application très simple écrite pour Mono qui m'a demandé des heures de boulot pour faire tourner dans Visual Studio)
Peut être que je me plante complètement, mais si c'est le cas, 1) dites le moi (en argumentant) et 2) donnez moi des avantages à utiliser Mono. Sérieusement, j'en veux !
On en revient donc à la question ultime, sachant le danger "potentiel" autour de Mono (existe il vraiment ?), sachant que le fait de pousser Mono pousse les technologies Microsoft (est ce que c'est grave ?) et sachant que Mono est techniquement (jusqu'à preuve du contraire) équivalent à d'autre technologies déjà existantes, quel est l'intérêt pour moi, développeur, d'utiliser Mono. Quel est l'intérêt pour moi, ingénieur, "chef de projet", de pousser mono dans mon équipe ? Quel est l'intérêt pour moi, de faire de la pub pour Mono au réunions ? Quel est l'intérêt pour moi, qui contribue au logiciel libre, à gnome, d'utiliser Mono. Et quel est l'intérêt pour le monde (et principalement celui du logiciel libre) ?
et elle reste d'actualité. En oubliant le coté marketing, le coté ".Net c'est cool sur un CV" et différents autre aspects subjectifs, pourquoi MONO pour une personne qui ne s'intéresse qu'au technique. Lorsque l'on a le choix et que l'on cherche la meilleur solution technique, en quoi mono est intéressant ?
J'aimerais juste un avis technique de "Mono fans" qui essayerait de me convertir, que vous apporte Mono (et son environnement) par rapport a d'autres solutions (je pense a python/GTK ou python/QT parce que c'est ce que je connais très bien, mais il existe pleins d'autres environnements libres, ayant une quantité impressionnante de bibliothèques, des langages avec pléthore de syntaxe plus ou moins sympathiques...
Bref, techniquement, qu'apporte Mono au libre (et c'est une vrai question !), pourquoi devrait-je contribuer à mono et pas a un autre projet ? Quel est l'intérêt de consacrer des ressources au développement de Mono qui jusqu'à présent n'a pas apporté grand chose de concret au libre et à gnome (encore une fois, cela est subjectif, mais hormis fspot, banshee, tomboy et gnome-do je serais incapable de citer une application écrite en mono, et pour la plupart j'ai vraiment l'impression qu'il s'est agit d'une perte de temps lorsque la contribution aurait pu aller sur un logiciel équivalent (rhythmbox, note applet, deskbar applet, eog).
Concrètement RMS ne dis pas qu'il est contre MONO, mais contre son utilisation pour des projets libre, du fait du danger de "disparition" de cette technologie si Microsoft met son grain de sable en plein milieu. Ce en quoi je pense que l'on ne peut qu'être d'accord, si le système est dangereux, faut-il prendre le risque d'utiliser le système ?
En clair, le jeu en vaut il la peine ?
Mono est pour beaucoup de développeurs Gnome une "grande bouffée d'air frais" car il permet de s'affranchir du développement Gtk+ en C qui, je crois que l'on est presque tous d'accord la dessus, est fort peu sympathique. Mais pourquoi Mono/C# et pas un autre langage ?
Je pense que GTK est en C pour des raisons d'interlope habilité. Le C est un langage simple, beaucoup plus simple que le C++, il est hautement portable et inter opérable (ce qui n'est pas le cas du C++, principalement du fait que chaque compilateur utilise une convention différente pour le "manglage" des symboles de fonctions). Mais derrière cela je pense que le but de GTK n'est pas d'être utilisé en C, mais grâce à un binding dont la réalisation est extrêmement simple du fait que GTK soit écrit en C tout en suivant un paradigme objet avancé.
Je pense donc qu'à l'heure actuelle, écrire une application en gtk+/C est une bêtise, pour le temps de développement que cela impose, pour la qualité de développement qui en ressort (le C restera toujours plus difficile à maintenir qu'un langage de plus haut niveau et possédera toujours des dangers tel que les buffers overflows et autres drôleries). Parlons de performances, le toolkit faisant déjà un travail dingue (la gestion de l'affichage de widget sur un écran est un travail extrêmement complexe). Bref, le fait d'appeler ces fonctions complexes dans un autre langage ajoute une surcharge de calcul tellement minime devant la complexité du traitement effectué dans le widget que toute optimisation à ce niveau relevé, de l'optimisation inutile et précoce.
Maintenant la grande question est donc, quel binding utiliser ? Il en existe dans tous les langages existants, en C++ pour ceux qui aiment, en python, en ruby, en haskell, en php, j'en oublie.
Tous ces langages sont matures et ont pour la plupart une implémentation libre ayant moins à craindre de la part de microsoft que mono. Ils possèdent tous de nombreuses librairies pouvant rivaliser avec le "framework" .Net. Ils possèdent tous des environnements de développement très compétitifs.
Ma question est donc simple, supposons qu'il y ai un danger à utiliser Mono (je ne m'avancerais pas la dessus, je pense qu'il y en a un, mais je ne tient pas à débattre de cela), cela en vaut il la peine ? Et même plus, en supposant qu'il n'y ai aucun danger, qu'apporte ce "nouveau langage" (mono est tout de même plutôt récent dans le paysage des langages disponibles) face à ces concurrents directs ?
Personnellement j'ai jeté un oeil attentif sur Mono/libG (gtk, gobject, ...) et après plusieurs années d'utilisation de python/libG, je ne vois vraiment pas ce que Mono peut m'apporter. A vous, développeur, décideur et utilisateur, que vous apporte-t-il ? Au lieu de prendre du temps à crée et améliorer Mono, le gain pour la communauté n'aurait il pas été plus important si cette énergie étaient aller en faveur d'autre technologie ?
Je me permet de continuer ici un débat qui a commencé sur le journal initial concernant la qualité du moteur de jeu et principalement de sa vitesse.
Il faut voir que la version 2.49 améliore grandement les choses. Ce n'est pas juste des optimisations locales, mais aussi beaucoup d'algorithmes "nouveaux" et d'options qui apportent réellement un plus en matière de vitesse (le 3x plus rapide sur YoFrankie n'est pas juste un chiffre en l'air).
Actuellement les performances du game engine sont tolérables pour le prototypage ou la réalisation de jeux déjà fort sympathiques.
Dernièrement, une entreprise de jeu vidéo a choisie le game engine de blender comme moteur pour la création et la commercialisation de leur jeu [1] et le travail qu'ils font en interne donne ses fruits puisque certaines optimisations ont fait leurs apparitions grâce (en partie) à eux [2] et son déjà disponibles dans 2.49.
Alors oui, le moteur de jeu n'est pas au niveau de beaucoup de moteurs proprio et de quelques moteurs libres, mais l'interface qu'il apporte ainsi que l'intégration avec Blender en font un outil vraiment compétitif dont l'évolution est à suivre, et qui promet de devenir vraiment intéressant dans les années à venir.
Parce qu'au moment de le poster il m'est arrivé plusieurs problemes :
1) c'est pleins de fautes d'orthographe, que je le veille ou non, elles ne veulent pas partir
2) L'interface de postage de depeche ma completement destabilisé
3) Blender 2.49 n'etait pas officiellement sortit.
Je vais essayer de préciser un peu ce que l'auteur dis, arrêtez moi des que je dis une bêtise. Mes excuses par avance pour l'orthographe...
Le gros problème des langages interprètes, tel que Python, réside dans la lecture du bytecode et l'affectation des instruction bytecode a une opération spécifique.
Pour comprendre, il faut revenir au base du fonctionnement d'un programme sur un CPU.
Un programme est une suite d'instructions, plus ou moins simples, que peut comprendre un être humain. Le programme est ensuite compilé en programme machine par un compilateur.
Un programme machine n'est qu'une suite d'instructions très simples que peut comprendre la machine. Ces instructions sont chargées en mémoire et le CPU les exécute de façon séquentielles.
Le chargement des instructions s'appelle le *fetch*. Le CPU conserve un pointeur qui lui indique la zone en mémoire qui contient l'instruction à effectuer. Cette instruction est donc chargée dans le CPU, puis vas ensuite être analysée pour savoir comment paramétrer le CPU pour effectuer le calcul. Cette opération s'appelle le *dispatch*. Ensuite le CPU effectue le calcul, et un nouveau cycle de fetch/dispatch peut commencer.
Il s'agit de quelques chose de TRÈS simple et qui est effectué par le matériel par des câblages spécifiquement dédiés à ce traitement. C'est donc TRÈS rapide.
Ce mode de fonctionnement pose toutefois un problème. Plus le langage initial (avant compilation) est complexe, plus le code à générer est complexe et plus le travail du compilateur est complexe, voir impossible (quoi que... ?). À cela s'ajoute le fait que tous CPU possède des jeux d'instructions différentes.
C'est pourquoi les langages interprétés, comme python, utilisent ce que l'on appelle une machine virtuelle.
Le code python est traduit en instructions pour cette machine virtuelle. Ces instructions sont de beaucoup plus haut niveau que celles que peut comprendre un CPU standard et chaque instruction est lié a un code plus complexe. Par example, la ou un CPU standard ne possède qu'une instruction simple ADD qui ajoute deux nombres, on peut imaginer une instruction de machine virtuelle qui s'appellerait FAIT_LE_CAFÉ associée à un morceaux de code bien plus complexe.
Deux problèmes se posent ici pour les performances :
1) ce morceaux de code plus complexe, si il s'agit d'une instruction simple de la machine virtuelle, n'est plus simple pour le CPU qui se trouve en dessous et donc nécessite plus de calcul. Au final ce n'est pas si grave, car cela fait plus de choses.
2) Le traitement de fetch/dispatch que doit faire la machine virtuelle pour charger les informations se fait de manière logicielle et est donc forcement beaucoup plus lent. Malheureusement ici cela pose problème car pour un traitement équivalent à ce qu'un CPU sait faire, le traitement se retrouve ENORMEMENT plus lent.
Maintenant que les fondations sont posées, quel est le but de se projet. La *boucle d'évaluation principale* citée dans cette dépêche n'est autre qu'un bout de code (C pour python) qui se contente de faire:
Cette boucle est lourde, impose des traitement complexes, impose des empilements de fonctions et des branchements qui sont difficilement optimisables, c'est donc une perte de temps impressionnante.
Sauf qu'en pratique, au moment de l'exécution du code python, le bytecode ne change plus. Il serait donc possible, à ce moment precit, de transformer la boucle principale en un morceaux de code machine spécifiquement prévu pour traiter ce morceaux de bytecode particulier. C'est le but de la "compilation Just In Time".
C'est une première étape pour l'optimisation JIT.
Une deuxième, qui avait déjà été réalisée avec Psyco concerne les optimisations à la volée en fonction du contexte.
Exemple pratique supposons une fonction python telle que celle-ci
def max(a,b):
'''
Retourne la plus grande valeur entre a et b, ou None si les deux sont egaux
''''
if a > b:
return a
else if a < b:
return b
else:
return None
Python ne forçant pas la déclaration de type, il n'y a aucun moyen de savoir à l'avance ce que sont a et b. Pour chaque test il faut donc aller vérifier que les objets a et b possèdent des méthodes de comparaison, si oui les appeler. Au sein de la méthode de comparaison, il faut regarder le type de a et b et si ce sont des entiers alors l'on peut appeler la méthode de comparaison native du CPU.
Cela nécessite plusieurs instructions de bytecode, plusieurs cycle fetch/dispatch, bref c'est lent, un peu moins si il existe un JIT sur fetch/dispatch, mais cela reste super lent.
Il reste possible de crée un JIT qui analyse le code lors de l'appel de la fonction et se rend compte qu'il peut le remplacer par des instructions native du CPU beaucoup plus simples (un CPU sait très bien faire une comparaison entre deux entiers)
[^] # Re: Belle reussite, du bon journal trolleur comme il faut!
Posté par Guillaum (site web personnel) . En réponse au journal Une liberté sur 360°. Évalué à 3.
[^] # Re: Marche pas...
Posté par Guillaum (site web personnel) . En réponse au journal Sozi : vers un système de présentation alternatif libre. Évalué à 2.
Je ne suis en rien contre la diversité (si peux etre, n'étant absolument pas creatif j'aimerais que tous le monde ai un site aussi moche que ce que je pourrais faire), cependant cette diversité devient nefaste à partir du moment ou elle nuit à l'accès à l'information.
Quand l'effet artistique constitue l'information, alors oui, lachez vous ! Mais quand l'information est constituée par le texte, les images/videos/sons, je trouve que l'interface devrait etre la plus simple possible.
Actuelement, la seule application que je ne trouve pas integrée ni utilisable facilement, c'est le navigateur web. Ce n'est pas homogene, c'est pas pratique, il y a toujours des sites differents. Si mon bureau a un theme lumineux, il y a des sites tout noirs. Si mon bureau a un theme noir, il y a des sites tout blancs qui me brulent les yeux. Et malheureusement je passe la moitié de ma journée à me balader sur internet. C'est aussi la seule application qui me force a utiliser une souris pour naviguer.
Donc autant je trouve interessant que l'on creuse des technologies marrantes et qui ont leur utilitées dans bien des cas. Mais j'aurais aimé qu'il y ai plus de boulot fait en direction de l'ergonomie de l'utilisation du web. Et je pense que cette ergonomie doit passer par un moyen simple de rendre la navigation uniforme. En rendant le html encore plus semantique qu'il n'est (avec des balises navigation, contenu, pied de page, ...) l'on pourrait faire des lecteurs plus integrés qui formatent le contenu en fonction des preferences utilisateurs (avec les couleurs qui me fatiguent le moins), avec une navigation qui correspond à ce que souhaite l'utilisateur, et ainsi de suite.
Le web actuellement me rappel un peu trop les applications spécifiques sous windows. Les apps pour scanner/graver/ecouter de la musque pour peu qu'elle viennent de differents constructeurs ne sont pas du tout homogenes, est-ce une bonne chose pour la diversité ?
# Marche pas...
Posté par Guillaum (site web personnel) . En réponse au journal Sozi : vers un système de présentation alternatif libre. Évalué à -2.
Si autant je trouve ces technos techniquement superbes, ce qui me fait peur c'est que le web devienne de plus en plus dependant d'elles.
Le danger vient du fait que meme si il s'agit de format ouvert et documentés, ceux-ci sont tellement complexes que les chances d'etre suportés a 100% par plusieurs navigateurs sont proches de 0.
Et c'est là qu'il y a un soucis a mon avis. Le web devrait rester une chose tres simple (on nivelle par le bas), du contenu. Bref, du texte, des images, des videos, du son, et tout cela presenté de facon simple.
Je souffre tous les jours des sites qui demandent des fonctionalités trop complexes pour mon browser ou pire, trop complexes pour mon cpu. J'accepte de m'acheter un ordinateur plus récent si je veux faire tourner une application particuliere, mais dois-je vraiment changer d'ordinateur parce que le site de ma banque utilise une technologie tellement complexe (et pourtant libre) qu'elle ne peut pas m'afficher mes comptes en ligne ?
Je vais meme pousser le vice un peu plus loin. Toutes ces technologies d'animation (animation SVG), de style (css) et de 3D (webgl) font qu'aucun site ne se ressemble ni ne s'utilise d'une facon homogene. Chaqu'un des sites de mes onglets force mes yeux a une luminosité differente (couleurs), à un effort different (taille et forme de police), a une logique differente (position des menus, elements de la page, logique de navigation). Et je m'y pert, et pourtant je suis un geek de 23 ans, j'avoue que je ne sais pas comment font mes parents qui en ont 60 et qui n'ont jamais rien pigé à l'informatique pour s'en sortir sur internet, ils m'epatent !
Bref, ce sont des techno super interessantes (oui, oui, moi aussi je m'amuse avec), mais par pitier, laisser les là où elles sont necessaires et utiles.
Un logiciel de presentation animé avec des transitions ? C'est beau, j'avoue. La prouesse technologique est interessante, j'avoue, mais l'interet ? Que cela apporte-il par rapport a une presentation avec 5 slides clairs ?
Sinon, cela n'enleve en rien le fait que je trouve l'outil très sympa et que je m'en servirais sans doute pour frimer 5 minutes devant mes collegues ;)
[^] # Re: Migration ?
Posté par Guillaum (site web personnel) . En réponse au journal jabber.org quitte le libre ?. Évalué à 1.
Personellement j'ai toujours mon compte apinc et j'utilise jabber.no pour mes passerelles (msn, aim, icq, yahoo)
Jabber c'est aussi la possibilité d'utiliser pleins de trucs funs ;)
[^] # Re: correction?
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de Blender 2.5 Alpha 0. Évalué à 2.
[^] # Re: correction?
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de Blender 2.5 Alpha 0. Évalué à 4.
La news a été écrite AVANT la sortie de blender 2.5 alpha 0, mais temps de modération oblige, cela arrive après.
Sinon, pour 2.5 ou 2.5 alpha 0, le nom correct est bien 2.5 alpha 0, mais en pratique la 2.5 n'existera pas. C'est 2.5 alpha, beta puis 2.6.
En clair, c'est bien la serie 2.5 (ou 2.50, c'est la même chose), mais du fait de la recriture complete, il a été décider de la nommer alpha 0 pour decourager l'utilisation en environnement de production.
[^] # Re: Pas possible de faire évoluer HTTP ?
Posté par Guillaum (site web personnel) . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 5.
# envoi de la requete de la page, tout a fait normal, avec une unique entete en plus :
GET /mapage HTTP/1.0
Speedy-Accept: Version; multiples_get, push, truc;
Le serveur repond :
200 OK
Speedy-Accept: multiples_get
// ici il envoie le contenu de la page /mapage et reste en attente
Ici, le client sait maintenant qu'il peut faire ses multiples requetes, toujours sur la meme connexion, entre temps il a chargé mapage et sait donc quelles ressources suplementaires il doit traiter.
Speedy-Mget /mapage, image1, image2, image3, image4
Speedy-Priority: by-size
Et la le serveur envoie TOUT, compressé à mort.
On a donc une requete http classique pour la premiere page (dont le contenu de retour peut etre compressé), mais ensuite, en reutiliant la meme socket, on fait une operation pour recuperer les ressources necessaires)
Donc la requete de la page initiale est au meme prix qu'avant, mais les requetes suivantes (les images/styles/videos/...) de la page sont bien moins lourdes, puisque elles se font en une unique requete sur le meme canal.
Et comme cela, on peut dès demain avoir du speedy sur nos machines. C'est rétro compatible, mais si le serveur gere et le browser gere, on y gagne.
# Pas possible de faire évoluer HTTP ?
Posté par Guillaum (site web personnel) . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.
On peut mettre ce que l'on veut dans les entêtes non ? Exemple dernièrement de la nouvelle entête pour permettre au xmlhttprequest d'aller taper à la porte d'un serveur distant.
Ne serait-il pas possible de faire évoluer HTTP en ajoutant de nouvelles entêtes qui seraient simplement ignorées par les serveurs ne gérant pas ? C'est bien ce qui se passe pour le Content-Machin: gzip non ?
Si le client n'accepte pas speedy, il n'envoie pas la première entête. Si le serveur n'accepte pas speedy, il ne renvoie pas la réponse speedy puisqu'il ignore tout bêtement l'entente envoyée. On ne casse pas la compatibilité avec http, on peut avoir une transition en douceur et cela peut permettre :
1) entêtes réduites à partir de la deuxième requête (la première devant être compatible http standard)
2) plusieurs get dans la même requête à partir de la deuxième requête (ce qui consomme ce n'est pas la première requête, c'est les 400 autres pour l'xmlhttprequest ou les dizaines d'images
3) compression des entêtes à partir de la deuxième requête.
Ensuite, c'est quoi qui pose problème actuellement pour le push. Si on ouvre la socket et qu'elle reste ouverte, pourquoi le serveur ne peut pas envoyer de son plein gré des données ?
Si le problème c'est de demander au serveur d'ouvrir lui même la connexion, comme ces choses là vont passer les NAT et comment ces choses là vont s'assurer que l'ordinateur qui répond derrière est toujours le bon ?
Je n'ai sûrement rien compris au protocole, mais là comme cela je ne vois pas l'intérêt de casser le web (ou de créer un web 2.0 ;) pour ces points particuliers qui, j'ai l'impression, peuvent être règles avec http.
[^] # Bon, on va moduler le message précédent
Posté par Guillaum (site web personnel) . En réponse au journal Spotify sans les pubs audio. Évalué à 1.
- U2, OK
- Muse, Ok
- Portishead, OK
Bon, ils ont les gros titres anglophones que j'apprecie, testons maintenant avec des choses française connues
- Brassens, OK !
- Ogres de barbak (rien)
et avec les trucs pas connus (mais un peu quand meme) :
- Oldelaf et monsieur D (et ben non...)
- Tit'Nassels (rien)
Bon, c'est globalement PAS trop mal, il n'y a plus qu'a attendre que la liste se remplisse progressivement.
# C'est presque parfait !
Posté par Guillaum (site web personnel) . En réponse au journal Spotify sans les pubs audio. Évalué à 1.
Ca va se finir en inscription premieum + gros hack pour faire une application native. Ca je pense que c'est legal ;)
# Et l'ancienne config ?
Posté par Guillaum (site web personnel) . En réponse au journal Nouveau pc et remise à niveau. Évalué à 5.
Bon, je ne dis rien et je retourne jouer a liquidwar sur mon athlon XP 1600+.
[^] # Re: Tu gardes ta box
Posté par Guillaum (site web personnel) . En réponse au message FAI, free ou autre ?. Évalué à 1.
[^] # Re: Drôle
Posté par Guillaum (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
>>> import ctypes
>>> lib = ctypes.CDLL('libm.so')
>>> lib.pow.restype = ctypes.c_double
>>> lib.pow.argtypes = [ctypes.c_double,ctypes.c_double]
>>> lib.pow(5.2,2)
27.040000000000003
C'est un exemple simple, mais il est possible de spécifier des alignements, des structs et pleins de choses joyeuses.
Le binding python opengl a été intégralement réalisé avec cela. Par contre il est vrai que tout est au runtime et non pas lors de la "compilation", d'où des perfs pas forcement géniales.
[^] # Re: Drôle
Posté par Guillaum (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Au final je comprend les 3/4 de tes arguments et je ne peux rien y dire, c'est plus un débat typage statique/dynamique et la il est clair que c'est affaire de préferences personelles. Je n'aime pas cela (le typage statique), mais je comprend tout à fait les arguments en sa faveur.
Au final, je ferais peut etre du c# le jour ou le typage statique me convaicra ;)
Simple question, pour les PInvoke, j'ai l'impression que c'est juste la capacité de charger une librairie dynamique à la volée et d'appeler les fonctions qui se trouvent dedans. Si c'est cela, c'est tout à fait faisable en python via la lib ctypes. Si ce n'est pas le cas et que j'ai mal compris, merci de m'eclairé un peu plus ;)
[^] # Re: Drôle
Posté par Guillaum (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Je serais presque d'accord avec cela. Tres souvent j'aimerais un peu plus de vitesse en python, et puis finalement je me rend compte qu'une utilisation plus inteligente de ma librairie (scipy par example), un petit bout de cython (qui n'est autre que du code python statiquement typé), ou un chargement rapide d'un bout de C avec ctypes et tout est reglé. Le plus crade c'est ctypes, et j'avoue que c'est une solution peu elegante. Mais cython cela revient exactement à ecrire du code python statiquement typé, et c'est rapide, tout en restant du python.
Pour la documentation complète, Ok. Je n'ai jamais eu de problème avec la doc python et j'ai toujours galeré dans la doc microsoft pour trouver ce dont j'avais besoin, mais c'est surement subjectif.
Pour la pérenité et la standardisation, rien à dire, cet argument est tres recevable (mais par contre il ne s'applique qu'à .net et pas à mono, et rien ne garantie que cela durera)
Pour le langage sur. Si tu veux du typage statique, fait du cython et le probleme est "presque reglé". D'experience personel (et encore ici, c'est subjectif), je ne pense pas que le passage de l'etape de "compilation/check des types" soit une securité. Un code qui n'a pas un minimum de couverture (et je ne parle meme pas de tests unitaire) ne peut pas fonctioner correctement.
Pour LINQ, c'est encore subjectif, mais en pratique c'est quelque chose qui se reecrit en python pur en peu de temps grace au generateurs et autres. Cela fournit les memes fonctionalitées sans complexifier le langage. C'est subjectif, mais je n'aime pas les langages avec une syntaxe complexe et plein de mot-clés.
Pour les methodes d'extension, je trouve le concept genial, mais j'aime pas, ce n'est pas explicite et c'est trop magique (par contre c'est faisable en ruby, en python et certainement dans d'autres langage. J'avoue, pour python on ne peut pas le faire avec les types de bases)
Et pour les Pinvoke que l'on site deux lignes plus bas, cela existe aussi en python et certainement dans pleins d'autres langages. Mais j'avoue, cela ne fait pas partie de la syntaxe du langage, mais d'une librairie.
Merci pour tes arguments, maintenant je vois ce qui peut plaire.
[^] # Re: Drôle
Posté par Guillaum (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 0.
Pour la perte de temps, j'avoue que si ils aiment ca, je n'ai rien à dire (sauf peut etre si il s'agit de non assistance a personne en danger, mais je m'egare ;) On va en revenir à ce que disait stallman, concretement je n'ai rien contre Mono et contre les gens qui font du Mono, je voudrais juste qu'il reste dans leur coin. Actuellement je ne vois pas l'interet de cet environnement pour Gnome et pour le libre et je trouve qu'il est dommage de "perdre du temps" à coder des applications en Mono alors qu'elles existaient deja avant dans d'autres technologie et ne demandaient qu'a etre ameliorer. Je trouve qu'il est dommage de disperser les efforts de la comunauté pour faire deux applications qui font la meme chose dans deux langage different. Apres il est vrai qu'en pratique, ces gens contribue au libre et que il ne le font pas sur le temps ou je les paye, donc je n'ai peu etre pas mon mot à dire, si ce n'est que je pense que c'est dommage.
Pour l'argument sur Java il s'agissait d'un example simple d'argument pour lancer la machine. Et finalement cela marche bien, CF le poste de TImaniac qui suis ou la reponse que vous me faites plus haut dans la discussion.
[^] # Re: Techniquement, pourquoi Mono
Posté par Guillaum (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
1) oui, je suis parfaitement d'accord, j'aimerais bien voir ce que ce genre de concepts peut donner. Le probleme qui se pose ici c'est que (cf un de mes postes précedents), je doute de la capacité de ce genre d'outil à fonctionner correctement, implementation differente, fonctionnement different. De plus, chaque langage a ces specificités et j'ai vraiment du mal à imaginer une VM tellement generique qu'elle peut couvrir efficacement plusieurs langages (j'avoue que à ce niveau je n'y connais pas grand chose).
2) oui.
3) Personellement je ne trouve pas. Hormis le fait que Mono possede un IDE tres sympa, je trouve que python/Gnome est vraiment exceptionel. Mais bon, ici on est dans le subjectif ;)
4) J'attends ces X ou Y.
[^] # Re: Drôle
Posté par Guillaum (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Example d'argument dans un débat equivalent. Je n'aime pas Java, je trouve que c'est un langage moche avec une syntaxe proche de C# (;)) vraiment lourde et qu'il n'apporte rien pour mon plaisir ou ma productivité. Mais par contre il est vrai que Java est present sur tous les téléphones portables du marché, c'est un aventage certain pour deployer des applications mobiles. Donc Java possede un avantage vis à vis de ces concurents.
Depuis le debut de ce debat les gens qui sont en faveur de Mono n'ont aucun argument, si ce n'est dire "regardez, ils font du racisme contre microsoft, bouh, les vilains !". On se croirait en politique...
Et pour la question "Ça sert à quoi Mono ? On a déjà Python et QT.", je t'invites à repondre a une question un tout petit peut differentes. J'ai python, j'ai QT (ou gtk), pourquoi devrais-je utiliser Mono ? Cela m'apportera il quelque chose ? (tu notes la difference, ici je ne crache pas sur Mono, je demande juste les aventages que cela m'apporterais).
Parce que si techniquement cela n'apporte rien, mais pourquoi on s'embete et on perd du temps à develloper cela ? Et si cela apporte quelque chose, mais pourquoi personne n'est capable de dire ce que cela apporte de bien, techniquement ?
[^] # Re: Techniquement, pourquoi Mono
Posté par Guillaum (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Mais vraiment, qu'apporte Mono, c'est une vrai question ?
Personnellement, pour avoir fait du C# lors d'un projet il y a 3 ans, j'y ai vu un langage avec une syntaxe que je n'apprécie pas, plutôt complexe. Des fois la complexité apporte de la fonctionnalité, ici je n'ai vu aucune fonctionnalité dans le langage que je puisse qualifier de "killer feature" et qui justifie la complexité de la syntaxe.
Après, certaines personne défendent les performances de mono qui surpassent celle de python par exemple. C'est vrai. Je m'en cogne. Pourquoi ?
<attention>Dans la suite du texte, 99.9% représente une valeur fortement élevée et proche de 100%</attention>
Dans 99.9% des cas, les besoins en performances sont une vaste blague, F-spot a besoin de performance ? Banshee aussi ? Tomboy ? Presque tous le temps de calcul est passé dans GTK, gstreamer ou X. Ici le langage fait plutôt office de colle glu entre ces différents composants et la seule performance ayant de l'importance tient dans le temps de chargement de la VM. Ici 16ms pour python, 100ms pour le chargement d'une petite application GTK, qui va sûrement rester affichée plusieurs minutes. Mono démarre plus vite, franchement, c'est une bonne nouvelle, cela change quoi ?
Lorsque l'on a besoin de performance dans une application, soit toute l'application se doit d'être performante (et la on écrira le code en C car de toute manière Mono est trop lent), soit il s'agit (comme dans 99.9% des cas) d'un petit bout de l'application, qu'il est facile de réécrire en C pour que toute l'application en profite (pareil, si cette partie avait été écrite en Mono, il aurait fallu la réécrire)
Le pire c'est que bien souvent le problème de performance vient d'un algorithme mal pensé ou d'une mauvaise libraire, ou d'entrées sorties. Et cela, j'ai du mal à croire que Mono s'en sorte mieux sur les entrée sortie qu'un autre langage, puisque de la même manière, tous le temps est passé dans le même traitement au sein du kernel et du hardware.
Maintenant vient l'argument de la probabilité et de l'interoperabilité que Mono apporte avec les technologie .Net. Je n'y crois presque pas. A partir du moment ou il y a deux implementations différentes, la portabilité ne peut pas être aisée. Il y a qu'à voir Java sur téléphones portables, C sur les différents compilateurs ou aussi les différentes implementations de python (Cpython, Jpython, IronPython, Stackless, Pypy...). A mon sens Mono est un environnement de développement portable, mais il n'assure pas la portabilité des applis écrites pour .Net sur d'autres plates-formes. (c'est du vécu, application très simple écrite pour Mono qui m'a demandé des heures de boulot pour faire tourner dans Visual Studio)
Peut être que je me plante complètement, mais si c'est le cas, 1) dites le moi (en argumentant) et 2) donnez moi des avantages à utiliser Mono. Sérieusement, j'en veux !
On en revient donc à la question ultime, sachant le danger "potentiel" autour de Mono (existe il vraiment ?), sachant que le fait de pousser Mono pousse les technologies Microsoft (est ce que c'est grave ?) et sachant que Mono est techniquement (jusqu'à preuve du contraire) équivalent à d'autre technologies déjà existantes, quel est l'intérêt pour moi, développeur, d'utiliser Mono. Quel est l'intérêt pour moi, ingénieur, "chef de projet", de pousser mono dans mon équipe ? Quel est l'intérêt pour moi, de faire de la pub pour Mono au réunions ? Quel est l'intérêt pour moi, qui contribue au logiciel libre, à gnome, d'utiliser Mono. Et quel est l'intérêt pour le monde (et principalement celui du logiciel libre) ?
# Techniquement, pourquoi Mono
Posté par Guillaum (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 5.
http://linuxfr.org/comments/1044941.html#1044941
et elle reste d'actualité. En oubliant le coté marketing, le coté ".Net c'est cool sur un CV" et différents autre aspects subjectifs, pourquoi MONO pour une personne qui ne s'intéresse qu'au technique. Lorsque l'on a le choix et que l'on cherche la meilleur solution technique, en quoi mono est intéressant ?
J'aimerais juste un avis technique de "Mono fans" qui essayerait de me convertir, que vous apporte Mono (et son environnement) par rapport a d'autres solutions (je pense a python/GTK ou python/QT parce que c'est ce que je connais très bien, mais il existe pleins d'autres environnements libres, ayant une quantité impressionnante de bibliothèques, des langages avec pléthore de syntaxe plus ou moins sympathiques...
Bref, techniquement, qu'apporte Mono au libre (et c'est une vrai question !), pourquoi devrait-je contribuer à mono et pas a un autre projet ? Quel est l'intérêt de consacrer des ressources au développement de Mono qui jusqu'à présent n'a pas apporté grand chose de concret au libre et à gnome (encore une fois, cela est subjectif, mais hormis fspot, banshee, tomboy et gnome-do je serais incapable de citer une application écrite en mono, et pour la plupart j'ai vraiment l'impression qu'il s'est agit d'une perte de temps lorsque la contribution aurait pu aller sur un logiciel équivalent (rhythmbox, note applet, deskbar applet, eog).
# Pourquoi pas mono ?
Posté par Guillaum (site web personnel) . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 10.
En clair, le jeu en vaut il la peine ?
Mono est pour beaucoup de développeurs Gnome une "grande bouffée d'air frais" car il permet de s'affranchir du développement Gtk+ en C qui, je crois que l'on est presque tous d'accord la dessus, est fort peu sympathique. Mais pourquoi Mono/C# et pas un autre langage ?
Je pense que GTK est en C pour des raisons d'interlope habilité. Le C est un langage simple, beaucoup plus simple que le C++, il est hautement portable et inter opérable (ce qui n'est pas le cas du C++, principalement du fait que chaque compilateur utilise une convention différente pour le "manglage" des symboles de fonctions). Mais derrière cela je pense que le but de GTK n'est pas d'être utilisé en C, mais grâce à un binding dont la réalisation est extrêmement simple du fait que GTK soit écrit en C tout en suivant un paradigme objet avancé.
Je pense donc qu'à l'heure actuelle, écrire une application en gtk+/C est une bêtise, pour le temps de développement que cela impose, pour la qualité de développement qui en ressort (le C restera toujours plus difficile à maintenir qu'un langage de plus haut niveau et possédera toujours des dangers tel que les buffers overflows et autres drôleries). Parlons de performances, le toolkit faisant déjà un travail dingue (la gestion de l'affichage de widget sur un écran est un travail extrêmement complexe). Bref, le fait d'appeler ces fonctions complexes dans un autre langage ajoute une surcharge de calcul tellement minime devant la complexité du traitement effectué dans le widget que toute optimisation à ce niveau relevé, de l'optimisation inutile et précoce.
Maintenant la grande question est donc, quel binding utiliser ? Il en existe dans tous les langages existants, en C++ pour ceux qui aiment, en python, en ruby, en haskell, en php, j'en oublie.
Tous ces langages sont matures et ont pour la plupart une implémentation libre ayant moins à craindre de la part de microsoft que mono. Ils possèdent tous de nombreuses librairies pouvant rivaliser avec le "framework" .Net. Ils possèdent tous des environnements de développement très compétitifs.
Ma question est donc simple, supposons qu'il y ai un danger à utiliser Mono (je ne m'avancerais pas la dessus, je pense qu'il y en a un, mais je ne tient pas à débattre de cela), cela en vaut il la peine ? Et même plus, en supposant qu'il n'y ai aucun danger, qu'apporte ce "nouveau langage" (mono est tout de même plutôt récent dans le paysage des langages disponibles) face à ces concurrents directs ?
Personnellement j'ai jeté un oeil attentif sur Mono/libG (gtk, gobject, ...) et après plusieurs années d'utilisation de python/libG, je ne vois vraiment pas ce que Mono peut m'apporter. A vous, développeur, décideur et utilisateur, que vous apporte-t-il ? Au lieu de prendre du temps à crée et améliorer Mono, le gain pour la communauté n'aurait il pas été plus important si cette énergie étaient aller en faveur d'autre technologie ?
# Moteur de jeu
Posté par Guillaum (site web personnel) . En réponse à la dépêche Blender, la suite tout en un de création multimédia en version 2.49. Évalué à 6.
Il faut voir que la version 2.49 améliore grandement les choses. Ce n'est pas juste des optimisations locales, mais aussi beaucoup d'algorithmes "nouveaux" et d'options qui apportent réellement un plus en matière de vitesse (le 3x plus rapide sur YoFrankie n'est pas juste un chiffre en l'air).
Actuellement les performances du game engine sont tolérables pour le prototypage ou la réalisation de jeux déjà fort sympathiques.
Dernièrement, une entreprise de jeu vidéo a choisie le game engine de blender comme moteur pour la création et la commercialisation de leur jeu [1] et le travail qu'ils font en interne donne ses fruits puisque certaines optimisations ont fait leurs apparitions grâce (en partie) à eux [2] et son déjà disponibles dans 2.49.
Alors oui, le moteur de jeu n'est pas au niveau de beaucoup de moteurs proprio et de quelques moteurs libres, mais l'interface qu'il apporte ainsi que l'intégration avec Blender en font un outil vraiment compétitif dont l'évolution est à suivre, et qui promet de devenir vraiment intéressant dans les années à venir.
[1] http://www.blendernation.com/2009/04/09/bge-taking-it-to-the(...)
[2] http://www.blendernation.com/2009/05/21/bge-updates-new-yofr(...)
[^] # Re: News
Posté par Guillaum (site web personnel) . En réponse au journal Sortie de Blender 2.49, et après ?. Évalué à 2.
[^] # Re: News
Posté par Guillaum (site web personnel) . En réponse au journal Sortie de Blender 2.49, et après ?. Évalué à 1.
1) c'est pleins de fautes d'orthographe, que je le veille ou non, elles ne veulent pas partir
2) L'interface de postage de depeche ma completement destabilisé
3) Blender 2.49 n'etait pas officiellement sortit.
Faut-t-il que je fasse rapidement une depeche ?
# Simples precisions
Posté par Guillaum (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 10.
Le gros problème des langages interprètes, tel que Python, réside dans la lecture du bytecode et l'affectation des instruction bytecode a une opération spécifique.
Pour comprendre, il faut revenir au base du fonctionnement d'un programme sur un CPU.
Un programme est une suite d'instructions, plus ou moins simples, que peut comprendre un être humain. Le programme est ensuite compilé en programme machine par un compilateur.
Un programme machine n'est qu'une suite d'instructions très simples que peut comprendre la machine. Ces instructions sont chargées en mémoire et le CPU les exécute de façon séquentielles.
Le chargement des instructions s'appelle le *fetch*. Le CPU conserve un pointeur qui lui indique la zone en mémoire qui contient l'instruction à effectuer. Cette instruction est donc chargée dans le CPU, puis vas ensuite être analysée pour savoir comment paramétrer le CPU pour effectuer le calcul. Cette opération s'appelle le *dispatch*. Ensuite le CPU effectue le calcul, et un nouveau cycle de fetch/dispatch peut commencer.
Il s'agit de quelques chose de TRÈS simple et qui est effectué par le matériel par des câblages spécifiquement dédiés à ce traitement. C'est donc TRÈS rapide.
Ce mode de fonctionnement pose toutefois un problème. Plus le langage initial (avant compilation) est complexe, plus le code à générer est complexe et plus le travail du compilateur est complexe, voir impossible (quoi que... ?). À cela s'ajoute le fait que tous CPU possède des jeux d'instructions différentes.
C'est pourquoi les langages interprétés, comme python, utilisent ce que l'on appelle une machine virtuelle.
Le code python est traduit en instructions pour cette machine virtuelle. Ces instructions sont de beaucoup plus haut niveau que celles que peut comprendre un CPU standard et chaque instruction est lié a un code plus complexe. Par example, la ou un CPU standard ne possède qu'une instruction simple ADD qui ajoute deux nombres, on peut imaginer une instruction de machine virtuelle qui s'appellerait FAIT_LE_CAFÉ associée à un morceaux de code bien plus complexe.
Deux problèmes se posent ici pour les performances :
1) ce morceaux de code plus complexe, si il s'agit d'une instruction simple de la machine virtuelle, n'est plus simple pour le CPU qui se trouve en dessous et donc nécessite plus de calcul. Au final ce n'est pas si grave, car cela fait plus de choses.
2) Le traitement de fetch/dispatch que doit faire la machine virtuelle pour charger les informations se fait de manière logicielle et est donc forcement beaucoup plus lent. Malheureusement ici cela pose problème car pour un traitement équivalent à ce qu'un CPU sait faire, le traitement se retrouve ENORMEMENT plus lent.
Maintenant que les fondations sont posées, quel est le but de se projet. La *boucle d'évaluation principale* citée dans cette dépêche n'est autre qu'un bout de code (C pour python) qui se contente de faire:
while(true)
{
instruction = fetch_instruction()
if(instruction == INSTRUCTION_AJOUT)
faire_instruction_ajout()
elseif(....)
faire_autre_instruction()
}
Cette boucle est lourde, impose des traitement complexes, impose des empilements de fonctions et des branchements qui sont difficilement optimisables, c'est donc une perte de temps impressionnante.
Sauf qu'en pratique, au moment de l'exécution du code python, le bytecode ne change plus. Il serait donc possible, à ce moment precit, de transformer la boucle principale en un morceaux de code machine spécifiquement prévu pour traiter ce morceaux de bytecode particulier. C'est le but de la "compilation Just In Time".
C'est une première étape pour l'optimisation JIT.
Une deuxième, qui avait déjà été réalisée avec Psyco concerne les optimisations à la volée en fonction du contexte.
Exemple pratique supposons une fonction python telle que celle-ci
def max(a,b):
'''
Retourne la plus grande valeur entre a et b, ou None si les deux sont egaux
''''
if a > b:
return a
else if a < b:
return b
else:
return None
Python ne forçant pas la déclaration de type, il n'y a aucun moyen de savoir à l'avance ce que sont a et b. Pour chaque test il faut donc aller vérifier que les objets a et b possèdent des méthodes de comparaison, si oui les appeler. Au sein de la méthode de comparaison, il faut regarder le type de a et b et si ce sont des entiers alors l'on peut appeler la méthode de comparaison native du CPU.
Cela nécessite plusieurs instructions de bytecode, plusieurs cycle fetch/dispatch, bref c'est lent, un peu moins si il existe un JIT sur fetch/dispatch, mais cela reste super lent.
Il reste possible de crée un JIT qui analyse le code lors de l'appel de la fonction et se rend compte qu'il peut le remplacer par des instructions native du CPU beaucoup plus simples (un CPU sait très bien faire une comparaison entre deux entiers)
Voila, j'espère que c'est plus clair.