Anthony Jaguenaud a écrit 1970 commentaires

On ne parle pas de la même chose. D’un côté vous parlez de calcul scientifique, recherche modification d’algo pour gagner du temps. Quand l’algo est prêt, après plusieurs années de recherche, il est publié, intégré dans une bibliothèque et utilisable.

De l’autre, je parle rationalisation, coût.

Le problème à la base est de savoir si openBSD a raison de refuser les optimisations qui nuise à la lisibilité du code. Je réponds : « oui ». Car openBSD est la comme serveur, ce n’est pas un super calculateur numérique.

Quand à ta remarque :

Tu n’as vraiment pas l’air de bosser dans le domaine.

Tu as raison, je ne suis pas mathématicien, je suis spécialisé dans le temps réel aéronautique. Ce qui nous intéresse par exemple, c’est de garantir que l’information du capteur vts, alt soit afficher au pilote en moins de x ms. On s’en fout complètement de rendre l’algo obscure pour donner l’information en x÷5, car le coût induit en test, certification etc. explosera d’un facteur × 10 ou plus.

Mon expérience, d’optimisation est là. Quand ça passe pas, il faut trouver une solution. Le plus contraint que j’ai eu à optimiser, c’est sur un calculateur relier à d’autre par 3 bus différents. Où il fallait caler les échanges bus + les calculs en dessous de 1ms. Avec un proc PowerPC en dessous de 1GHz. On a fait des analyses de ce qui passait sur les bus (vive les analyseurs PCI). Quand on a atteint les 987μs, on a fait validé le produit.

L’utilisation de la carte graphique 3D permet de faire des choses sympa et joli. Je suis d’accord que compiz était too much, mais avec kwin (de kde), tu peux en utilisant + éclater toutes les fenêtres et les afficher en petit sur ton écran quelque soit le bureau. Ensuite, avec les flèches tu peux sélectionner la bonne fenêtre. Mais tu peux aussi filtrer en tapant le nom du logiciel, du titre de la fenêtre (contenant souvent le nom du fichier ouvert…). Personnellement, je trouve ça très ergonomique, joli et surtout sans sortir les mains de mon clavier ;-)

Oui et non.

Oui, je suis d’accord sur le principe, mais dans la pratique, le coût non négligeable de te baser sur des euristiques liées à ton processeur qui deviendront fausse dès la prochaine génération, car :

• Les lignes de cache ne feront plus la même taille,
• La prédiction de branchement sera plus efficace,
• Le cache sera plus gros et tout tiendra dedans.

n’est pas intéressant. Il vaut mieux se concentrer sur les structures de données, et faire des algo compréhensible par les compilateurs de façon à se qu’ils optimisent. Par expérience, à moins d’investir énormément, le choix de l’algo et son codage simple permet au compilateur de donner de très bon résultat.

De plus, tu occultes le fait que tout le monde n’a pas une puce Intel et que dans ce cas, il faut aussi optimiser pour AMD, faire un algo spécial pour chaque ARM, etc.

C’est envisageable quand tu fais de l’embarqué, que tu connais ta cible pour de l’applicatif PC, c’est de la masturbation intellectuelle. C’est ce que je disais dans un autre commentaire, c’est intéressant pour le sport, pour le défi, mais ça n’a aucune importance pour ça.

Pour produire des trucs hyper spécifiques comme une bibliothèque de calcul matriciel, ok, c’est envisageable d’investir sur plusieurs CPU, faire différents codes, analyser les performances… mais pour de l’applicatif, ce n’est pas généralisable.

Je suis d’accord avec toi que ce genre d’article est intéressant pour le garder à l’esprit. Mais il ne faut pas tomber dans le travers inverse à chasser la dernière ns en dépensant 30 jours de développement.

Je vois que tu es universitaire d’après ton lien page perso. Ce qui explique cela. Dans l’industrie, le but est d’atteindre un objectif quantifiable et donc chiffrable en €. Le but n’est plus le sport intellectuel, bien que je le regrette parfois ;-)

Sur certains projets, on peut même diminuer une contrainte temporelle si on sent qu’elle risque de coûter trop cher.

Je suis en accord avec ton post, sauf sur le 32 bits. S’il change de machine, un système 64bits est plus logique, de plus, wine n’a plus vraiment de soucis pour utiliser des logiciels 32 bits sur un OS 64 bits.

Sinon, pour la tradition linuxfrienne un peu d’orthographe : il y a (verbe avoir) ne prend pas d’accent. On pourrait écrire, « il y avait de l’eau dans ce verre. ». Bon je retourne boire mon rhum puisqu’il n’y a plus d’eau…

