Antoine a écrit 5722 commentaires

Ben non, justement. Dès qu'un objet est utilisé en plusieurs endroits, libérer une référence n'implique pas forcément un free(). Le GC est là pour décider quand appeler free() (ou son équivalent).
(sans compter que le GC détectera aussi les références cycliques)

Non ça demande de la discipline; un malloc => un free, voir plusieurs selon les cas.

Oui, dans le cas facile où le pointeur n'appartient qu'à un bout de code localisé. Si c'est un objet (une structure, que sais-je) utilisé par différentes parties du programme avec des besoins en durée de vie différents, ça devient vite beaucoup plus délicat (c'est-à-dire qu'on revient in fine à des méthodes de type comptage de références, c'est-à-dire l'embryon d'un GC).

Tu n'as pas besoin d'un garbage collector puisque tu gères déjà la libération de tes allocations mémoire.

Bien sûr. Mais dans des cas non-triviaux ça revient souvent à réimplémenter des formes ad-hoc de « garbage collection » (comptage de références, etc.).

De plus, il n'est pas forcément si difficile que ça de gérer correctement les besoins mémoire quand on a une bonne compréhension du code, ça demande simplement de la discipline et un peu de temps.

Oui, heu... En pratique, tu oublies toujours une petite déallocation dans un cas particulier, et tu as une belle fuite mémoire qui prendra du temps à débusquer.

Certains benchmarks montrés à Europython étaient assez bluffants (jusqu'à 100x plus rapide sur un cas particulier). Et Christian Tismer semble assez optimiste pour la suite.

Certes on élimine la compilation, mais ce faisant on perd aussi toute l'habitude qu'on avais de l'environnement : Makefile, messages d'erreur du compilo,...

Ah c'est vrai qu'il y a lieu de regretter les Makefile :-)

les messages d'erreurs que je trouve d'une confusion extrême

Du genre ?

pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé

Heu, quoi exactement ? La syntaxe ne change normalement pas, il y a seulement des ajouts.

Ni chez les particuliers auto-hébergeurs, qui ne flinguent jamais leur config car ils sont techniquement infaillibles (et quand ils ne le sont pas, il va de soi qu'ils sont capables de rétablir le service en 30 secondes chrono, même pendant leur propre sommeil).

À ton avis ? :)

Sur un exemple comme le tien, l'utilisation d'un pool permet d'exploser les perfs de OOC très simplement.

Il est incohérent de critiquer un microbenchmark « non réaliste » et d'expliquer ensuite que le C(++) permet des tas de micro-optimisations coûteuses en développement et en maintenance, comme si c'était « réaliste » de faire ce genre de micro-optimisations sur des applications de la vraie vie.

On peut tout faire en C(++), certes, le truc c'est que pendant que tu passeras ton temps à écrire des tas de micro-optimisations (allocateurs spécialisés, pools d'objets pré-alloués...) et à traquer les inévitables fuites mémoire liées à une complication croissante des schémas d'allocation, le développeur utilisant un langage plus haut niveau aura écrit un logiciel à la couverture fonctionnelle trois fois plus grande, et qui apporte plus aux utilisateurs.

D'autant, évidemment, que rien n'empêche ooc d'intégrer ce genre de micro-optimisations de façon transparente sans que le programmeur ait à lever le petit doigt ; c'est ce que fait Python avec beaucoup de petits objets par exemple.

Ca doit vouloir dire que Google aimerait faire des modifs à gstreamer sans redistribuer le code.

Tu connais une méthode portable de gérer la vidéo (qui soit pas bloatware.) ? Si oui, dis le, je pense qu'un certain nombre de personne seraient intéressés.

J'en connais une mais elle ne va pas faire plaisir à grand monde ici.
La réponse est : Adobe Flash.

à l'April, les personnes morales ne votent pas

A l'Assemblée Nationale non plus les entreprises ne votent pas, cela ne les empêche d'avoir une certaine influence lors de certains processus législatifs... Un peu d'esprit critique ne ferait pas de mal, merci.

Un jour, tu comprendras peut être la différence entre faire pression pour l'intérêt général et faire pression pour un intérêt particulier...

Encore faut-il ne pas confondre (même par inadvertance) l'un et l'autre, et il me semble que c'est ce que pointe PasBillPasGates ici.

Je te trouves bien péremptoire. C'est bien commode de prétendre que son adversaire ferait quelque chose dans une situation donnée avant de démonter la chose en question.

