Antoine a écrit 5722 commentaires

Les objectifs de la version 1_0
http://www.parrot.org/news/vision-for-1_0

Ok, mais je posais la question des performances qu'on peut en espérer concrètement. Je n'ai rien trouvé, mis à part quelques lignes très vagues expliquant qu'une machine à registres peut être plus rapide qu'une machine à pile...

En plus, ça fait un paquet d'années que Parrot a été lancé (peut-être autant ou plus que PyPy, qui pourtant est autrement ambitieux), je pense que beaucoup de gens qui auraient pu être intéressés se sont lassés de suivre le projet.

Du coup, pour la performance, je suis allé voir le site du Computer Language Shootout, et ce n'est pas faramineux. Parrot est significativement plus rapide que Python, mais ceci en comparant des fonctions écrites directement dans l'assembleur Parrot à des fonctions écrites dans un langage haut niveau (Python) :
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)

Bref, les perspectives sont peu engageantes à l'heure actuelle.

On imagine tout a fait Canonical se mettre à dos toute la communauté.

La vacuité de cet argument me sidère. Pour reprendre l'analogie de ton pote du dessus, « on imagine tout à fait XFree86 se mettre à dos toute la communauté ». Ah, tiens, justement...

Encore une fois si ca avait été un pb penses tu réellement que la FSF l'aurait accepté en tant que projet GNU

Je ne savais pas que la FSF détenait le pouvoir absolu de dire le Vrai et le Faux. Merci pour cet argument d'autorité.

De plus cela ne peut pas changer la licence des versions jusqu'au jour du changement

??? Bien sûr que si, ça peut. Canonical peut packager des offres propriétaires autour d'anciennes versions de Bazaar si ça lui chante. Il a le droit d'apposer une nouvelle licence comme bon lui semble.

Il peut se passer un truc comme il s'est passé pour XFree86 et alors? Le projet a subit un fork et c'est le fork qui a gagné comme par hasard.

"Et alors ?" Et alors, il vaut mieux un projet où l'on n'a pas à forker pour avancer en bonne coopération. Les années perdues par XFree86 dans les bisbilles juridico-personnelles à la noix n'ont pas été très constructives, il me semble. Et je pense que peu de contributeurs se disent que ce n'était pas grave, qu'ils n'ont pas perdu leur temps et leur énergie dans ces idioties.

Maintenant, vu ton enthousiasme à troller comme un malade, je comprends que pour toi ce ne serait pas forcément du temps perdu...

Donc le coup du transfert de copyright c'est juste un prétexte point barre

N'importe quoi. Que Matt Mackall, qui a lancé Mercurial sous licence GPL, n'ait pas envie de céder son copyright à une boîte commerciale qui veut se réserver le droit de sortir des versions propriétaires de son code, je n'appelle pas ça un prétexte.

Ses allégations ne sont confirmées nulle part ailleurs sur le net

Elles ne sont pas infirmées non plus par qui que ce soit, bien que ce soit un post public par le fondateur du projet Mercurial, bref pas un troll de passage.

Soit dit en passant, on n'a pas besoin de la remarque de Matt Mackall pour avoir de sérieux doutes sur les « intentions de Canonical », la politique de Canonical suffit (Launchpad, marketing communautaire agressif, etc.).

La différence c'est que les concurrents ne peuvent pas le faire, ca me parait pas absurde.

Là ça tient du troll. Le problème c'est que les autres contributeurs non plus ne peuvent pas le faire. Bref, alors que tout contributeur devrait être sur un pied d'égalité juridiquement (c'est le principe fondamental de la GPL et du copyleft), Canonical détourne le principe à son profit et aux dépens de tous les autres auteurs.

Il est assez facile d'avoir des info sur Parrot

URLs bienvenues :-)

Ca pourrait s'appeler x86. Mais il me semble que l'intérêt d'avoir différents jeux d'instructions est que les langages ont chacun leurs propriétés particulières. Par exemple, je viens d'aller voir le site Web de Parrot, qui a des registres de type entier. Malheureusement, ces entiers sont de taille fixe (un mot machine) et ne gèrent probablement pas les dépassements, donc une implémentation de Python au-dessus de Parrot devrait refaire en Parrot ce qu'elle fait déjà en natif : à savoir gérer les dépassements à la main.

Cela veut dire que les licences GPL ne servent à rien et que en fait bazaar n'est pas libre?

Cela veut dire que la GPL s'applique à tout le monde sauf à Canonical, qui peut changer la licence du projet du jour au lendemain si ça lui chante, au grand dam des contributeurs.

Anyway, je suppose que tu le savais déjà et que tu ne fais que troller.

Ce qui doit tuer les perfs, c'est le fait de ne pas connaitre le type à la compile, tu es donc obliger de faire des vérifications et plusieurs chemins de calcul possible.

Oui, c'est une grosse partie du problème. Mais il y a plus simplement le fait que les types sont plus haut niveau. Par exemple, les entiers Python sont de taille variable, les listes vérifient que l'indice fourni est bien valable, etc.

