Philippe F a écrit 2214 commentaires

On est vraiment dans des réflexions de comptoire (et encore, il y a quand même des plus intelligentes).

Si un créateur de jeu veut vivre de son art, ta proposition en gros, c'est qu'il a qu'à pas le faire. C'est sur que avec des propositions comme ça, la création de jeux libres ne peut que mieux se porter.

Ah c'est sûr qu'avec des produits comme ça t'es pas prêt de trouver un business model pour les jeux vidéos dans le libre

Au contraire c'est parce qu'ils font le choix du non libre qu'ils trouvent justement un business model. Tous les autres efforts de jeux video libres se sont misérablement planté. Il y a peut-être quelque chose à comprendre la-dedans qui t'a échappé.

J'ai pris un tableau d'entier pour simplifier mais il est évident que l'utilisation d'une boucle avec ce type de complexité en C++ ne se justifie que par exemple pour parcourir une structure custom (genre arbre) qui te retourne un itérateur, et qui contient aussi une structure custom.

Dans ce cas, la STL est bien adapté et la syntaxe est bien celle que je décris, en python comme en C++.

L'avantage des délimiteurs est justement de rendre le code lisible sans ambiguïtés quelque soit le style choisit par le programmeur.


Note que le seul cas où il y a ambiguïté visuelle en Python est le cas où d'une part, le programmeur a mélangé allègrement tabulation et espaces, et d'autre part, ton éditeur n'est pas configuré comme l'éditeur de l'auteur original (et encore, uniquement dans un mode défavorable; s'il a choisi 2 espaces pour une tabulation et que tu en utilises 8, le code sera encore lisible parfaitement). Si t'es sous vim, tu pourras rectifier la situation en 3 secondes et ça doit être possible sous d'autres éditeurs.

Note que la même situation peut se produire avec du C++. Le code sera tout aussi moche et plein d'ambiguïtés visuelles, mais tu pourras encore le compiler. Est-ce que c'est mieux ou moins bien ? je ne saurai dire...

D'ailleurs, ton affirmation que les délimiteurs rendent le code sans ambiguïté peut facilement être remise en question. Je te sors quelques classiques :


int * a, b, c, d; // oops, qui est un pointeur et qui ne l'est pas ? Ou est donc l'aide des délimiteurs ?

for( i=0, i < 10, i++) // ah ah, le délimiteur me fait-il sauter aux yeux cette erreur de syntaxe pourtant patente ?

for( i=0; i <37 && pasFini == true; i++ ) ; {
.... // fait des trucs mais il ne le fait qu'une fois au lieu de 37 fois. Merci aux délimiteurs.
}




Je ne suis pas non plus d'accord que les délimiteurs rendraient le code plus lisible. Après quelques années à faire du python et à me déshabituer de la syntaxe C/C++, un code chargé de symboles abscons comme ces deux derniers langages me semble beaucoup plus illisible que du code python qui me semble clair et surtout aéré.

Aller, un petit exemple à deux balles :

l = [1,2,3,4,5]
for i in l :
.... print i



int array[] = { 1, 2, 3, 4 ,5 };
std::vector l( array, array + sizeof( array ) / sizeof( int ) );
for( std::vector::iterator it = l.start(); it != l.end(); ++it ) {
.... printf( "%d\n", *it );
}


Merci à linuxfr qui ne permet pas de taper facilement du code !

En tout cas, les deux exemples font la même chose, je continue à trouver la version python plus lisible. Et je n'ai pas triché sur le C++, j'ai utilisé la méthode officielle d'itérer sur un tableau STL.

Donc pour en revenir à nos moutons, en ce qui me concerne, je me réjouis que les concepteurs d'un nouveau langage pensent aussi à sa lisibilité en utilisant une syntaxe légère. Les jeunes barbus sont choqués, les vieux barbus regardent ça avec une moue dédaigneuse et un vague sourire en coin (ah plan 9, ça, c'était quelque chose) et les jeunes boutonneux regardent soit avec un enthousiasme démesuré, soit avec des yeux de merlans frits.