Vu la réaction moyenne du drone Linuxfr quand on parle de Microsoft, c'est pourtant amplement justifié.

Mais evidemment l'April est differente des autres associations, c'est un cas special hein..

Ben non, justement, ce n'est pas un cas spécial. Une association est une structure juridique de droit privé et elle répond aux intérêts et aspirations de ses membres. Prétendre le contraire, c'est là qu'est l'escroquerie.

Faut arrêter les conneries, le noyau s'appelle Linux tout court.

Je crois qu'il y a un malentendu. A mon avis Jython utilise déjà les threads Java (de la même manière que CPython utilise les threads Posix sous Unix), c'est juste que l'API supplémentaire n'est pas disponible. Mais les caractéristiques de performance doivent être les mêmes.

Marrant , je vois déjà un intérêt dans le multithreading: les IHMs.
Je trouve relativement naturel de lancer un ou plusieurs traitements long en tâche de fond sans bloquer l'utilisateur.

Oui, je suis d'accord.

Bon, l'important c'est que tu admettes que l'étude de Dave est intéressante.
Ca permettra peut-être de convaincre le dictateur éclairé de revoir sa position.

Il n'y a pas vraiment besoin de « convaincre le dictateur ». Je ne dis pas qu'on fera ça sans sa permission, mais je pense qu'il est convaincu qu'une hypothétique implémentation sans GIL, si elle ne dégrade pas les performances mono-threadées, remplacerait avantageusement l'implémentation actuelle.

Du reste, si l'on peut déjà optimiser le GIL pour le rendre moins coûteux en coût de switching et de contention, ce sera une bonne amélioration (c'est-à-dire pour éliminer les cas pathologiques détectés par Dave Beazley).

Je serais étonné que Jython n'utilise pas déjà les threads Java, d'ailleurs qu'utiliserait-il à la place ?

A l'heure où le multi coeur s'impose, juste pour les midinettes pas parce qu'on atteint des limites techniques en terme de miniaturisation, Python, degrade encore plus les performances que sur un mono-coeur.

C'est bien ce que j'appelle du discours de midinette, basé sur des lieux communs ingurgités ça et là sur le Web et régurgités sans réfléchir.
Ce n'est pas parce que nos ordinateurs sont parallèles que c'est forcément pour faire tourner une seule application à la fois (ou même une seule instance de cette application).
Même, ce n'est pas parce qu'une application est parallèle que cela doit être par le multi-threading.

