Guillaum a écrit 472 commentaires

Le benchmark ne teste donc pas la validité de l'implémentation (c'est testé par des tests unitaires dédiés), mais seulement sa rapidité, en mono-thread. Cela permet donc d'évaluer l'overhead des instructions atomiques, qui est ici négatif, ce qui est surprenant.

Déjà ton code est faux. var est volatile et tu le passes en tant que non volatile dans les deux fonctions. GCC emet un warning et ce n'est pas pour rien, cela n'a pas de sens, ce bench n'a pas de sens.

Et en supprimant le volatile ?

Je m'explique, le qualifier volatile en c/c++ n'est utile que pour des mappings hardware (genre device mapppé, ou interruption, …), mais il ne change RIEN pour l'atomicité des opérations, mais il empêche le compilateur d'optimiser certains traitements.

Hors le atomic est une opération hardware spécifique du CPU (Je ne sais pas comment elle fonctionne, mais il y a des chances que ton CPU soit capable en un unique cycle de faire le get/l'incrementation/le set).

A ce moment, le compilateur va simplement remplacer ton __sync par l'appel à l'instruction du CPU qui va bien.

De l'autre coté, le compilateur va être forcé de générer le code pour récupérer la valeur, l’incrémenter et la remettre en mémoire.

En gros, vire volatile et regarde ce qui ce passe. Volatile n'est pas nécessaire ni suffisant pour faire des opération thread-safe et se contente simplement d’empêcher des optimisation du compilateur ou du CPU.

On va creuser un peu. les fonctions thread_safe et not_thread_safe en -Os donnent:

thread_safe:
lock addl $1, (%rdi)
ret
not_thread_safe:
addl $1, (%rdi)
ret

Bon, rien de magique. Maintenant la boucle, bon là c'est marrant, mais la boucle genere moins d'assembleur en unsafe que en safe (globalement GCC se rend compte que c'est une boucle, l'inline, se rend compte que tu fais N fois l'incrementation et remplace tout par une unique incrementation de N, contrairement à la version /safe/ qui force la boucle et l'appel de N fois la primitive atomique.) Bref, tant que on a pas ton code complet, cela n'a pas de sens.

Bon, par contre si on met volatile AUSSI sur les prototypes des fonctions:

void thread_safe(volatile int *ptr)
{
    __sync_fetch_and_add(ptr, 1);
}

void not_thread_safe(volatile int *ptr)
{
    *ptr += 1;
}

#define BENCHMARK_ITERATIONS 10

int benchmark(const int c)
{
    volatile int var = 0;

    for (unsigned int i=0; i<c; ++i)
    {
       not_thread_safe(&var);
    }

    return var;
}

(J'ai un peu changé la fonction benchmark pour que GCC ne puisse pas inliner la boucle aussi facilement qu'avant)
Là cela devient drole, car le code (en O3) du milieu de la boucle en unsafe est donc:

.L7:                                # debut de boucle
    movl    -4(%rsp), %edx          # Fetch memoire (à cause du volatile)
    addl    $1, %eax                # compteur de boucle++
    addl    $1, %edx                # valeur++
    cmpl    %edi, %eax              # test de boucle
    movl    %edx, -4(%rsp)          # store memoire (à cause du volatile)
    jne .L7                         # Jump en fonction du test de boucle

Contre en safe:

.L7:                                # debut de boucle
    lock addl   $1, -4(%rsp)        # Incrementation atomique (note le lock)
    addl    $1, %eax                # compteur de boucle
    cmpl    %edi, %eax              # comparaison
    jne .L7                         # Jump en fonction du test de boucle

Donc la raison ici c'est que le volatile force le fetch/store alors que l'atomique ne fait rien… Test sans le volatile.

En fait, si j'ai bien compris, tu compares un code pas thread-safe à un code thread-safe et tu en conclue que le thread-safe va plus vite alors qu'il est en théorie plus lourd (i.e.: instruction atomiques).

Hum… Et il se passe quoi si dans ta boucle pas thread-safe qui compte le nombre d'essais tu saute un increment ? Et bien le pas thread-safe va faire un tour de boucle de plus, donc il sera plus lent (mais bon, c'est bugé).

Donc soit j'ai raté une étape, soit ton bench n'a pas de sens ?

Ce qu'il faudrait que tu fasses c'est mesurer le temps en sinle core avec la version pas thread safe et mesurer le temps en multi-core avec la version thread safe, tu auras ainsi une idée du cout de la synchronisation.

ou

Faire une version thread-safe lourde et comparer avec la thread safe légère.