Je ne vois vraiment pas comment des projets pourraient investir autant dans la performance alors qu'il y a si peu de projet qui investissent la moité dans la correction de leur logiciel.

Oui, je suis d’accord avec toi. C’est la conclusion à laquelle je voulais venir, c’est que d’un côté les projets libres n’ont pas les moyens d’optimiser dans les règles. Et que openBSD n’a pas les moyens d’auditer les optimisations de logiciel tiers. Donc ils ont fait le choix de faire les choses simplement. Avec des exigences perfo simple et pas trop contraignantes. La sécurité est, de leur point de vu, à ce prix.

En général, on optimise pour atteindre un objectif. Si c’est juste pour le sport (passer 1 mois à gagner 3 requêtes par seconde), le code devient crade.

Avant d’optimiser, il faut avoir un objectif. Pour nginx ça pourrait-être livrer 1000000 de pages statique d’une certaine taille par seconde.

Ensuite, il faut vérifier que le code simple initial ne répond pas déjà à l’objectif.

Si ce n’est pas le cas, il faut trouver quels sont les points de ralentissement du logiciel.

Optimiser intelligemment certains points uniquement jusqu’à atteindre l’objectif. Et surtout documenter et prouver chaque optimisation.

En faisant tout ça dans les règles, optimiser coûte cher. C’est simple de gagner au début en organisant correctement les données en fonction de l’usage : ne pas utiliser des listes chaînés si on accède principalement par index…, mais gratter les dernière μs pour passer en dessous de 1 ms sur des processeurs pas tout jeune, en étant capable de prouver qu’il n’y a de régression, ce n’est pas évident.

Il y a plein de constructions de base en haskell que je trouve complètement illisibles. Les développeurs haskell les trouvent parfaitement lisibles, et très concises, moi pas. Après, les goûts et les couleurs…

Moi, quand j’ai vu l’exemple de la liste de fibo infinie, et on demande la valeur qu’on veut, comme l’index de la liste, je me suis mis en tête de faire la même pour les nombres premiers. Je suis d’accord que dans ce cas, l’exercice est intéressant pour le style, pour la lisibilité…

prem = 2:[a | a <- [3,5..], (product (map (\x -> mod a x) ([3,5..truncate(sqrt (fromIntegral a::Float))]))) /= 0 ]
prem' = 2:[a | a <- [3,5..], (product (map (\x -> mod a x) (takeWhile (<= truncate(sqrt (fromIntegral a::Float))) prem'))) /= 0 ]
prem'' = 2:[a | a <- [3,5..], (all (/= 0) (map (\x -> mod a x) (takeWhile (<= truncate(sqrt (fromIntegral a::Float))) prem''))) ]

Il m’a fallu deux jours pour aboutir… la version la plus rapide est la liste prem''.

Sinon, je trouve haskell plutôt simple et clair. Il faut rentrer dans le langage, mais comme dans tous. On peut y écrire des trucs affreux comme dans tous.

Je crois que le problème vient plus de l’usage détourné de certaines spécificités :

c = (toto % 2 ? add: mult)(a,b);

(f) && f(param1);

(p) && delete (p) || (p = new(int));

C’est évidemment lisible, mais rarement au premier coup d’œil. Après, j’ai connu l’excès inverse sur certains projets, où pour simplifier on interdit plein de construction du langage, et tu te retrouves à recoder ou contourner les limitations imposées…

Le print d écrit 0.0 donc float sinon ce serait : 0 comme l’autre.

La division entière est définie de

Donc comment définir le résultat de 15,1 / 5,1 ?

• Ça revient à 15/ 5 == 3 ?
• Ou E(15,1 / 5,1) == 2 ? (15,1 / 5,1 == 2,96… la partie entière vaut donc 2)

Et ton message révèle en beauté pourquoi c'est moche de forcer l'indentation…

Sérieusement, c'est le truc qui m'empêche de me mettre au python. Après tout, l'indentation, je sais que c'est nécessaire, mais j'aime avoir la liberté de choisir celle que je préfère, et il y à même des gens qui ont créé astyle, qui permets de pull un projet avec mon codestyle, et de le push avec le codestyle d'origine.