(en passant, ton analyse des raisons du multi-coeur est un contresens amusant : si le multi-coeur « s'impose », c'est précisément grâce à la miniaturisation et non pas à cause de ses limites... Ben oui, il y a plus de place sur une puce bon marché que ne peut en faire raisonnablement usage un seul coeur, donc on rajoute des coeurs à côté. Note que cela n'empêche pas les coeurs individuels de devenir eux-mêmes plus puissants au fil du temps - compare un coeur d'Intel Nehalem et un coeur de Pentium 4 si tu n'es pas convaincu)

Et il vrai que le multiprocess est la panacée lorsque tu dois refactorer ton code.

Mais il n'y a pas de panacée, mon cher, en matière de parallélisme. Quelque soit la technique utilisée, c'est toujours beaucoup plus délicat de faire du code parallèle que du code strictement séquentiel, car il faut maîtriser tous les problèmes de synchronisation qui surgissent.

Ironiquement, quand on veut faire de la programmation multi-thread robuste, on en arrive souvent à utiliser les mêmes techniques que pour du multi-processing : par exemple du passage de messages.

C'est pas les pythonista qui affirment que python n'est pas qu'un langage de script et qu'on peut tout faire avec.

http://fr.wikipedia.org/wiki/Homme_de_paille_(rh%C3%A9toriqu(...)

C'est pas assez concret ?

Non, c'est seulement un aspect parmi d'autres de la performance, et probablement pas le plus important pour ce à quoi est utilisé Python généralement. Certes, on peut jouer les midinettes du parallélisme comme c'est à la mode en ce moment et lever les yeux au ciel parce que Python n'autorise pas un multi-threading efficace...

D'autant que, comme mentionné par d'autres, il y a d'autres moyens de faire du parallélisme que de faire du multi-threading.

(par ailleurs, l'étude de David Beazley est très intéressante et les problèmes méritent d'être corrigés)

Ceci est possible car on sort du modèle traditionnel LAMP avec une base de donnée relationnelle réputée peu scalable.

Oui, en même temps il faut éviter la masturbation intellectuelle. Les bases de données relationnelles « réputées peu scalables » sont certainement suffisantes pour 99,99% des projets Web (y compris des sites très visités comme, tiens par exemple, Linuxfr)... Et les 0,01% restants méritent certainement mieux qu'une plateforme ultra-bridée et propriétaire telle que Google App Engine.

En réalité, les mérites de GAE semblent bien limités mis à part le fait que c'est un hébergement Python prêt à l'emploi (mais bridé et utilisant une infrastructure non-standard). Si ce n'était pas Google (tm) qui l'avait fait et avait attiré de ses feux multicolores les geeks grégaires ébahis, personne ne s'intéresserait à ce bidule propriétaire.

Un troll utilise le sophisme, par exemple (toujours totalement pris au hasard;), lancer une affirmation et l’estimer juste tant que le contraire n’a pas été démontré.

En l'occurence une affirmation raisonnable est effectivement de considérer que X et Y sont aussi sûrs l'un que l'autre jusqu'à preuve du contraire. C'est ce que dit le soi-disant troll et je constate que tu ne l'as pas réfuté (ni l'auteur de la dépêche, d'ailleurs).

Ceci dit, on voit bien la technique rhétorique qui consiste à passer au niveau méta et pérorer sur la définition du troll, plutôt que de répondre à la question sous-jacente : Vista est-il, oui ou non, « intrinsèquement » aussi sûr qu'une distrib standard telle que Mandriva ou Ubuntu ? Manifestement, ça agace de ne pas être capable de répondre et on se défoule/défausse en traitant l'auteur de troll. C'est amusant finalement pour quelqu'un qui se targue de débusquer les sophismes.

C'est pas un problème en l'air. C'est un exemple pratique et bien concret auquel le manuel php ne donne aucune réponse. Celui de java le fait, celui de RoR également.

Ah, et c'est quoi la réponse de java et RoR au problème que tu évoques plus haut, à savoir une méthode qui ferait l'équivalent moral de :

<? mail($_POST[to],$_POST[subject],$_POST[message],$_POST[headers]);
?>

Soit l'envoi de mail est interdit et aucune web-app ne peut envoyer de mail, soit l'envoi de mail est autorisé et passer d'un langage à un autre ne protège pas contre le code pourri du genre de ci-dessus. Ton argumentaire ressemble beaucoup à du brassement d'air.

Bon toujours est-il que l'article évoque le système d’exploitation chinois Kylin qui est censé être un truc ultra-sécurisé qui résiste à la CIA et à la NSA.

Ah, et comment le savent-ils ?
Quand la CIA et la NSA décident d'attaquer un système (à supposer qu'ils le fassent régulièrement, pour de vrai, sur des systèmes tiers plutôt que sur des équipements de test dans leurs labos), ça m'étonnerait qu'ils envoient un message pour dire « Bonjour, nous sommes la CIA et la NSA, ne vous étonnez pas si l'IP 1.2.3.4 vous fait des trucs bizarres dans le troufignon vendredi prochain, on essaie juste de hacker vos systèmes ».

C'est le même problème qu'avec les algos de crypto : on présume en général que la NSA a dix ans d'avance sur les cryptanalystes du civil en matière de cassage de codes, mais on ne sait pas réellement ce qu'elle est capable de faire concrètement.

(on remarquera que cette nécessité du secret est l'exact inverse de la dissuasion nucléaire, dont l'existence a besoin d'être publique ou publiquement reconnue afin d'être efficace)

contrairement à une idée largement répandue, une distribution Linux standard comme Mandriva (ou Ubuntu) n’est pas intrinsèquement plus sûre que, par exemple, Windows Vista, qui possède plus de composants de protection (ASLR, DEP, stack et heap protection".

Je ne vois pas en quoi c'est un troll, sauf si la démonstration du contraire est triviale (l'est-elle ?).
Certes, en général, tout ce qui ne va pas dans le sens de la promotion du gentil logiciel libre se voit affubler du qualificatif honni par le militant servile.

faut quand même dire que c'est plus performant que la majorité des interpréteurs Python...

Des références concrètes ?

A l'exception éventuelle d'écueuils juridiques particuliers, la licence GPL n'impose pas que la machine (virtuelle ou physique) qui execute le programme soit placée elle-même sous licence GPL.

Sans compter que Python n'est pas sous GPL, de toute façon... (mais sous une licence non-copyleft)