Note que les instructions atomique sont optimistes (au contraire des instructions lourdes genre verrous et autre qui sont pessimistes). Cela signifie que tes instructions atomiques supposent que les choses se passent bien (et coûtent du temps quand les choses se passent mal).
Alors qu'un verrou fait l'inverse. Quand cela se passe bien, il coûte du temps, quand cela se passe mal, il coûte le même temps.

En gros, si tu as beaucoup d'accès partagés sur une variable, cela peu valoir le coup de mettre un vrai mutex. Si dans l'autre main tu as peu d'accès partagés, un atomique est génial (en utilisant au maximum les atomiqueInc/Dec contrairement au CompareAndSwap qui sont plus lent).

Dernièrement, je n'ai pas accès à ton code, mais il peut être intéressant de regarder sur quelles lignes de cache sont les données partagées. En effet, si elles sont sur des lignes identiques, un atomique sur un ligne va faire échouer toutes les variables atomiques de la ligne. Cela peut donc valoir le coup de mettre cela sur des lignes différentes.

tl;dr; Le benchmark me semble pourri par définition, il compare du code buggé a du code non bugé (ou j'ai raté une étape)

Ce qui est bien avec GL c'est que le système de shader est plus complet que cela.

En GL/GL-ES, tu as deux/trois/quatre stages de shader en plus:

Vertex Shader -> (Tesselation Control -> Tesselation Evaluation) -> [Geometry shader] -> Fragment shader + Compute shader.

(Entre parenthèse ce qui est strictement GL 5, entre crochet un stage optionnel et qui est disponible en GL3 ou GLES depuis peu, mais je ne crois pas sur les navigateurs).

Respectivement le travail de chacun :

Vertex Shader

Prend des points en entrée et les transforme pour generer de nouveaux points. Un point c'est une entité arbitraire, donc cela peut être une position, mais cela peut aussi être un poulet, défini par sa couleur, sa taille, ses points de vie. Le but du vertex shader est de transformer cela pour donner un nouveau point arbitraire (cela peut donc être des mesures de température liés à une date)

Pour être très honette, le viewer sur glsl sandbox utilise (obligatoirement) un Vertex Shader avec 4 points positionnés au quatre coins de l'écran. (Je n'ai pas regardé le code, on peut aussi faire autrement, mais ce serait vicieux ;)

Controle et Evaluation Tesselation Shader

Je groupe ces deux shaders car ils sont liés. Ils prennent en entrée des points et vont générer pleins de triangles/lignes. C'est généralement utilisé pour lisser les objets, mais on peut s'en servir de façon détournée (pour faire des cheveux par exemples, en générant pleins de lignes)

Geometry Shader

Celui-ci est tordu. Sont but est de prendre une primitive (i.e. un assemblage de points) et de générer une/plusieurs nouvelles primitives. Dans les grandes ligne GL ne connaît que trois primitives (point, ligne, triangle) (c'est encore faux, mais bon, vous lirez la doc pour plus). Un exemple d'utilisation du geometry shader pourrait être de convertir un point en triangles. Exemple vous avez un arbre, représenté par un point contenant une couleur, une position, une taille, un type de feuille et vous aller mettre un tas de triangle à la place.

Generalement on utilise le géometrie shader pour des cas tordus, d'autant qu'il est lent, donc on le réserve pour des usages bizarres ;)

Ici il faut faire une pause. Tout ces traitement ont eu lieu sur des points arbitraires (comme je le disais, des poulets), mais maintenant il faut savoir quoi afficher à l'écran. Pour cela il faut connaître la position 3D de vos points. Ainsi nos points qui étaient arbitraire au depart doivent sortir du geometry shader (ou du tesselation si le geometry n'est pas utilisé, ou du vertex shader si ni geometry ni tesselation ne sont activés) avec une position.

Ainsi on passe d'un point arbitraire (un poulet) à un point positioné dans l'espace avec des attributs arbitraires (i.e.: une position associée à une couleur, une taille, une agressivité et des points de vie).

A ce moment, la carte graphique va decider des pixels qui sont couverts par notre primitive et pour chacun de ses pixels elle va appeler le fragment shader (i.e.: le seul bout de code disponible dans l’outil presenté dans ce journal)

Fragment shader

Sert à donner une couleur et une profondeur à un pixel en fonction des attributs interpolés des points passés en paramètre pour dessiner une primitive.

Vous l'aurez conclu vous même, sans control sur les points passés en paramètre et sur le type de primitive, le fragment shader ne sert qu'a "donner une couleur à un pixel arbitraire" et c'est super limité !

Relativisons, on peut faire pleins de choses, mais comparé à ce qui est normalement faisable dans GL, c'est limité.