Si tu juges un langage uniquement sur sa syntaxe, ben ... je sais pas trop quoi dire mais ça me parait tellement réducteur. Certes, la syntaxe n'est pas anodine et je peste sur la syntaxe old school de CMake par exemple, mais de là à refuser d'utiliser un outil parce que sa syntaxe est pourrie, ça me dépasse. Quid de la facilité d'utilisation en général, de la pertinence à résoudre simplement ou pas les problèmes qui se posent à toi, du jeu de bibliothèque, de l'expressivité du code, de la maintenabilité, de l'intérêt des nouveaux concepts, de la performance, de la portabilité ?


De la même manière que je ne fait pas de python à cause de cette indentation qu'il faut faire d'une manière bien particulière et que j'ai toujours vu poser plus de problèmes qu'elle n'en résout.


Une indentation bien particulière oui. Poser plus de problèmes qu'elle n'en résout, je suis pas d'accord. Le code est plus lisible, il y a moins de caractères à taper, et il est indenté de façon uniforme. Bon, de toute façon, j'ai jamais compris cet argument. C'est OK d'imposer un langage de programmation pour donner des ordres à un ordinateur, c'est ok d'utiliser une indentation cohérente pour faciliter la séparation sémantique des blocs mais c'est pas ok que cette séparation sémantique fasse partie du langage. C'est ok de forcer à utiliser un point-virgule à la fin de chaque ligne, c'est ok d'utiliser plein de caractères ésotériques pour la programmation ( &!<*{;]:?}[ ) mais c'est pas ok d'avoir moins de caractères pour programmer.


Un codeur qui ne connait rien à Go, lorsqu'il va voir du code avec des nom en majuscule et d'autre en minuscule, il va se dire que le programmeur est un branleur qui pourrait au moins faire un code homogène ; il se dira surement pas : à tiens, ça doit surement servir à dire au compilateur qu'elle sont les méthodes externes.


De même, un codeur (comme moi) qui lit du ruby dit : j'y comprends rien. Et il dit la même chose quand il lit du lua, du perl, du SmallTalk, du lissac, du Haskell et du LISP. Mais avant de dire que le langage est une grosse merde et le codeur un gros brlanleur, je me dis que peut-être je devrai me documenter un peu plus sur le langage.

Note qu'il existe aussi pleins d'erreurs qu'un compilateur de langage statique ne décelera jamais.

Tu as raison sur le fait que malgré tous les argument qu'on peut avancer, au final, la syntaxe de Python peut introduire des bugs qui peuvent générer une exception qui font planter l'application alors que certains de ces problèmes auraient été attrapés par des langages à vérification de typage statique type C++.

Et pourtant, mon expérience personnelle, qui semble partagée, est que mes programmes C++ ont bien plus de bugs que mes programmes Python.

On peut réfléchir à d'autres aspects. Par exemple, une étude d'IBM montrait que le nombre de bugs produit par un programmeur donné par nombre de lignes tapées est constant quel que soit le langage utilisé.

Certaines constructions en python peuvent faire en 3 lignes ce qui prend une dizaine voire une vingtaine de ligne en C++. Ceci expliquerait peut-être cela, tout n'est pas dans le typage, statique ou pas, mais plus dans l'esprit du langage.

Euh, je vois pas le rapport avec la choucroute ?

On parle d'un langage développé en Open Source, incidemment par des employés de google. On parle ensuite des limitations techniques de Python, notamment dans le cadre d'application qui doivent tenir une très forte montée en charge et tu ressors le vieux laïus du grand méchant google.

[mode offensif] Tu le sors à chaque fois qu'il y a qu'il y a marqué google dans un commentaire ?

Le tout est de faire les delete dès que possible, sans les accumuler pour les faire plus tard.

Ca, c'est assez naïf comme vision. Justement, dans un jeu video où il y a beaucoup de temps réel, reporter un delete a plus tard peut être très important. Et si les delete se produisent de façon automatique, cela peut créer de vrais problèmes puisqu'il ne devient plus possible de le reporter.