Honnêtement, quand tu arrives sur un projet, c’est chiant de faire comme tout le monde au niveau de l’indentation… mais quand tu es sur la troisième version d’un projet, avec 30 personnes qui bossent dessus, tu es content que les deux premières versions respectassent des règles de codage… parce que sinon, avec 2 × 30 personnes avant, sur différents composants, je te raconte pas l’horreur de te retrouver dans un code où chaque fichier suis un template différent.

Je suis d’accord pour dire que c’est contraignant et nécessaire.

---

P.S.: À la place de respectassent, j’avais initialement écrit respectaient… mais antidote RX m’a dit de l’écrire ainsi.

Sur une feuille de papier, "42" et 42 sont conceptuellement exactement identiques. C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique.

Bah, la différence, c’est que ta variable est var :
est différent de ou plutôt .

Et expliquer : « L’ordinateur est un peu stupide, il ne sait pas additionner un nombre de avec un nombre de … ». Les élèves comprennent. Àmha.

Je rejoins ceux qui disent que les fonctions préfixés nuisent à la compréhension. Un langage plus proche du langage naturel me semble mieux.

Néanmoins, il y a vers la fin de la page principale un système de boite permettant de faire de la programmation visuelle, un peu comme dans scratch. Je trouve ça pédagogique, quelqu’un sait-il si ça existe pour d’autre langage ?

Les IO j’ai à peu près compris (j’espère), mais je n’en suis pas là. J’ai lu Tutorial Haskell pour le développeur C et j’ai lu un peu plus de la moitié de Apprendre Haskell vous fera le plus grand bien ! j’ai fini le chapitre 9. Mais c’est dense, il me faut un peu de temps pour croire comprendre les concepts… je dois parfois relire plusieurs fois. Et j’ai surement oublié des trucs lus par manque de pratique.

Est-on obligé d’écrire : <int> ou le compilateur peut-il le déduire seul ?

Bon, j’ai essayé ce code :

// includes …
int main() {
  auto square = [](auto x) { return x * x; };
  auto twice = [](auto x, auto f) { return f(x) + f(x); };

  std::cout << twice(5,square) << std::endl;
  std::cout << twice(5.1,square) << std::endl;

  return 0;
}

Le but étant de vérifier comment il instancie les différentes versions en fonction des types.

Compilation :

$ g++ -std=c++11 main.cpp
main.cpp: In function 'int main()':
main.cpp:29:25: error: parameter declared 'auto'
   auto square = [](auto x) { return x * x; };
                         ^
main.cpp: In lambda function:
main.cpp:29:37: error: 'x' was not declared in this scope
   auto square = [](auto x) { return x * x; };
                                     ^
main.cpp: In function 'int main()':
main.cpp:30:24: error: parameter declared 'auto'
   auto twice = [](auto x, auto f) { return f(x) + f(x); };
                        ^
main.cpp:30:32: error: parameter declared 'auto'
   auto twice = [](auto x, auto f) { return f(x) + f(x); };
                                ^

…

Je ne suis pas un pro du C++11, quelqu’un pourrait m’expliquer ?

Je croyais qu’il fallait éviter les monades si possible pour faire du « pur »…

Sinon, pour square, quitte à définir la fonction sans paramètre, j’aurais écrit :

square :: Num a => a -> a
square = (^2)

Quand à ton deuxième code, j’ai du mal à comprendre l’avantage à part rendre obscur une fonction simple.

J’ai bien aimé la blague ;-) donc en C++ :

int twice(int x, int (*f)(int))
{
  return f(x) + f(x);
}

int main() {
  int (*square)(int) = [] (int x) { return x * x; } ;

  twice(5,square);

  return 0;
}

Avec des types génériques :

template <class T> T twice(const T& x, T (*f)(const T&))
{
  return f(x) + f(x);
}

template <class T> T square(const T& x)
{
   return x*x;
}

int main() {
  twice(5,square);   // Évalué à 50
  twice(5.0,square); // Évalué à 50.0

  return 0;
}

Je n’ai pas essayé à faire une lambda template. Les objets de type T pouvant devenir gros, j’ai décidé de passer les paramètres par référence, pour préciser au compilateur que l’objet ne serait pas modifié, j’ai ajouté const. Ce que je n’ai pas fait sur le premier exemple avec des paramètres par copie.

En haskell :

twice :: (Num a) => a -> (a -> a) -> a
twice x f = f x + f x

square :: (Num a) => a -> a
square x = x * x

Dans ghci :

Prelude> twice 5 square
50
Prelude> twice 5 (^2)
50

Les déclarations de type ne sont pas nécessaire, mais permette de garantir que la fonction prend un type numérique et retourne le même type. Fonctionne avec Int, Integer, Float, etc.