Il reste un dernier shader (GL4.3 dernièrement) c'est le Compute shader, qui sert à tout faire, et même le café, sans aucune aide de la part du GPU pour par exemple afficher. C'est moins limité, mais plus lent dans certains cas, donc il faut l'utiliser au bon endroit.

tl;dr

C'est limité, GL permet de faire tellement plus de chose. Mais c'est tout de même cool !

J'ai 27 ans. Il y a 4 ans je sortais d'une grosse école d'ingé en informatique française dans laquelle j'ai appris à mentir, ne pas faire mon travail et surtout, être superficiel (Je troll, mais les rares moments dans ma vie ou je trouve que mon cursus d'école d'ingénieur m'a appris quelque chose c'est quand je ment ou que je fais mal mon travail, j'ai juste un peu moins honte de le faire).

Quand je suis sorti d'école préparatoire j'ai hésité. J'avais déjà un gros bagage en informatique et je me demandais si il ne serait pas rentable de suivre une formation en électronique, bâtiment, mécanique, … J'aurais appris des choses et j'aurais pu mettre mes compétences en informatique au service d'un autre domaine. Finalement j'ai été convaincu par un ami de faire de l'informatique. La raison première est que j'aime cela. C'est une science extraordinaire où tout est possible. C'est surement une des rares science où l'on peut apprendre par soit même et faire des expérience dans son garage (il suffit d'un ordinateur. c'était cher quand j'ai commencé à coder, il y a 15 ans, mais accessible. Aujourd'hui tout le monde à un ordinateur. Tout le monde peu expérimenter, crée, concevoir, dans sa cave, à partir de 5 ans… Je trouve cela beau. Va demander de l'uranium enrichi, une tour à béton ou un accélérateur de particule à tes parents pour l'anniversaire de tes 10 ans.)

C'est aussi la science de la simplification de vie. Comme tout bon informaticien, je suis fainéant. Si je peux optimiser ou faire disparaitre une tache régulière en créent un outil, je vais le faire. Mais tous le monde n'a pas les compétences pour se simplifier la vie, donc je me suis imaginé en grand sauveur de l'humanité, créant des outils pour permettre à la population de gagner du temps (temps qui pourrait être utiliser pour geeker et ainsi créer d'autres outil). Et c'est ainsi que j'ai rejoins une école d'ingénieur en informatique, pour changer le monde ;)

