lasher a écrit 2743 commentaires

Et pour moi ce n'est plus du « vrai » C++. Normalement, comme il a été dit plus haut, on utilise des mots-clef explicites pour tout ce qui est transtypage. À ce moment-là, le compilateur C++ est censé être capable de dire « non » quand le transtypage est illégal.

Euh. En pratique, il inline les accesseurs, si pour lui il n'y a aucune ambigüité. Il garde la définition de la classe, mais il l'inlining est opéré à divers niveaux par le compilateur (et heureusement, parce que le coût d'un appel de fonction dans une boucle qui itère plusieurs milliers de fois, juste pour récupérer la valeur d'un attribut ...).

Je vais faire mon vieux con ©. Un profane qui ne programme pas sur sa machine ne devrait pas avoir à y installer un compilateur, ne serait-ce que d'un point de vue sécurité : compiler un rootkit quand le compilateur est déjà accessible est quand même bien plus facile que s'il faut d'abord faire tout un tas de contorsions pour récupérer les droits root.

Pour le coup du « bleeding edge », je n'y crois pas du tout : par définition, sauf à avoir vraiment blindé le programme pour pouvoir s'installer partout (et à ce moment-là, s'agit-il encore de « bleeding edge » ?), il y a *toujours* un risque de plantage lors de la compilation. Et ton utilisateur, il se retrouve toujours très bête.

Tu viens de répondre toi même : l'utilisation de generics est là pour ça : application de modèles typés statiquement.

Qu'est-ce qui est imposé ? Le référendum ? Le gouvernement n'était pas obligé de le faire, à ma connaissance ; il aurait tout à fait pu donner sa réponse sans en appeler au peuple.

Une fois que tu poses la question, évidemment, il faut fournir le texte à propos duquel on doit donner son avis. Mais c'est se foutre de la gueule du monde de donner un texte comme ça à évaluer à des gens qui ignorent tout ou presque des institutions européennes pour une grande partie (non négligeable). Bref, si tu veux demander son avis au peuple, tu lui donnes un texte qu'il est capable de comprendre, et tu t'y tiens. C'est en cela que j'ai trouvé l'utilisation d'un référendum très démagogique [1], car en fait (pour me répéter), cela s'apparente plus à un plébiscite gaulliste.

[1] Là encore, pour ceux qui voudraient y voir une orientation quant à mon vote, retenez-vous de penser quoi que ce soit à ce sujet, je ne fais que critiquer une démarche, et je ne donne aucune opinion quant au contenu du TCE en lui-même.

C'est marrant, pour une bonne partie des gens que je connais qui ont voté non, finalement, ça revenait presque au même.

Bon, je vais passer outre le ton condescendant.

Déjà, il semblerait que tu aies décidé pour moi ce que j'ai voté (j'ai pourtant bien fait attention à ne pas laisser d'indice sur ce que j'ai effectivement mis dans l'urne, car pour mon post précédent, ça n'avait aucune importance). Fais attention, tu risquerais d'être surpris.

Lorsque je dis que je me fiche des textes précédents, c'est en rapport avec le côté complexe de la chose. Faire un référendum concernant un texte complexe, difficilement intelligible, c'est débile, car le référendum devient une sorte de "plébiscite", et pas une vraie demande d'opinion (vu que 80% de la population est incapable de comprendre le texte brut).

Et donc, n'ayant pu voter pour les textes précédents, et ceux-ci étant en application de toute manière, la seule question qui se posait pour moi était : "qu'est-ce que je comprends à ce texte ? où trouver des informations qui puissent me permettre d'y piger quelque chose vu que manifestement, il n'est pas rédigé à mon intention, et qu'on me demande mon avis quand même ?". Pour Maastricht, la question ne m'était pas posée, et de toute manière j'aurais été bien incapable de répondre à l'époque.