Il y a justement une discussion sur ce sujet (l'utilisation de Python par google) sur la liste de Unladen Swallow. La conclusion est simple et sans fioriture : google aime bien python mais il y a plein de tâches pour lequel il n'est pas du tout adapté.

Par un des auteurs de Unladen Swallow :


Well, simple common sense is going to limit Python's applicability when operating at Google's scale: it's not as fast as Java or C++, threading sucks, memory usage is higher, etc. One of the design constraints we face when designing any new system is, what happens when the load goes up by 10x or 100x? What happens if the whole planet thinks your new service is awesome? Any technology that makes satisfying that constraint harder -- and I think Python falls into this category -- *should* be discouraged if it doesn't have a very strong case made in its favor on other merits.

Moi j'aime bien l'idée d'avoir des interfaces à la duck-typing.

Le modèle de classe / méthode me fait penser à la simplicité de lua, ce qui permet de l'optimiser à donf sans passer par des tables de fonctions virtuelles.

Globalement, ça me plait.

D'après la FAQ, on peut facilement linker du Go avec du C . Pour ce qui est du C++, ils espèrent pouvoir faire ça en passant par une interface SWIG.

Donc plutôt bof a priori pour Qt, possiblement OK pour Gtk.

Disons que c'est assez subtil. KDE a fait monter la mayonnaise au maximum avec des nouvelles technologies comme Plasma, Phonon, Nepomuk, ...

Alors forcément, dès que les annonceurs ont eu une release à se mettre sous la dent, ils se sont jetés dessus. KDE a eu beau insister que c'était pas stable, ça n'a arrêté personne.

Il voulait surement dire "bonobo, DCOP, son successeur D-Bus ..."

Qui se souvient encore de bonobo aujourd'hui ? Alors que KDE a été honni pour avoir choisi DBUS plutôt que du bonobo-like ...

Est-il possible de completement "traduire" en assembleur "optimisé a donf" un programme python ?

Non, pas vraiment. Même avec Unladen Swallow, c'est uniquement la partie de Python qui analyse un opcode Python et décide quelle fonction en C de Python appeler qui est passée par LLVM.

Ca veut dire que si l'implémentation en Python d'une opération est lente, elle restera lente. Par contre son appel l'appel de cette fonction pourra être optimisé pour devenir plus rapide via LLVM qu'elle ne l'était en C via Python.

On peut forcer la compilation en LLVM de toutes les modules Python (et avoir une consommation mémoire en x10), mais je sais pas si on peut forcer l'utilisation du JIT. Je suis pas sur que ça aie un sens, puisque le JIT est efficace justement parce qu'il ne travaille que sur une petite partie du code et peut donc faire des optimisations non globales.

C'est un problème que j'ai régulièrement en Python, comment supprimer des éléments d'une liste sans passer par des indexes ?

Je préfèrerai stocker des références aux objets à supprimer. Mais il me semble que l'implémentation des listes en Python est basé sur un tableau, donc c'est pas possible.

En passant par un ensemble, je pourrais activer un algo en O(n), non ?

Ils se heurteront aussi à tous les moments où le programme passe par de la résolution de noms, inévitable si l'on veut conserver la souplesse qu'apporte ce mode de fonctionnement de Python.

Comme je l'explique plus haut, si j'ai bien compris ce qui se dit sur la mailing liste, ils font le postulat que les références des variables changent peu et mettent donc en cache la destination de la référence. J'imagine que pour les objets immutables, ils vont jusqu'à mettre la valeur en cache.

Donc ils court-circuitent autant que faire possible la résolution dynamique des objets, au prix d'un cache plus important. Mais dans la boucle chaude d'un programme, c'est pas là où tu t'amuses le plus à changer les types des objets, à résoudre dynamiquement les modules, etc. Au contraire, déjà en Python, il vaut mieux tout mettre en variable locale pour gagner en perf.

Mais, ils se heurteront au lock global et à sa prise/libération, s'ils réussissent à le contourner et que ça fonctionne encore bien, chapeau (et GVR sera sûrement très intéressé)

N'oublions pas que tout le monde travaille chez Google, donc ils peuvent discuter en direct. Pour citer un message de la mailing list :
FYI, at breakfast this morning, Guido seemed receptive to the idea of dropping the more exotic threading models and just keeping the pthreads and Windows support.


Prendre son petit-dej avec Guido, ça aide pour discuter du futur du langage.

Jython est à peu près aussi rapide que CPython, avec encore des gains potentiels. Cf http://wiki.python.org/jython/JythonFaq/GeneralInfo#Howfasti(...)

IronPython, l'implémentation de Python pour le CLR de .NET est en revanche significativement plus rapide que CPython :
http://ironpython.codeplex.com/wikipage?title=IP26RC1VsCPy26(...)


La preuve, si les gens en doutaient encore, qu'un compilateur à qui on passe les bonnes informations peut faire un travail d'optimisation plus poussé qu'un être humain.

En y reréfléchissant, j'ai dit une connerie. Unladen Swallow ne présente pas des variables Python en tant que constante à LLVM (ce serait quand même débile), il présente en revanche les variables Python comme pointant toujours vers la même référence.

On peut imaginer que dans la partie hot d'un programme, on s'amuse moins à changer le type des variables ou les faire référer vers d'autres objets.

Exemple qui marcherait dans Unladen Swallow :



def main_loop() :
....data_to_process[:] = fetch_data()
....while len(data_to_process):
........idx_to_remove = extract_some_data( data_to_process )
........for idx in idx_to_remove :
............del data_to_process[ idx ]




Dans cet exemple l'objet data_to_process varie mais pointe toujours vers la même liste. LLVM pourra donc optimiser l'indexation des objets dans la liste et l'accès à la longueur.

Alors, quelques explications sur le gain de consommation mémoire extraordinaire. Tout d'abord, notez que les auteurs soulignent que Unladen Swallow consomme encore beaucoup trop de mémoire par rapport à l'interpréteur de référence.

Normalement, l'interpréteur Python convertit un programme en bytecode python, conserve ce bytecode en mémoire et l'éxecute dans sa VM. La consommation de mémoire de Python correspond grosso-modo à la mémoire utilisée par la VM, plus tous les modules sous forme de bytecode.

Ce qui se passe avec la couche LLVM que Unladen Swallow a rajouté, c'est que certains morceaux de bytecode qui sont exécutés très souvent deviennent Hot et sont convertis en un autre bytecode, le bytecode de LLVM (qui s'appelle IR pour Intermediate Representation). Unladen Swallow conserve donc en mémoire le bytecode IR des modules optimisés. Ensuite, lorsque LLVM exécute le bytecode IR, il applique d'une part des optimisations, d'autre part il observe la fréquence d'utilisation des morceaux d'IR et peut décider si certains morceaux reviennent très souvent de balancer son compilateur JIT, qui lui va transformer l'IR en assembleur optimisé à donf.