Je passe sur ma désillusion de la formation, cela pourrait faire l'objet d'un bouquin (Je suis persuadé que les école d’ingénieur en france ne forment pas bien les étudiants, mais comme ceux-ci ont été sélectionné au départ, au final il y a peu de déchet. Par exemple, j'ai trouvé la formation que j'ai eu à la fac lors de mon double diplôme bien meilleure, la différence c'est que comme tout le monde peu entrer à la fac, et que tout le monde en sort, le niveau est moins bon.). Je vais cependant insister sur un point. Nous étions en cours de "communication/discussion/culture" et l'enseignant à voulu ouvrir le débat sur la raison de notre présence dans cette école d'ingénieur en informatique. Une trentaine de personne dans la pièce. Pleins de raisons sortent ("Le diplôme est bien valorisé, le salaire en sortie d'école est important, les possibilités de carrière sont énormes, c'est la spécialité où si l'on ne veut pas faire de technique c’est très simple de bifurquer sur autre chose") et là on se regarde avec un ami et on dit que nous on trouve que c'est une science intéressante et que on aime la technique. Je me souviens encore du regard de tous les autres étudiants à la limite du choc de découvrir que des gens peuvent aimer l'informatique en tant que tel et pas comme une passerelle vers autre chose (l'argent, la gloire, …). J'ai tout de même fini mon cursus (mais avec largement moins de motivation qu'à l'entrée).

J'ai pris peur du monde du travail lors de mes stages ou de mes entretiens d'embauche. Entre les stages ou il n'y a aucune qualité dans le travail effectué (quoi, on bosse directement sur la base de production et on modifie à la main le code d'un clone du production et après on fait la même modification à la main sur les autres clones), entre les entretiens d'embauches ou je rentrais dans une grille (Donc vous êtes ingénieur ****, ok, on vous embauche, quoi, vous voulez négocier parce que vous avez plus de 5 ans d’expérience de contribution au libre et vous pensez être plus compétant que les autre ingés **** que l'on vient d'embaucher, mais mon brave monsieur…). Entre les entretiens faussement technique (Vous avec combien d'année d’expérience en OpenCL… 1 ans… Mais c'est pas assez… (à cette époque les spécifications opencl avait été publiée dans l'année…). Ou vous maitrisez le HTML ? Le DHML ? Le javascript ? L'ecmascript ? Le web 2.0 ? l'ajax…) Vous avez 3 ans d’expérience OpenGL, mais pas de direct3D, on ne peut pas vous embaucher (pour le débat, oui les deux technos sont différentes, mais bon, ce qui est important c'est de comprendre comment fonctionne une carte graphique, le reste c'est là même chose dans les grandes lignes). Le pire sans doute à été de réaliser que l'on était que des ressources sans valeur ajouté. Un jour le responsable technique d'un projet m'a dit "Nous avons un devoir de conseil envers la direction, mais nous devons appliquer leur décisions à la lettre" à propos d'une décision technique voulue par la direction qui n'avait aucun sens. Cette décision à été appliquée contre l'avis des "gens qui savent comment ce truc fonctionne" et il a fallu tout réparer deux mois plus tard. Je ne prétend pas comprendre le travail du marketing et de la direction (et je suis content qu'ils soient là parce que sinon notre travail ne peu pas être valorisé), mais l'inverse est aussi vrai, sans technique, pas de produit à vendre, et c'est trop souvent oublié. Pourquoi cette relation est elle à sens unique ?

Bref, avec tout cela, j'ai craqué, et j'ai décidé de faire une thèse (et j'ai fais une croix sur les sous). La thèse se finie presque mais je n'ai pas envie de continuer la dedans. En France la recherche est super mal valorisée. La plupart des gens pensent que l'on est des branleurs dans un labo bien au chaud, les recruteurs se demandent ce que l'on a fait pendant 3/4 ans et ont peur que l'on soit trop qualifié et que l'on demande trop d'argent. Et la recherche en soit c'est très frustrant. Tu as une idée, tu la creuse, ça marche, ça marche vraiment bien. Tu tentes une publication. Refusée, mal rédigée. Tu rédiges cela mieux. Refusée, tu ne te compares pas à une méthode qui à été publiée la semaine dernière. Tu fais la comparaison, refusée, quelqu'un a publié un article avec une méthode équivalente, ok, tu peux jeter 2 ans de travail, nouvelle idée, 6 mois de boulot… bon cela ne marche pas… Mince, cela fait déjà 3 ans… il faut que je rédige, mais je n'ai rien… De nos jours pour faire un article de recherche il faut avoir une bonne idée (ce qui n'est pas gagné, certains domaines sont vraiment très concurrentiels), avoir une bonne réalisation (i.e. un code correct, cela je sais faire). Avoir une preuve mathématique forte (c'est plus dure et c'est souvent frustrant car tu prouves des choses théoriques non applicables, du genre que ton algorithme est correct à l'infini, mais en pratique tu n'atteindras jamais ce temps), savoir rédiger (ça quand tu es français c'est pas gagné "I are actually a firking rezearch studen"), savoir mettre en valeur (oui, tu travailles sur de l'affichage de texte, mais tu dois faire une vidéo digne de pixar dans laquelle ta contribution est utilisée pour les crédits). Bref, je devrais soutenir ma thèse sous peu. (dont je suis très satisfait personnellement, j'ai beaucoup appris, j'ai testé/expérimenté énormément de choses. Malheureusement pour la communauté il s'agit d'une thèse peu brillante, j'ai peu de publications (on ne publie pas les choses testées qui échouent)).

Alors j'ai recommencé à chercher un emploi. Pas dans la recherche, j'ai trop souffert du manque de valorisation, de l’échec permanent (note: ce n'est pas forcement le cas pour tous le monde. Sans doute suis-je mauvais, ou alors c'est une loterie ?) Les entretiens d'embauches sont les même, je n'ai encore trouvé aucune boite pour qui mon expérience (même si elle est petite) est intéressante. Généralement mon CV est résumé à "Ingenieur **** - Sans expérience pro depuis 4 ans. C++". Les seuls offre intéressantes sont à l'étranger (ou à paris, mais c'est pareil ;) mais je n'ai pas envi de bouger pendant au moins 3 ans (pour des raisons familiales, enfant/compagne avec un diplôme à la con qu'elle doit finir et qui ne pourra jamais quitter la France car pas/peu valable à l'étranger). Et pourtant je ne suis pas perdu dans la campagne, je suis dans la seconde plus grande ville de France.

J'ai pas mal envisagé de tout changer. Devenir moniteur d'escalade, de montagne, de parachutisme. Devenir enseignant de 3D dans une école d'art. Mais je n'ai aucune qualification pour cela. J'envisage aussi de changer et de me mettre en mode management requin. Voir si cela passe, pendant combien de temps cela passe. Si au final je gagne assez d'argent pour pouvoir me payer des loisirs sympas pendant mon temps libre, c'est sans doute une façon correcte de voir les choses (mais bien loin de mon idéal initial).

J'ai beaucoup parlé de moi alors que c'est ton journal et je m'en excuse, c'est un peu pour dire que tu n'es pas seul dans ces grandes interrogations. J'ai plusieurs fois relu mon texte en me disant que cela n'apporterais rien à ton journal et en pensant ne pas le soumettre, et finalement je vais valider, parce que j'ai passé du temps à écrire cela, et que cela peu ajouter quelques détails à la discussion.

tl/dr; T'es pas le seul à souffrir, à être perdu.

De l'oeil ?

J'ai un œil droit plutôt mauvais et un œil gauche de pilote de chasse, alors c'est un peu dommage que la vidéo soit à droite…

Enfin bon, cela me motivera pour me faire opérer // aller chez l'ophtalmo.

Souvent les GPUs exposent des instructions hardware permettant d'optimiser les rendus graphiques, il est peut-être possible d'en tirer parti pour faire une transformée de Fourier accélérée.

Je me suis mal exprimé. Tout à fait d'accord que certains problèmes (typiquement une transformé de fourier) sont plus adaptés à un GPU qu'un CPU, mais cela ne veut pas dire que ce n'est pas optimisable sur CPU et que le jeux n'en vaut pas la chandelle. En ce moment on assiste à une grande passion pour le GPU, mais si les développeurs passaient autant de temps à optimiser pour CPU qu'il le font pour GPU, beaucoup de code CPU tourneraient bien plus vite.

Programmer pour GPU c'est globalement faire du C avec d’énormes contraintes. Du C où tu sais comment les données sont disposées en mémoire, du C où tu sais comment la machine charge les données. Du C où tu essayes de ne pas faire de if parce que c'est mal. Du C où tu n'aimes pas les accès aléatoire au données. Du C où tu fais toi même les copies entre la ram et le cache parce que la machine ne le fait pas pour toi. Du C sans fonctions récursives. Du C sans types "pratiques" (les doubles… LOL…).

Les instructions hardware disponibles dans un GPU sont souvent liées au pipeline graphique (globalement: remplir des triangles), qui n'est pas exposé dans OpenCL.

En pratique ce que va t'exposer OpenCL c'est certaines fonctions optimisées ou calculs vectoriels, mais tout cela est aussi disponible sur un bon CPU (sse/avx). Le truc c'est qu'avec un peu de chance, sur CPU ton compilateur va savoir exploiter cela tout seul, sur GPU il faut le faire à la main.

Ce qui fait la différence entre un GPU et un CPU c'est que l'architecture est différente, ainsi en fonction du type de problème à traiter, il est clair qu'un GPU sera plus adapté et pourra roxer à mort du pinguin en performance (en fait tout les problèmes qui peuvent se décomposer en une grosse quantité de sous problèmes identiques et indépendants nececitant beaucoup de calcul et générant peu de transactions mémoire).

Donc un GPU n'est pas une bête simple à domestiquer et un code "naïf" sur GPU ne va pas donner grand chose comparé au même code naïf sur CPU.

C'est sûr, mais pour y avoir goûté ça pique vraiment, donc ça se comprend qu'on ait envie d'avoir un driver OpenCL plutôt que de devoir jouer avec des framebuffer objects, des textures, du glsl…

Essayes OpenCL… C'est la même chose, tu remplaces les framebuffer objects par des buffer objects, les textures par des images et le glsl par de l'OpenCl ;) C'est juste plus générique et permet de cibler avec le même code deux plateformes hétérogènes (CPU et GPU), mais ce n'est finalement pas si simble.