Oui, répondre "non" ou "oui" au TCE signifiait garder les textes existants ou pas. N'empêche : je maintiens qu'on me demandait mon avis sur ce texte-là en premier. Les répercussions, ce sont des réflexions de deuxième plan. Pour être plus clair : je devais d'abord me demander si ce texte-là me plaisait (et ça m'a bouffé un temps pas possible). Ensuite, j'ai regardé les conséquences, et franchement, j'avais plus le temps de mater et essayer de comprendre par moi-même les textes précédents, mais comme de toute manière les pour et les contre semblaient d'accord pour dire que le TCE unifiait la plupart des textes déjà en application, le fait que ces derniers avaient été écrits dans une langue absconse m'était (et m'est toujours, d'ailleurs) relativement indifférent.

La question était donc pour moi de savoir si oui ou non, ce qu'apportait le TCE m'intéressait ou pas. Et ensuite, j'ai voté.

s/disait/aurait pu dire/

( Et comme disait Fucius - oui ben vous marrez pas, il avait oublié d'être con ! -, comme disait Fucius, "une civilisation sans la science est aussi absurde qu'un poisson sans bicyclette" )

On élit un président entre autres pour ses idées (dans le cas de 2002, c'était particulier, certes). Je ne trouve pas choquant que Chirac ait donné son opinion concernant le TCE. Il a dit que selon lui c'était important et qu'on risquait gros à ne pas le faire, et pourtant, au final, le non l'a emporté. Comme quoi, il a pu donner son avis de chef d'état (qui est franchement plus qualifié que le tiens ou le mien), mais a laissé la liberté au peuple de donner son avis. Je ne vois pas où est le mal.

Honnêtement, les textes précédents, je m'en fiche un peu, je n'étais pas majeur pour voter pour ou contre. Je ne sais pas si celui à qui tu réponds a eu le même problème, mais je trouve qu'en ce qui me concerne, ça explique pourquoi je ne parle pas trop des autres traités. :-)

Par contre, les textes récents, je suis assez grand pour m'apercevoir qu'ils sont assez indigestes. Heureusement que j'ai pu lire plusieurs analyses différentes à côté pour pouvoir me faire une opinion et m'éclairer un peu sur le texte que je lisais (j'avais écrit tout plein de '?' dans les marges là où je ne pigeais pas), sinon j'aurais été bien incapable de faire un choix. Et même comme ça, j'ai hésité jusqu'au dernier moment.

D'un autre côté, ajouter une dépendance à python est loin d'être négligeable. Et si c'est fait en C, c'est sans doute aussi dans une optique de performance (et pour ce qui est de l'indexation, c'est à mon avis important) ; même si python n'est pas non plus un boulet dans le domaine, il est quand même un sacré facteur limitant dans cette optique.

Il a pas parlé de liberté, mais d'ouverture. Faudrait arrêter d'interpréter tout ce qui est dit comme ça t'arrange, ça devient fatiguant à la longue (je suis d'extrême mauvaise foi moi-même, mais j'essaie de ne pas déformer les propos qui me sont tenus).

continu comme ça, c'est super agréable à utiliser après (je n'utilise plus que ça depuis 2 mois déjà)

continu -> continue

Attention...

Moi j'ai toujours cru que c'était dans les tables de la loi, juste à côté des 1090139 exceptions à cette règle, écrites dans l'ancien testament.

Non.

Oui, mais l'auteur dit qu'elles semblent au premier abord équivalentes, alors qu'une des valeurs est incluse dans l'un ou l'autre groupe en fonction de la comparaison effectuée. C'est en ça que je trouve bizarre sa façon de présenter les choses.

« Quand est-ce que les gens comprendront que la complexité est une notion mathématique faisant appel à des concepts d'infinis qui n'existent pas en informatique ? »

On t'a déjà répondu en partie, mais juste pour préciser : j'ai fait exprès de parler de complexités spatiale et temporelle ; il y a bien une notion « physique » dans ces deux types de complexité.

Ensuite, une fois qu'on a un algorithme qui dans le cas général est correct, il faut encore se pencher sur une implémentation efficace.

Oui, il existe des cas où la complexité théorique n'est pas si importante. J'ai en tête un exemple assez frappant :
1°) Pour pouvoir mettre sous forme SSA un programme ( http://en.wikipedia.org/wiki/Static_single_assignment_form ) il faut construire des frontières de domination (dominance frontiers en Anglais). Il existe un algorithme, avec une complexité théorique qui pour le moment n'a pas été améliorée (ou alors juste ses constantes).
2°) Les auteurs d'un papier ont mis au point un algorithme ayant une complexité théorique moins bonne, mais
3°) La différence de complexité n'entre réellement en compte que lorsque le graphe de flot de contrôle (CFG, Control Flow Graph) totalise plus de 30 000 noeuds.
4°) Ça n'arrive presque jamais (en fait, je n'ai jamais vu un cas pareil, mais mon expérience de l'informatique est très petite).
5°) L'algorithme des auteurs est beaucoup plus simple à mettre en oeuvre
6°) Les auteurs de l'article ont tripatouillé à mort leurs structures de données

