neologix a écrit 346 commentaires

Cela leur permet de migrer progressivement de Python vers Go (et ils ne sont pas seuls).

La notion d'utilisateur système est purement administrative : du point de vue du kernel - qui gère les IPC - c'est purement un uid comme un autre (je sais qu'il y a une difference par example pour adduser, mais c'est orthogonal).
Alors prendre une decision de supprimer des IPCs - qui est potentiellement très dangereux - basée dessus n'a aucun sens.
Sans parler du risque intrinsèque de régression, qui est inacceptable.
Linus l'explique mieux que moi : https://lkml.org/lkml/2012/12/23/75

Sinon, je vois que ce journal a été tagué FUD/troll : c'est dommage, parce que je suis globalement satisfait de systemd, mais ce genre de bug - et le refus de le corriger - est implement inacceptable.

Je vais probablement m'attirer les foudres de certains, mais oui, la plupart de ceux ayant voté pour le Brexit n'ont "aucune jugeote" : je vis en Angleterre, dans une ville universitaire et avec une forte concentration de boîtes de R&D (Cambridge), et les gens sont atterrés…

Il suffit de voir la corrélation entre le vote Leave et le niveau d'éducation pour s'apercevoir que le camp du Leave a gagné en jouant sur la peur de l'immigration et la stupidité de provinciaux crédules (et des vieux qui ne sont plus tellement cortiqués et qui vivent dans une autre époque) [1], dans des provinces sinistrées, qui ont par exemple gobé les mensonges éhontés sur le montant de la contribution à l'UE (ne prenant pas en compte la contribution nette, par exemple avec la PAC) et promis leur redistribution à la NHS [2].

Je ne dis pas que tous les partisans du Leave sont stupides - loin de là - mais qu'il s'agit d'une flagrante démonstration des problèmes de la démocratie directe.

[1] http://www.bbc.co.uk/news/uk-politics-36616028
[2] http://www.huffingtonpost.co.uk/entry/nigel-farage-good-morning-britain-eu-referendum-brexit-350-nhs_uk_576d0aa3e4b08d2c5638fc17

Ben… il parcourt quand même le graphe d'objets pour détecter les cycles morts (la traversée du graphe se faisant via tp_traverse).

En effet, j'ai oublié le graphe "complet", merci de la précision.

Ceci dit, quand la génération la plus âgée est parcourue, ça peut prendre du temps.

Oui, dans mon souvenir le parcours n'est pas incrémental : il y a déjà eu des rapports de bugs concernant les pauses ?

Je ne vois pas trop ce que cet argument vient faire ici. Oui, la fragmentation de la mémoire est un problème, pour les GC comme pour la gestion de la mémoire manuelle.

Je n'ai jamais parle de fragmentation memoire - qui est d'ailleurs un avantage pour les GCs, qui sont de nos jours compactants - mais de pollution de caches processeurs par l'executiondu GC, qui va donc provoquer l'eviction de code/donnes qui sont actuellement utilisees pour toucher des objets inutilises un peu partout en memoire (qui est par ailleurs tres peu cache-friendly).

Mais je pense qu'il n'y a pas d'incompatibilité en général entre l'utilisation d'un Garbage Collector et l'embarqué.

Moi non plus, j'aime les GCs, je voulaisjuste souligner qu'il y a de bonnes raisons de s'en passer dans certains contextes.

Sauf que tous les workloads ne sont pas partitionables, que l'utilisation de fibres/goroutines/coroutines/user-space tasks/quel que soit le nom qu'on leur donne implique des echanges de messages et donc un cout en copie, synchronization et context switch (meme en user-space).
Il y a une raison pour laquelle des boites comme Azul existent…

Un autre argument contre les garbage collectors donne par Linus est la perte de localite de reference: lorsque le GC decide de faire une collection, tu te retrouves avec un cache pollue par les objets collectes.

Donc non, un heap par task ne resoud pas tous les problemes.

C'est un avis pour le moins surprenant. Le compteur de référence n'est qu'un élément. Python a bien des pauses pendant la libération des anciens objets qui ne sont plus utilisés. Peux-tu détailler pourquoi tu ne considères pas ça comme un Garbage Collector ?