tl/dr: Le GPU c'est cool. J'aimerais bien avoir OpenCL disponible de partout sans me poser de question, mais s'il vous plait, arrêter de brandir le mot GPU de partout en disant que cela va sauver le monde et que c'est la solution à tout les problèmes, après il y a des décideurs qui écoutent…

Je ne comprend pas du tout ce que tu racontes sur le fait que que OpenCL permet d'optimiser les transformée de fourier contrairement à pthreads ou openMP.

OpenCL n'a rien de magique. Tout ce que tu peux faire avec OpenCL peut être fait avec n'importe quel api à base de thread sur CPU (TBB, openMP, pthread). Et tout ce que tu peux faire sur GPU se fait avec une autre API comme OpenGL ou DirectX. C'est juste une façon de programmer différente.

Ce qui fait la force d'openCL c'est que c'est le seul outil qui tourne autant sur CPU que sur GPU de façon unifiée. Maintenant cela ne veut pas dire que c'est transparent (en pratique il faut souvent écrire un code différent pour CPU et pour GPU), et il faut soit même faire la répartition du travail entre le CPU et le GPU (ainsi que les synchronisations/ transferts, …).

Bref, openCL est une très belle techno (malheureusement qui a du mal à s'imposer face à cuda), mais ce n'est pas un truc magique qui accélère l'internet et fait le café.

J'ai essayé plusieurs fois d'utiliser Mercurial pour mes projets perso, mais le truc ne sait rien faire de base, il faut avoir recours à des extensions : pour éditer l'historique (git rebase -i), faire des commit partiels (git add -p).

Pour l'histoire des extensions, c'est plutôt un problème de design de l'UI. Il s'agit plutôt de fonctions activées ou desactivées. Sur n'importe quelle machine tu commences par crée ton .hgrc avec ton nom de commit, et tu ajoutes les extensions que tu désires. Cela simplifie l'aide intégrée de Mercurial qui ne liste que les extensions activés, ainsi on ne se perd pas au milieu de millions de fonctionnalités. Aussi certaines "extensions" propose une réponse différente au même problème, ainsi c'est à l'utilisateur de savoir celle qu'il désire activer.

C'est un peu comme si l'on reprochait à Firefox de ne pas venir avec toutes ses extensions par défaut. Pour toi le rebase est peut-être important, mais il ne l'ai pas forcement pour moi (Simplement parce que c'est un concept un peu plus avancé de la gestion de version), ainsi ce n'est pas visible par défaut.