On peut donc se retrouver facilement avec en mémoire pour chaque module le bytecode Python, le bytecode IR et l'assembleur. Ca va même plus loin puisque pour optimiser l'IR, les variables Python utilisées sont présentées comme constantes à la couche LLVM. Cela permet de faire un travail d'optimisation plus poussé, mais ça contraint à surveiller lesdites variables. Si certaines valeurs changent, l'IR n'est plus valide, il faut donc relancer une phase de compilation de l'IR et se débarasser de l'IR précédent, devenu obsolète. Et bien sur, faire cette surveillance sur les variables python implique de leur rajouter quelques champs afin de surveiller leur variation, donc augmenter la taille de certains objets Python. Il me semble qu'il y a aussi un cache au niveau de l'IR.

Pour la version Q2, l'objectif était de mettre en place toute cette infrastructure de compilation. C'est assez complexe comme vous pouvez le constater et la problématique de la mémoire a été laissé de côté pour cette phase. Il faut bien commencer par quelque part.

Au point que dans certaines versions de Unladen Swallow, l'IR obsolète n'était pas déchargé tout de suite de la mémoire.

Donc comme vous le voyez, c'est facile de consommer un max de mémoire avec cette architecture. Fondamentalement, Unladen Swallow consommera toujours plus de mémoire que le même code Python, ne serait-ce que par l'instrumentation du bytecode Python nécessaire pour déclencher correctement la partie LLVM.