Ce n'est pas un garbage collector genre mark/sweep ou compactant : il se contente de collecter les cycles, donc ce qui n'est pas libéré par le comptage de référence. Donc en gros il ne va pas faire d'analyse du graphe d'objets et des piles, contrairement à des GCs comme on l'entend classiquement (Java, Go…) (je parle de cPython uniquement).

A priori, Julia s'en sort bien pour le calcul scientifique. Et Erlang a plus que fait ses preuves pour les systèmes embarqués.

Ca dépend vraiment des contraintes : si par exemple tu vises des latences inférieures à la ms ça va être très dur avec un GC dès que la taille du tas devient conséquente, même si Azul par exemple a vraiment révolutionné le domaine.
Mais après c'est vrai que beaucoup de gens tapent sur les GCs sans vraiment savoir de quoi ils parlent, et c'est frustrant en 2016 d'avoir des failles dues à buffer/stack overflows plusieurs fois par semaine…

Comme je l'ai dit il est évident que les implémentations sont différentes et que la différence vient de là, je voulais savoir si quelqu'un avait une idée plus précise du pourquoi une telle différence de performance (voir ci-dessous, c'est probablement parce qu'on atteint un range error sur 32-bit). J'ai déjà jeté un oeil à l'assembleur, mais je n'avais rien vu d'évident (mis à part que les implémentations n'ont rien à voir).

D'ailleurs, en y repensant, l'appel à la fonction ne peut pas être optimisé, parce qu'elle n'est pas pure (elle peut changer errno).

C'est visiblement lié à un overflow/domain représentable par un double sur 32-bit.

En changeant l'appel à exp() en :
exp((i + j) / (double)SIZE);

Les performances sont comparables.

Non mais en tourne en rond là, c'est évident, ce qui m'intéresse c'est pourquoi la version 32 bit est si lente (je compile uniquement en -O0 pour que gcc n'optimise pas complètement la boucle, étant donné que je n'utilise pas les valeurs retournées par exp() et que c'est une fonction pure).

Merci, mais c'est évident que les versions 32-bit et 64-bit sont linké avec des libm différentes (/lib vs /lib64).
Ce que j'aimerais savoir c'est pourquoi la version 32-bit est tellement lente.

Oui, j'avais essaye avec differentes march/mtune, mais ca ne change rien…

http://en.wikipedia.org/wiki/Function_prologue.

Mais "incipit" ça fait cool, et ça rappelle "inception" (j'ai aussi horreur de ces traductions systématiques…).

Colin Watson, le mainteneur Debian, semble dire que la dépendance est très faible dans le code puisqu'il ne s'agit que de quelques lignes. Affaire à suivre…

Ca me rappelle quelque chose, un patch de quelques lignes maintenu par Debian dans un projet commençant par OpenSS… :)

bash aussi est épargé, pour peu qu'on le lance en mode posix (-p):

$ env x='() { :;}; echo vulnerable' bash -p -c "echo this is a test"
this is a test
Cette vulnérabilité exploite un bash-ism (possibilité d'exporter une fonction, pas juste une variable d'environnement).

Et si on a aucune compétence en Python, mais qu'on est bien calé ailleurs (bd, c++), ça intéresse malgré tout ?

Chez nous, malheureusement je pense que Python est un pre-requis : c'est un peu la "lingua franca", meme le CEO code regulierement en Python.

Par contre, si tu consideres un job dans la finance, je te conseille d'aller faire un tour sur le site http://www.efinancialcareers.com, C++ et Java sont tres populaires dans la finance.

Il y a pas mal d'offres, et si tu n'as pas peur du risque, je te conseille d'eviter les grands groupes du style Goldman Sachs, Bank of America, etc, et de te concentrer sur les hedge funds : c'est en quelque sorte l'equivalent des start-up dans la finance, donc atmosphere bien plus sympa que les grands groupes, projets interessants et varies, et remuneration plus attractive. Par contre, l'esperance de vie moyenne d'un hedge fund est de 5 ans, donc si tu veux la securite de l'emploi il vaut mieux eviter :-)

Ca t'amuse de toujours répondre à côté de la plaque, systématiquement ?

C'est bien ce que je dis : les 3 emplois sont fixés, le reste, ça passe sans but.

Non, on n'a pas de quotas à remplir, c'est juste une moyenne de se que l'on observe. On ne s'arrête pas au troisième candidat recruté sur l'année N, cela n'aurait aucun sens.

Maintenant, merci d'arrêter de polluer ce sujet, et d'aller jouer ailleurs, parce que cela devient fatiguant.