Pour git rebase ou les commits partiels j'accorderais une chose, c'est que le mode interactif de mercurial est limité.

Et il y a des concepts que je n'arrive pas à retrouver (le concept de dépôt distant, git remote)

git remote, c'est pas juste une fonction qui permet de changer la liste des alias des dépots distant ? Dans mercurial cela s'appelle vim et tu modifies un fichier de configuration en ajoutant ces lignes:

[paths]
default=http://depot1
alias1=http://depot2
…

Là c'est juste de l'UI, mais par principe je ne suis pas fan des outils qui font des choses simples à ma place

Pour le concept de dépôt distant, je n'ai pas compris ce que c'est… Ce n'est pas juste un dépôt dans lequel il n'y a pas de copie de travail ?

Je ne me considère pas forcement comme un fanboy, et un jour je quitterais très certainement Mercurial pour Git (la victoire du plus gros), mais j'aurais quelques arguments en faveur de Mercurial (subjectif, je n'ai pas touché à git sauf pour des petits patchs tout simple depuis 4 ans)

Je passe sur le coté "je trouve cela plus simple, je n'ai jamais eu à lire le man de mercurial comparé à celui de git…" qui est hautement subjectif.

Il y a un truc que j'aime beaucoup dans Mercurial, c'est les phases. Ainsi un commit "phasé" comme étant définitif ne peut plus être rebase/amend ou autre. Cela évite le traditionnel problème de git de "Hey, mais t'a rebase sur des commits distribués à toute l'équipe… on fait quoi maintenant". Ou le traditionnel "Mais, t'as pull des changements que je voulais modifier…"

La prochaine version de Mercurial devrait commencer à amener le concept d'evolve que je trouve très propre. C'est du rebase/amend mais avec conservation de l'historique (caché) des changements détruits (et avec une relation entre les nouveaux commits rebasés et les anciens). Je m'en sers personnellement depuis quelques mois et c'est vraiment sympathique. (Je sais que git conserve les anciens changset devenu obsolète suite à un rebase/…, mais à ma connaissance git ne conserve pas l'historique et la raison de cette obsolescence).

Un fanboy de Git pourrait-il m'expliquer ce qu'il aime dans Git et pourquoi cela roxxe du poney ? Surtout niveau fonctionnalités.

+1 ici… cela me fait rire, pour l'instant on est à 18, généralement au pire on à 16 au milieu de l'hiver. Après on est peu frileux… je met un pull seulement quand c'est à 16, le reste du temps je suis généralement pied nu/short/tishort.

Je me demande à combien chauffent les voisins ?

Une seule chose m'inquiète. Au final, est-ce le plus rentable (je ne parle pas de ma facture EDF, je parle de la communauté). Pour maintenir mon appart à 18, est-ce que le surcout de chauffage des voisins est moins important que mon économie ?

Cela me rappel l'avant seconde guerre mondiale et la montée de l’antisémitisme…

Au passage j'ai juste lancé le bench polynom avec pypy.

python2: 140s
python3: 110s
pypy1.9: 5s

Ben quoi, il marche bien notre JIT python ;)

Ma skin aussi (sur mes deux claviers) se fend doucement sur les cotés et fond en laissant ces marques jaunes bizarres. J'avais associé cela aux lavages que je donne à la skin tous les mois, mais si tu confirmes que tu obtiens la même chose, c'est surement un problème de fabrication. Quoi qu'il en soit, cela ne gène en rien l'utilisation de celle-ci.

