Philippe F a écrit 2204 commentaires

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 :-)

Ca ressemble un peu a topcoder aussi, sauf que le niveau des solutions de topcoder est autrement plus eleve que les solutions que j'ai pu voir jusqu'a present...

Moi je connais l'intérêt de coder en php. Ça permet de garantir ton boulot de webmestre à vie. Ou ça permet aux SSII qui repassent derrière de se faire un max de pognon. Ça permet aussi à tous les neuneux qui débarquent sur le marché du travail d'en trouver facilement et de créer plein de nouveaux emplois.

Vraiment en ces périodes de crises, PHP, c'est le langage qui va vous permettre de passer à côté de la charrette.

C'est un peu naïf comme vision. Je fais un logiciel libre et une foule de développeurs va se ruer dessus pour contribuer du code, des correctifs, le porter sur 23 plate-formes !

C'est pas du tout comme ça que ça se passe et on retrouve régulièrement des auteurs de logiciel libre très très déçu par le niveau de contribution extérieur.

Avec un résumé pareil, ça ne me donne pas envie de lire. J'espère que ce n'est pas une thèse bourrée de raccourcis à deux balles comme celui-là.

Donc, si on résume, Linux est sensé aller beaucoup plus vite avec toutes ces modifications !

Il accélère aussi l'internet ?

Genre porter du code écrit pour Windows 3.1 et Borland C++ vers Vista / Visual Studio la dernière version qui va bien ?

Gérer des incompatbilités de machines parce que le client fait toujours tourner Windows 95 (ou Linux 2.2.12) et que pas de bol, ta lib sur laquelle tout ton programme repose est super récente ?

Corriger les bugs dans une lib OpenSource que ton projet utlise, lib qui n'est plus maintenue depuis 5 ans ?

Faire une vrai programme ou tu jongles avec une 10aine de lib extérieures et ou il y a des conflits à la con, qui doit marcher dans une environnement hétérogène ?

Depuis quelques années, on voit décroitre peu à peu la popularité de Perl au profits d'autres langages, tels que Ruby et Python :

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.(...)
https://www.ohloh.net/languages/compare?commit=Update&l0(...)


Je suis curieux de savoir si cette constatation est vérifiée sur le terrain par les perleux. Est-ce que à des évènements comme les journées perl, il y a moins de monde qu'il y a 10 ans où est-ce que la population des perleux s'est stabilisée , voire augmente encore ?

Ce qu'on peut aussi interpréter comme un autre type de question : est-ce que les nouveaux pythoneux et rubyeux "volent" à la population des "perleux" ou est-ce que ces populations viennent d'une source différente ?

Un copain qui bosse dans les télécoms m'avait expliqué ça. En effet, Linux renégocie tout ce qu'il peut pour profiter de la liaison au maximum, tel que c'est proposé par le protocole TCP. Commes les autres OS ne le font pas, il se retrouvent vite de côté niveau débit.

Pour les avantages par rapport à Swing, je pense que tu as cité le principal : c'est beaucoup moins complexe.

Il y a besoin de beaucoup beaucoup moins de code pour faire la même chose. D'où gain de temps phénoménal en développement. Pas besoin d'une classe anonyme pour mettre en relation deux objets.

En ce qui me concerne, à chaque fois que je fais du java, c'est là que je souffre : c'est verbeux, verbeux, verbeux. Et que je te crée 10 classes pour faire un truc super simple.

Il me semble aussi que les interfaces Swing sont poussives (pour rester poli) alors que Qt est en général plutôt très réactif.

Après, si tu es super à l'aise dans Swing et que tu trouves que c'est extraordinaire, Qt ne te fera surement pas changer d'avis car c'est différent.

Pour les signature signal/slot vérifiés au runtime, c'est un compromis qui permet de garder pas mal de souplesse dans Qt. D'autres lib comme boost ont fait un compromis différent et connectent des signaux et des slots avec verif à la compilation, au prix de moins de flexbilité au runtime.

Je suis tout à fait d'accord sur le problème de fond, ça fait très peu crédible.

Il reste un gros travail de définition de suite de test pour valider l'interopérabilité des formats et leur utilisation correcte dans du code.

Pour participer à certains comités ISO ou à regarder d'autres efforts d'unification (xdg, browser et html, ...), la situation est pourtant assez courante et semble être un chemin naturel quoique désagréable de tout effort de coopération et de standardisation.

Ca commence toujours par merder avant de converger. C'est bien pour ça qu'on parle d'effort de standardisation parce que ce n'est pas du tout du tout naturel.

Cela dit, il semble que ODF aie suffisamment de monde derrière pour devenir un vrai standard, contrairement à OOXml qui n'a que Microsoft (ce que fait beaucoup de monde certe) et ne peut prétendre à ce type d'interopérabilité.

Il me semble qu'il y a quelques années, on percevait un essoufflement net dans le développement de gcc et on avait l'impression qu'il était plutôt à la ramasse sur pas mal de sujets (vitesse de compilation, temps d'exécution, ...).

Depuis le 4.0 et ces derniers temps en particuliers, le compilateur a repris du poil de la bête. En plus, ca le fait trop d'avoir une optimisation unique au monde à la pointe de la recherche, qui explose de 30% des benchmarks !

Longue vie à gcc alors. Et sinon, le code interne est toujours aussi atroce ? Des dires de ce qui avaient regardé, ca faisait plutôt peur.