Comme indiqué dans mon commentaire, on est toujours à la recherche de différents profils.
Le poste en question a été - plus ou moins - pourvu, mais on n'est pas un grand groupe, avec une politique RH, des quotas et des grilles de salaires : si je me souviens bien, ils avaient cherché 6 mois avant de m'embaucher.
On ne cherche pas à remplir des cases, mais plutôt à embaucher des gens compétents, il y a toujours du boulot à faire. Par exemple, un de nos analystes a été embauché avant la fin de son PhD, mais n'a commencé que 6 mois plus tard.
Il n'y a pas d'arnaque, rien de surprenant à ce qu'un poste reste ouvert 6 mois, par contre c'est vrai que le recrutement est très sélectif (de mémoire, on doit embaucher en moyenne 3 personnes par an sur 400/500 CVs reçus).

Il y a quelques temps, j'avais posté cette offre d'emploi (bien mal m'en a pris):
http://linuxfr.org/forums/general-petites-annonces/posts/offre-d-emploi-developpeur-python-dba-dans-un-hedge-fund-a-cambridge

On est toujours à la recherche de différents profils (analyste quantitatif, développeur, etc), et beaucoup de gens dans la boîte ont des doctorats en math/physique, donc beaucoup d'analyse de données.

Si ça pourrait t'intéresser (ou un de tes potes/collègues), tu peux m'envoyer un email: cf.natali at gmail.com

P.S. : Merci d'éviter les messages du type "La finance c'est le mal", le gars cherche un boulot et j'essaie juste de l'aider…

Il faut relire la discussion complète (ce ticket, mais également la liste de discussion python-dev). Il me semble que cette option a été rejeté pour plusieurs raisons. Dave Malcolm a par exemple noté que l' "AVL tree" ne permet pas d'utiliser des types arbitraires comme clés (ou plutôt que l'AVL tree s'y prête mal).

En fait le problème est simple : avec un dictionnaire implémenté par une table de hachage, il suffit que les éléments supportent l'égalité (eq), relation d'équivalence. Pour une implémentation par arbre de recherche, il faut qu'ils soient mutuellement comparables (cmp ou @total_ordering), relation d'ordre. Donc par exemple ça ne fonctionnerait pas si on mélange des datetime.date et datetime.datetime (ce qui est une mauvaise idée, mais c'est un exemple).

OK, deja tu confonds le hedging systematique et le trading haute frequence : nous sommes un fond macro, autrement dit on s'interesse a des changements macroscopiques, a long terme, pas a la milliseconde.

Ensuite, faut arreter de croire tout ce que racontent TF1 et nos hommes politiques, hein.
La finance a bon dos, mais peut etre que si les gouvernements et les gens comme toi et moi arretaient de vivre a credit on se serait pas autant dans la merde.

Enfin, personnellement je ne risquerais jamais mon argent pour investir dans des startups, ou des bons du tresor Grec. Il y a des gens qui prennent ces risques, et il est normal qu'il soient payes en retour, non ? La bourse ne sert pas qu'a enrichir les grands patrons, elle sert aussi a financer des vrais projets.

Enfin bref, c'est affligeant tant d'ignorance…

Donc je cherche à partager ce grand tableau entre les processus. Pour cela je mets les
données dans un module tiers que j'importe et par la magie du copy-on-write ça marche bien
et vite avec fork().

Atention quand même avec le COW : en effet, tu n'as pas à te tapper la sérialisation.
Mais comme CPython utilise le comptage de référence, le simple accès en "lecture seule" de ce tableau (par exemple juste un itération) va provoquer une duplication des pages, d'où risque de OOM.

Et si tu mets un sleep de mettons 2s entre chaque commande ?

Oui, la taille est spécifiée à l'établissement de la connexion TCP : fais une capture tcpdump et regarde le MSS (maximum segment size). C'est fonction du MTU et de la receive window.

Mais tu ne pourras pas forcer la taille d'un paquet TCP : ça n'a même aucun sens puisque c'est un protocole stream.

Dans ton cas, tu peux essayer l'option TCP_CORK.

Si on arrive à intégrer tulip (PEP 3156), on devrait arriver à intégrer le travail de Victor…
Victor, d'ailleurs ça me rappelle que je dois revoir ta PEP, je vais essayer de m'y mettre cette semaine !