Skin blanche ici.

Non, tu as raison (si je ne me trompe pas).

GL n'impose RIEN quand au support materiel, GL ne fait que proposer une API qui pourra optionnelement etre accelerée par le hardware.

Ici sur une carte Nvidia haut de gamme, les float 64 bits sont plus lent que les 32, mais cela va.
Sur ma carte AMD entrée de gamme, ils ont beau etre suportés (ie: cela marche), les performances sont 100x plus lentes que pour les float 32bits.

AMD est en gl 4.2, on attend le driver 4.3, mais la sortie de GL 4.3 datant d'une semaine, j'estime cela une attente pour l'instant correcte.
Nvidia est en GL 4.3, Rien à dire.
Intel est en GL 4.1 ou 4.0 sous windows exclusivement, GL 3.0 sous linux. Maintenant il faut aussi voir que jusqu'à cet été (sortie des HD4000 d'intel), la plupart des cartes graphiques du marché (ie: intel) ne supportaient pas la tesselation matériel, donc pas besoin de GL >= 4.0.
Pas la moindre idée pour les constructeurs mobiles.

AMD et Nvidia sont à jour, intel n'est pas pressé car ils ne visent pas le même marché (ie: les gamers du dimanche ont des drivers GL 4 pour windows pour faire tourner les jeux GL… en fait non, il n'y a pas de jeux GL… Sous linux, plateforme sur laquelle il n'y a pas de jeu, direct X où GL, on s'en cogne, GL 3.0 est suffisant pour le Desktop, et les rares personnes qui voudraient des drivers GL 4 pour cartes intel, je n'en connais pas à part moi (qui aimerait tester mes algos de recherche même quand je suis en balade avec mon ordinateur portable)

Donc globalement la faute au constructeur, mais bon, ici le constructeur qui est le plus à la traîne, c'est celui qui fait du libre, donc c'est peut-être en grande partie aussi la faute au stack libre qui traîne un peu.

Maintenant il faut aussi voir que les versions de GL correspondent aussi à un support matériel particulier.

Par exemple, entre gl 4.0 et 3.3, c'est le support de la tesselation. GL 4.2 apporte le support des atomics et GL 4.3 apporte le support du compute shader (une sorte de cuda/opencl mieux intégré à GL)

Maintenant pour un développeur qui n'a pas besoin de cela, il peut facilement vivre en GL 3.3. (3.3 nettoie beaucoup de choses, et coder du GL 3.2 c'est l'horreur, surtout pour écrire les shaders). Il peut faire la même chose en GL 3.2 et si il ne se sert pas du geometry shader, il supportera GL 3.1/3.0.

De plus la plupart des dev de jeu utilisent toujours un vieux GL avec les extensions qui vont bien, ainsi il est possible d'avoir accès à l'api gl 4.0 sur une carte qui date un peu, mais certaines fonctionnalités seront lente ou indisponible. Si je ne me trompe pas je crois que doom 3 est exclusivement écrit en GL 1.0 + extensions.

Donc ce qui manque pour que cela bouge c'est à mon sens plus de produit tout public gl 4.3 (en fait des produits qui utilisent VRAIMENT les fonctionnalités de GL 4.3, mais qui n'ont pas besoin d'une carte graphique puissante) et ces produits cela va étre des jeux. Et c'est là que cela devient intéressant, parce que les jeux mobile c'est justement ce qui monte et dans ce domaine GL ES est presque incontournable. Mais GL ES ne couvre pas beaucoup de fonctionnalités "Desktop only" fournie par GL (il faut que je relise la spec pour ne pas dire de connerie, mais il n'y a pas de compute shader, pas de tesellation, pas d'atomic et pas de geometry)

C'est dingue, actuellement on est a 25 personnes en Antarctique, selon wikipedia la population estimée de ce beau continent est de 1500 personnes, donc on est presque à 2% de la population de l’antarctique représentée sur linuxfr.

Il y a un biais de sélection ou de la triche ?

En fait c'est rare et périodique, mais avec des périodes alternées, tous les cent ans environs entre deux périodes de 10 ans environ.

D'après Wikipedia, les précédents étaient en:

1631-1639
1761-1769
1874-1882
2004-2012

Et le prochains sera en: 2117-2125.

Donc à chaque fois une dizaine d'année ou cent ans ;)

Et le précédant, j'y étais ;) Je serais sûrement mort pour le suivant.

http://gobpower.free.fr/venus.jpg