Résultat : en pratique, tant que les CFG sont en dessous de 30 000 noeuds, ils ont un algorithme qui va plus vite que les implémentations connues de l'algo classique, et qui, étant plus simple dans son énoncé, risque moins d'être sujet à bugs pour sa mise en oeuvre.

Dans cet exemple, on touche directement à la limite séparant la recherche de l'ingénierie. L'ingénierie concerne l'optimisation des structures de données ; la recherche la mise au point de l'algo ; le flou concerne le fait qu'on prend en compte la complexité, tout en faisant attention aux cas réels.


D'autre part, la complexité n'est pas qu'un outil mathématique. Elle donne des bornes, ce qui est très important pour l'implémentation. À quoi bon implémenter un algorithme de complexité O(m^n), par exemple ? Ou mieux : lorsqu'on demande à quelqu'un d'effectuer une tâche, et que ce quelqu'un parvient à démontrer que le problème donné à résoudre est NP-complet [1], il est temps de reformuler le problème, pour le circonscrire un peu plus. Je réagis assez vivement parce que tu donnes l'impression de croire que l'informatique théorique n'est que de la masturbation intellectuelle ; or ce n'est clairement pas le cas [2].

Quand on parle d'algorithmes répartis, par exemple, tu as intérêt à être sûr que ton algorithme converge, sinon tu vas au devant de grosses surprises. Là encore, les « maths » aident beaucoup (même si maintenant il existe tout un tas d'outils sympa pour aider l'infoteux à se dépatouiller de tout ça).

[1] Oui bon, OK, non seulement ça n'arrive pas tous les jours, mais en plus, ça prend du temps de le démontrer correctement.
[2] Y'a des exceptions, comme toujours. ;-)

Oui oui oui. Bien sûr. Évidemment. Tout est blanc ou noir, amen.

Ah oui tiens, soit dit en passant, tiré du blog du monsieur en question (qui effectivement est intéressant) :

1. x < y ? x : y
2. x <= y ? x : y
3. x > y ? y : x
4. x >= y ? y : x

Chez moi, l'expression 1. et l'expression 2. n'ont absolument rien d'équivalent, idem pour 3. Vs 4. Ça n'empêche pas le reste de son article d'être intéressant, mais c'est quand même un peu bizarre ...

Concernant les normes, ça m'intéresse !
Parce que icc -Wall est bien plus (trop ?) verbeux que gcc, au point que c'en est gênant.

Ben c'est pas dur, y'a que deux règles pour l'optimisation :

1°/ On n'optimise pas.
2°/ (pour experts seulement) On n'optimise pas encore.

Blague à part, effectivement, les compilateurs optimisants sont plutôt assez bien fichus de nos jours, et un bon algo restera en général bien plus efficace qu'une micro-optimisation locale. Il y a des exceptions, bien entendu.