Disons que si ça avait été du FUD il y aurait certainement eu quelqu'un pour répondre et le corriger...

Quand on va sur le site de Parrot il est difficile de connaître l'état d'avancement précis du projet et ses performances actuelles.

C'est curieux de vouloir comparer la vitesse de l'interpréteur Python avec qemu qui n'est pas loin de la vitesse de 100% sur x86.

Heu, c'est toi qui as commencé à parler de qemu, pas moi. Je disais au contraire que les instructions émulées n'ont rien à voir en terme de complexité.
Quant à n'être pas loin de 100% sur x86, n'est-ce pas simplement parce qu'il n'y a pas de traduction du tout et que le code userspace est exécuté nativement ?

Pour un seul bytecode, combien d'instruction à exécuter avec le dispatch ?

Je n'en sais rien, ça dépend du bytecode et aussi du compilateur qui a généré l'interpréteur :-)
Les instructions les plus simples (POP_TOP, DUP_TOP...) doivent se ramener à une vingtaine d'instructions assembleur je pense.
Les instructions les plus complexes peuvent être arbitrairement longues. Mais même un simple appel à l'opérateur + (BINARY_ADD) peut impliquer des choses pas triviales.

La liste unladen-swallow parle un peu de ce que tu proposes, il y a apparemment eu un projet sous le nom de "Python2C". Voici ce que dit un des intervenants à son sujet :

« FWIW, the anecdotal evidence I've seen pointed to a more modest speed
boost in the range of 15-30%, but I can also believe 2x in certain
workloads. »

http://groups.google.com/group/unladen-swallow/browse_thread(...)

tu gagnes tout le mécanisme de traduction.

Ce que tu appelles "traduction", c'est simplement le dispatch des bytecodes. C'est certes non négligeable, mais les bytecodes d'un langage comme Python sont plus haut niveau que les instructions d'un CPU émulé par qemu, donc le gain apporté par la suppression du dispatch est moins grand.

Par ailleurs, en raison de la complexité des bytecodes, se pose la question de l'empreinte mémoire et de l'efficacité du cache d'instructions du CPU si tu remplaces chaque bytecode (1 à 3 octets chacun) par plusieurs dizaines d'instructions en langage machine.

Je ne comprends toujours pas. Tu as dit :

Qemu définit chaque instruction comme une fonction. Celle-ci est copié dans un buffer et conservé (gestion d'un cache)

Si chaque instruction continue à être exécutée individuellement, on ne gagne rien.

Pourquoi ne pas faire la même chose avec du code de plus haut niveau ?

Quel intérêt par rapport au switch/case d'une boucle d'évaluation ?

C'est bien la fameuse Loulou K (de Poméranie) qui faisait tourner les têtes des assidus du forum Framasoft il y a quelques années ?

j'avais vu une presentation d'une innovation Orange, c'etait pour diffuser du parfum en fonction des images que vous regarder sur le web. C'etait juste avant la fin de la bulle internet de 2001

histoire d'etre dans le bain...

a l'epoque je me disais qu'il y avait un directeur, une equipe qui ont bossé la dessus payé des milliers d'euros (bon la c'est normal), a mon avis (de l'epoque) c'etait vraiment une belle daube payé trop chere.

J'ai bossé un peu chez FT R&D, ils ne font plus que très peu de R&D mais seulement des études marché autour de "nouveaux produits" complètement fumeux. Il y a aussi quelques poignées de zozos qui se branlent la nouille autour de concepts à la mode (Web 2.0, réseaux sociaux etc.) et vont serrer des louches à leurs semblables en faisant passer cela pour de la veille technologique (barcamps et autres foutaises du même acabit). Leur budget pourrait être 10x plus grand ou plus petit que le résultat final serait strictement le même.

Et à l'époque dont tu parles, il y avait effectivement pléthore de projets ridicules du même genre, des bidules domotiques "intelligents", des frigos reliés à Internet, des vélos d'appartement en peer-to-peer, etc.

C'est un système x86 complet pour ~80e et le Celeron 220 dessus sont des Conroe L (basés sur l'archi Core, la famille des Core 2 si j'ai bien compris).
Je ne sais pas ce que ça vaut en flottant, mais à mon avis c'est pas à dédaigner.

Si en virgule flottante c'est aussi impressionnant qu'en entier, ça vaut vraiment le coup.
J'ai un petit serveur basé là-dessus (un RPS de chez OVH, bon côté IO par contre c'est pourri, mais c'est dû à l'architecture choisie par OVH), et les performances en entier sont parfois aussi bonnes que sur un Athlon X2 3600+ cadencé 50% plus haut en fréquence.

Au niveau technocratique, il y a très peu de fonctionnaire européen comparé à la quantité de fonctionnaire qui sont dans les ministères parisiens.

Heu, c'est une boutade ?
Je veux bien croire qu'il y ait moins de fonctionnaires EU en nombre absolu que de fonctionnaires dans les ministères et collectivités français, mais rapporté aux champs d'intervention concrets et aux budgets gérés, il me semble que le rapport bascule totalement.