C'est fait à la webcam dans un champs après avoir tirer 100 mètre de câble électrique pour allumer la tour. Pour la petite histoire, j'avais passé la nuit précedant à compiler Video 4 Linux sous Gentoo pour être certain d'y arriver.

Damned, il m'a fallu 1h30 pour calculer Z_C'… Je suis vieux…

J'ai aussi du me rappel l'integration par partie, mais normalement eux savent ;) sinon cela me semble pas si dur que cela.

Je trouve la partie algo sympathique, mais j'interdirais les calculatrice au bac, pour éviter qu'un idiot passe une heure à implémenter le truc pour vérifier la première question.

Sous ce titre un peu digne de rien du tout, je m'en vais dénoncer grave. Vous vous rendez compte que l'on ne parle que d'une problème de changement d'heure sur la freebox.

L'heure de la freebox ce n'est pas le truc le plus critique en ce moment, Free pourrait plutôt s'occuper du réseau téléphonique qui est tout le temps occupé, ou des chaînes TV qui ne passent plus car "Le début n'est pas suffisant". Mais l'heure ? WTF, au pire vous aller rater l'enregistrement du second épisode de Stargate SG1, mais bon, on les a déjà tous vu trente fois… (grr, il va falloir le regarder sur le replay), mais sinon…

Ce qui serait intéressant c'est de savoir si des failles critiques de la libc sont présentes dans les boxs et là on pourrait hurler au scandale. Mais là… Il n'y a rien de critique…

Cela permet aussi de se la péter au (bar|club de gym|salle d'escalade|bibliothèque) du coin en expliquant d'où vient le problème. Cela peut aussi permettre de parler du libre. Grâce à ce bug j'ai présenté le libre à dix personnes aujourd'hui qui sont ressorties convaincues ;)

Puis ça m'a bien fait marrer.

Puis cela à bien justifié dix minutes de pause de plus au café.

Bref, pas de quoi en faire un fromage (miam !)

Merci (pour la correction et la compassion) ;)

Oui, better kernel ever ;)

Voila, cela faisait plusieurs semaines que j'attendais ce noyau comme si il s’agissait du saint Graal pour la réduction de la consommation d’énergie. Et paf, voila que l'on me vole mon ordinateur la veille de la sortie… Damn ! Je ne saurais jamais.

Alors, chez vous cela consomme moins ?

Tient, sinon une autre solution marrante, avec ctypes.

a) tu compiles un .so à partir de beep :

gcc -shared beep.c -o beep.so

b) tu fais un programme python qui fait le boulot en chargeant le module .so

import ctypes

class beep_parms_t(ctypes.Structure):
    _fields_ = [
            ('freq', ctypes.c_float),
            ('length', ctypes.c_int),
            ('reps', ctypes.c_int),
            ('delay', ctypes.c_int),
            ('end_delay', ctypes.c_int),
            ('stdin_beep', ctypes.c_int),
            ('verbose', ctypes.c_int),
            ('next', ctypes.c_void_p),
        ]

# load the beep library
lib = ctypes.CDLL('./beep.so')
lib.play_beep.argtypes = (beep_parms_t, )

def beep(frequency=440.0,
         length=200,
         reps=1,
         delay=100,
         end_delay=False,
         stdin_beep=False,
         verbose=False):
    '''
    Play a beep.
    '''

    param = beep_parms_t()
    param.freq = frequency
    param.length = length
    param.reps = reps
    param.delay = delay
    param.end_delay = end_delay
    param.stdin_beep = stdin_beep
    param.verbose = verbose
    param.next = None

    lib.play_beep(param)

# usage simple
beep()
beep(frequency=500, reps=2)

c) A toi de gérer le cas ou les choses tournent mal avec ton programme (ie, signal handler/atexit/…)

(edit) Et en fait il semblerait que cela se passe bien, parce que lorsque le processus ferme le descripteur de fichier du beep, le système arrête le beep (mais dans ce cas là, à quoi sert le handler de signal dans beep.c ?)

Projet sympa.

Pour beep, tu peux utiliser subprocess.Popen()….kill() au lieu d'un signal à la main (.kill() fera la même chose, mais tu auras moins l'impression de le faire à la main)

Sinon, regarde le code de beep, c'est 300 lignes de C, 150 pour parser la ligne de commande, 50 pour les includes, 100 de boiler plate, 25 d'accolades, 12 de commentaires et deux ou trois d'utiles dans lesquelles tu ouvres un fichier et tu écris dedans. Tu peux faire cela en python trivialement et ainsi t'affranchir de dépendance tout en ayant plus de contrôle.

Et l'on a le droit de répondre aux questions même si l'on n'est pas Victor ni Antoine ?

Avec vim, mais oui ;)