Pour répondre à un commentaire vu plus haut concernant les histoires d'optimisation pour les caches, etc.. Si on prend la bibliothèque MKL (Math Kernel Library) d'Intel qui a été optimisée aux petits oignons et tout, on s'aperçoit que les défauts de cache, on s'en fout. Elle en fait plein, plus que des bibliothèques justement étudiées pour les minimiser. En contrepartie, elle fait plein de préchargements intelligents.

C'est ça le gros problème de l'optimisation : on cherche à améliorer la localité ? Très bien, on améliore. Mais on oublie que les défauts de cache sont parfois peu important vis à vis d'autres facteurs (un défaut de TLB par exemple est souvent bien plus déterminant qu'un défaut de cache L2). Ou bien on se rend compte que tout bêtement, un compilateur donné ne sait pas correctement dérouler des boucles un peu irrégulières, et qu'il suffit de le faire à la main pour gagner 20 à 30% de performances (déjà expérimenté sur icc version Itanium). Mais là, on se rend dépendant d'un compilateur donné.

Donc toute la difficulté est dans le compromis portabilité du code/portabilité des performances/optimisations spécifiques, et franchement, avant d'en arriver à ce genre de choses, je pense que bien définir ses structures de données et ses algorithmes est sacrément plus important.

C'est vrai, mais comme nous disait mon prof d'architecture des ordis : les processeurs haute performance, mis à part le calcul scientifique et les jeux vidéos, personne n'en a besoin. C'est pour ça que je n'ai pas abordé ces deux domaines qui sont très particuliers.

Le truc, c'est que jusqu'à il y a peu, c'était plutôt les boites qui disaient « entre payer une équipe de programmeurs pour optimiser un logiciel [qui en plus pouvait être proprio] et acheter des machines plus puissantes, la deuxième solution est plus économique ».

J'ai aussi des exemples dans le domaine du calcul scientifique, mais ça commence à devenir un peu trop ciblé.

Je suis d'accord dans l'ensemble concernant l'optimisation du code, mais ...

... Mais les gens oublient qu'à partir du moment où on optimise, on perd le plus souvent en lisibilité du code ; que tout le monde n'a pas le même niveau en programmation ; que beaucoup de code produit (et jeté) provient de stagiaires qui par définition ne sont pas encore rôdés [1]; etc.

Si on a pu démultiplier ainsi le nombre d'applications complexes, c'est grâce en grande partie à la réutilisation de composants, de bibliothèques, etc., car c'était plus simple pour des programmeurs moins expérimentés de construire au-dessus des briques de base pas toujours évidentes à faire. Mais ce faisant, et l'abstraction aidant, beaucoup de programmeurs (surtout débutants, je souligne) ignorent de quoi sont faites les briques sur lesquelles ils s'appuient (nombre de programmeurs Java - mais c'est valable pour tout autre langage avec une bibliothèque aussi importante - ne mesurent pas toujours les conséquences d'utiliser un ArrayList plutôt qu'un TreeMap plutôt que ... en termes de complexité spatiale et temporelle).

Moralité : oui, il faut essayer de faire attention à ne pas faire n'importe quoi, pour que ça tourne au mieux, mais il faut faire aussi attention aux excès de zèle.

[1] Il y a toujours des exceptions, bien sûr.

Lorsque j'étais minuscule (vu que je suis toujours petit, il faut changer d'échelle), j'avais un ordinateur-jouet, qui me servait à faire du calcul mental, de la grammaire et de l'orthographe, principalement (y'avait aussi un module sonore pour « composer » d'atr^Wd'amusants morceaux grâce au doux son du buzzer, et quelques autres trucs).

C'était déjà assez lourd pour moi à 5 ou 6 ans, je me vois mal trimballer un ordinateur de pièce en pièce (car n'oublions pas qu'il s'agit d'un jouet avant tout) avec une caisse en bois...

Moi j'aimerais connaître le rapport direct avec le post auquel tu réponds.