à part les extrémistes, il n'y a personne de "divisé".

Ouai, alors là, tu m’insultes… je suis dubitatif sur le projet en lui même pour différentes raisons, mais me traiter d’extrémiste, je trouve que tu y vas un peu fort.

Il semble confortable pour les « fan » de traité ceux qui ne suivent la sainte parole aveuglément de les traiter d’intégriste…

J’aurais tendance à dire qu’il faut regarder le pour et le contre. Mais c’est parce que je suis intégriste !

C'est quand la dernière fois que t'as eu une carte Ethernet qui ne fonctionnait pas directement

Pour moi, c’est quand j’ai passé ma femme sous GNU/Linux… carte mère qui fume, changement en urgence, elle avait un truc à faire pour le lendemain. Après les x redémarrage, pas de carte réseau, ni d’USB pour transférer les drivers depuis mon PC. Donc switch sous GNU/Linux.

C’est ce que fait img.linuxfr.org, si l’image disparait, elle reste dans le cache du site pour toujours. Si elle est modifiée, alors, la nouvelle apparaitra.

C’est ce que m’avait répondu quelqu’un sur un commentaire il y a un moment… je n’arrive pas à remettre la main dessus.

Je ne suis pas sûr de bien comprendre, donc je vais éviter de m'énerver, parce que mon incompréhension vient peut-être simplement du fait que tu ne sais pas t'exprimer de manière construite, mais… si je lis ce que j'ai cité, j'en déduis que tu crois qu'on ne peut
* ni ajouter de breakpoint à la volée
* ni modifier de variable à la volée
* ni faire du pas-à-pas

Non, ce n'est ni ce que j'ai dit, ni ce que je crois.

Dans quel monde tu vis ?

Dans un monde où les bancs industriels coûte cher, ils sont donc partagés. Donc quand tu as une après midi sur le banc pour faire tes tests, tu y restes coûte que coûte. Si tu trouves un bug rapidement à 14h30. Tu as deux choix, soit tu corrigse et recompiles, mais le temps de recompilation (4h) me donnera un nouvel essai dans, heu ben demain en fait. Sauf que le lendemain, je n'ai pas de créneau avant 16h.
Pour optimiser mon temps sur le banc, je recommence en « corrigeant » le bug dans le débugger. A ce point, j'ai deux choix, soit je contourne le bug à chaque fois manuellement (avec une interface graphique), avec gdb, je peux scripter cette partie et gagner du temps.

Il est possible qu'une bonne interface graphique de debug permette de scripter, mais je n'en connais pas.

Est-ce qu'avec ton gdb tu peux exprimer une condition pour activer ou non un breakpoint (genre "arrête-toi ici seulement si ceci et cela" en ayant accès à toute l'expressivité de groovy et même ta logique métier) ?

Oui.

Est-ce que tu peux sélectionner une ligne de ton programme et cliquer/taper le raccourci clavier "j'ai pas mis de breakpoint mais relance le flot d'exécution jusqu'à cette ligne peu importe ce qu'il se passe" ?

Je ne suis pas sûr de comprendre le « peu importe ce qu'il se passe ».

Est-ce que tu peux abandonner le contexte courant ("drop frame" dans IntelliJ, désolé flemme de chercher mieux) en revenant au début de ta méthode et en remettant tout le contexte (variables, paramètres, etc.) dans l'état où il était au début histoire de revoir ce qu'il se passe ?

Je ne sais pas le faire, mais il me semble que gdb sait faire depuis quelques versions.

Moi j’ai eu des cas, ou tu as du matériel de test pendant 4h. Tu trouves un premier bug, mais si on le corrige, il y a 5h de recompilation… donc, pouvoir scripter un test, ajouter un breakpoint, modifier une variable avancer de 5 instructions, remodifier une variable, pour enfin être prêt à trouver un deuxième bug… et bien je suis content que gdb soit en ligne de commande, qu’on puisse lui passer des scripts, etc.

Après, pour des softs avec IHM, un débogueur en IHM aussi peut suffire.

Tu sais, dans l’industrie, j’ai des clients qui nous demande encore visual 6… alors tu sais…

Pour ton information, kdevelop, qtcreator, emacs sont très bien, font de la très bonne complétion. Kdev te propose même les inclusions. Visual a aussi pas mal progressé que ce soit au niveau du compilateur comme de l’IDE… mais personnellement, pour faire des remplacements, compilation… je préfère une ligne de commande. C’est juste une question de gout et d’habitude.