Par contre, avec la release Q3, ils ont commencé à regarder d'un peu plus près les grosses sources de consommation, d'où ce gain phénoménal. Pas plus tard qu'avant hier, il y a eu des modifications pour faire encore des gains de consommation mémoire, donc on peut imaginer que la version Q4 rentrera dans le domaine du raisonnable.

« pas de dispersion de ressources aussi précieuses. »

Ha ha ha.

Il n'y a point de dispersion, à moins de menacer les développeurs khtml avec un fusil à pompe, ils ne travailleront jamais sur webkit.

D'un point de vue utilisateur, on peut le regretter, en tant que développeur, je les comprends tout à fait. Participer à un projet open source, c'est quand même pour le fun, et ca reste plus fun de travailler sur son propre projet, même à très faible audience, que de contribuer à un autre projet, surtout quand l'autre projet est un fork du votre.

Et au passage, note à l'auteur de la news, on dit KDE , pas Kde.

Il stocke toujours les mot de passe en clair dans un fichier de config ? Quid d'un petit fichier crypte en truecrypt pour memoriser les mots de passe ?

J'dis ca, j'l'utilise pas, mais quand même, si je dois l'utiliser un jour, je serai très réticent à cause de ça.

D'un autre côté, les performances qu'ils obtiennent reflètent ce qu'obtiendrait l'utilisateur mu (après lambda) qui compilerait lesdits logiciels avec un gcc livré de base sur son système d'exploitation.

C'est bizarre que ce soit basé sur de la reconnaissance à base de phonème, mes cours de reconnaissance de langue m'avaient expliqué que ça marchait très mal et qu'il fallait des diphones.

Toujours d'après ces même cours, un phonème change énormément suivant le phonème que le suit ou le précède. C'est pour ca qu'on fractionne en diphones. Par exemple, pour « bidon d'huile », on découperai en : __bi - idon - ondui - uile - eeu__

Déjà que le lapin coûte cher, en plus, il faut donner des sous à la boite qui le fabrique pour qu'elle survive ? C'est gentil mais pas pour moi.

Ces dernières années, KDE a reçu bien plus de bugs que les développeurs ne pouvaient en trier (pas corriger, trier juste pour dire c'est bien un bug ou c'en est pas un). Donc la base de bug a grossi, grossi, grossi....

Depuis un ou deux ans, il s'est mis en place un BugSquad ( http://techbase.kde.org/Contribute/Bugsquad ) dans KDE qui a entrepris l'immense tache de trier tous les bugs dans KDE. Ca veut dire vérifier si le bug s'applique à la dernière version, si le bug est encore présent, s'il est facilemtent reproductible, donner plus d'informations dans le cas de vrais bugs sur la façon de le reproduire, voire corriger des bugs pas trop compliqués.

Le résultat de tout ça, c'est que beaucoup de bugs ont pu être fermés. Il me semble avoir lu que le rapport vrai bug / bug reporté est de 1 sur 10. Dans 9 cas sur 10, le bug soit n'en est pas un, soit est déjà corrigé, soit est non reproductible, soit est lié à un autre composant qui est buggé, donc peut être fermé très rapidement.

Tu peux voir un morceau de l'activité de BugSquad ici : http://techbase.kde.org/Contribute/Bugsquad/BugDays

C'est comme ça qu'on arrive à des chiffres aussi énormes.

Il y a un eu blog récemment sur le BugSquad où l'un des gestionnaire se plaignait entre guillemets que beaucoup de BugSquader devenaient mainteneurs ou contributeurs et qu'il fallait donc recruter en permancence :-)