De plus, je ne vois pas ce que le nombre de fonctionnaires vient faire ici. Quand je parle du système technocratique européen, c'est bien pour désigner la matière de la légitimité dont il se pare (c'est-à-dire cette supposée compétence technique dans la gestion (ce qui est en soi une qualité anti-démocratique d'ailleurs), je dis bien « supposée » parce que quand on voit les (non-)réponses de Barroso, Trichet & co face à la crise, c'est plutôt pathétique...). Qu'il y ait dix ou mille fonctionnaires n'y change rien, les fonctionnaires ne sont que les outils d'un mode de direction politique.

Pour la constitution, le problème est encore de la responsabilité de notre président actuel.

???
Quand j'ai parlé du référendum sur la constitution, ce n'était pas pour dire que la constitution de 2005 était bien ou mal (ce débat n'a plus d'intérêt), c'était pour montrer un exemple récent où la souveraineté populaire a pu s'exprimer, et c'est au niveau de la nation (ce bidule archaïque etc.) que cette souveraineté s'est exprimée.

Cette impression de dictature vient justement de ce que les états ne veulent pas officialiser la fédération

Mais il n'y a pas de fédération... Il n'y a absolument rien à officialiser de ce côté-là.
Il n'y a pas de médias européens, pas de culture partagée quotidiennement, pas de langue commune, etc. Sur quelles bases veux-tu construire une fédération ? (à part sur un Etat central imposé autoritairement)

plutôt que de sous-traiter ça à une SSII, ils avaient demandé si parmi les utilisateurs (les gendarmes), certains étaient volontaires pour se former et s'y coller, et un petit groupe s'était mis en place. Ce petit groupe avait ensuite impliqué un groupe plus large d'utilisateurs pour s'assurer que tout correspondait au besoin général, tant qu'à faire...

Oui, c'est la base du logiciel libre : les utilisateurs forment des communautés d'entraide pour résoudre leurs besoins eux-mêmes. C'était déjà comme ça dans les années 50 (avant que le logiciel ne soit soumis au copyright / droit d'auteur), quand IBM a lancé le programme SHARE pour que les utilisateurs de ses machines puissent échanger leurs développements. (*)

Ça change du discours habituel sur l'industrie des services et l'open source !

(*) http://www.libroscope.org/Un-point-de-vue-subjectif-sur-l

Je te rapelle aussi que nous sommes dans l'UE et que les états existent encore parce que nos présidents ne veulent pas perdre leur poste

Heu....
Les Etats existent encore parce qu'il n'y a pas de culture ni de langue commune européenne, et qu'un Etat européen serait forcé d'être une dictature pour se maintenir (ce que la commission est déjà, d'ailleurs, nonobstant le vernis technocratique et gestionnaire).

Au niveau des nations actuelles, il est encore possible pour une véritable voix populaire de s'exprimer, même si c'est de moins en moins le cas (dernière occurrence flagrante : le référendum sur... la constitution européenne, justement).

Il a fort à parier que la vraie raison du choix de Ubuntu soit le coût.

Les licences Ubuntu sont moins chères que les licences Mandriva ? :)

Et voici le point de vue de Matt Mackall, développeur de Mercurial :

« fsync is a) immensely slow (can cause system-wide filesystem stalls for
many seconds) and b) doesn't guarantee file integrity on modern hardware
(many drives only guarantee that data has made it to their onboard
caches).

Because fsync has such a negative effect on average I/O bandwidth, it
can actually increase the odds of hardware corruption by widening the
corruption window. It's not at all clear that fsync is desirable. »

http://www.selenic.com/pipermail/mercurial/2009-March/024582(...)

Petite correction : le problème avec fsync dans Firefox 3.0 n'est pas originellement à cause de Firefox 3, mais à cause de sqlite.

Non non, c'est bien la faute de Firefox qui a décidé d'utiliser une base données transactionnelle ACID-compliant pour sauver des données parfaitement accessoires (historique de navigation). Sqlite, lui, fait le boulot pour lequel il a été conçu.

Ceci dit, si Firefox embarque son propre sqlite lié en static (c'est une hypothèse que je fais), ils auraient pu patcher le source pour enlever les fsync().

La plupart des mainteneurs ne travaillent pas chez Mandriva, elle n'a donc aucun pouvoir coercitif pour améliorer la qualité.

Pour la plupart des paquets, oui. Mais je pense que pour ssh, le mainteneur est un gars payé par l'entreprise (en tout cas j'espère, sinon il n'y a plus qu'à fuir en courant).

Par contre, il faut encore et toujours se faire entendre, en envoyant des courriels pour signaler ces gros problèmes de qualité.

Envoyer des courriels à qui ?

L'entreprise dont je suis actuellement le grand sachem informatique, plus de 30 sites, pas d'Oracle, pas de JEE. Même pas Active Directory :-)

Laisse-moi deviner : tout est en phpNuke ?