Discussion :

[_skip]

On le vérifie alors immédiatement en version non-optimisée, pour voir si l'erreur provient du code (=ça fait pareil en non-optimisé), ou de l'optimisation (=ça marche en mode non-optimisé).

Et vous tombez sur des cas où l'optimisation pratiquée par le compilateur est la cause? Perso j'ai toujours considéré ce genre de chose comme assez sûre, plus que mon code bien souvent.

[Alakazam]

Écrit comme ça, oui. Mais si tu fais ça, tu fais mal tes boucles, la bonne manière est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
taille = tableau.size ;
for (i = 0; i < taille; ++i) { ... }

Ce qui rend la taille du tableau constante au niveau de la boucle... Sinon, elle serait réévaluée à chaque itération, tout comme elle le serait avec un foreach.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
taille = tableau.size;
for (i = 0; i < taille; ++i) {
  tableau.pop();
}

Oups.

[jabbounet]

Et vous tombez sur des cas où l'optimisation pratiquée par le compilateur est la cause? Perso j'ai toujours considéré ce genre de chose comme assez sûre, plus que mon code bien souvent.

j'ai déjà rencontré des cas ou l'optimisation faite par le compilateur produisait des effets indésirables lors de l'exécution, cela fait longtemps que je ne fais plus d'embarqué mais j'ai déjà vu.

et pour revenir sur le sujet de l'optimisation du code (ce qui implique parfois du refaire certaines parties).
La première étape est d'avoir un code qui marche et une suite de test qui valide que l'on introduit pas de régression pendant l'optimisation.(enfin quand c'est fait sérieusement)

[Mac LAK]

Deux mondes qui méritent de coexister je pense...

Les deux coexistent, mais pas aux mêmes niveaux ni dans les mêmes "niches". Je suis le premier à dire que faire une IHM autrement qu'avec un RAD est stupide et chronophage... Elle n'a pas besoin de performances d'affichage fulgurantes, ce n'est pas un jeu. Si un code de traitement "lourd" doit être fait, les threads et les DLL compilées avec un langage optimisé sont là.

C'est juste qu'un langage de haut niveau permet de se décharger d'un certain niveau de détail, ce qui amène plus de sécurité et facilite la maintenance.

Attention : cela amène une certaine forme de sécurité, qui n'est pas toujours la même chose que la sûreté de fonctionnement...

Faut juste savoir jusqu'à quel point on peut s'appuyer dessus car les limites existent et arrivent parfois vite.

J'ai donné l'exemple un peu plus haut de telles limites, et pourquoi augmenter le matériel n'est pas toujours possible.

Et vous tombez sur des cas où l'optimisation pratiquée par le compilateur est la cause? Perso j'ai toujours considéré ce genre de chose comme assez sûre, plus que mon code bien souvent.

Depuis que je travaille, j'ai eu les cas suivants :

• Une bonne dizaine de bugs d'implémentation de la librairie standard C ou C++.
• Une demi-douzaine de bugs en phase d'optimisation du compilateur, notamment liés à des spécificités dans certaines versions embarquées des CPU par rapport à la version "bureau" de référence.

Bref, des choses normalement "fiables", en qui on a "confiance"... Confiance justifiée dans 99.99% des cas. Sauf qu'à force de pousser une machine et un langage dans ses derniers retranchements, on finit par tomber sur le 0.01% restant...

Oups.

Tu peux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
taille = tableau.size;
for (i = 0; i < taille; ++i) {
  consommer(tableau[i]);
}
tableau.drop_from_head(taille) ;

"pop()" ? Fonction de feignant pour éviter la copie manuelle, c'est ça ?
Ce genre de chose n'est possible QUE si l'on maîtrise chaque étape, notamment les modifications de l'environnement de la fonction. Bref, que l'on maîtrise les effets de bord... Ce qui est rarement possible si on laisse des primitives et/ou des instructions complexes faire le boulot à notre place.

[jabbounet]

Autre principe que j'ai souvent vu

Si quelqu'un pense qu'une connerie peux se produire dans un cas d'utilisation du logiciel, on peu être certain que cela arrivera si on ne fait rien pour la prévenir.

[Alakazam]

Tu peux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
taille = tableau.size;
for (i = 0; i < taille; ++i) {
  consommer(tableau[i]);
}
tableau.drop_from_head(taille) ;

"pop()" ? Fonction de feignant pour éviter la copie manuelle, c'est ça ?
Ce genre de chose n'est possible QUE si l'on maîtrise chaque étape, notamment les modifications de l'environnement de la fonction. Bref, que l'on maîtrise les effets de bord... Ce qui est rarement possible si on laisse des primitives et/ou des instructions complexes faire le boulot à notre place.

Tu veux dire, réutiliser du code, et éviter de réinventer la roue ?

[Mac LAK]

Tu veux dire, réutiliser du code, et éviter de réinventer la roue ?

Bienvenue dans le monde merveilleux du bas niveau, où la réinvention de la roue est parfois nécessaire pour garantir les performances attendues (perfs au sens large, inclus le footprint donc)...

[CedricMocquillon]

Bref, des choses normalement "fiables", en qui on a "confiance"... Confiance justifiée dans 99.99% des cas. Sauf qu'à force de pousser une machine et un langage dans ses derniers retranchements, on finit par tomber sur le 0.01% restant...

il est évident (à la vue de tes précédents posts) que tu travailles dans un domaine pour lequel l'optimisation est cruciale, cependant cela représente 0.01% () des développements informatiques, de nombreux projets pour lesquels les performances sont importantes n'ont pas de contraintes aussi extrêmes. Il serait bien que tu arrives de temps en temps à te détacher légèrement de ton expérience perso (qui est utile pour illustrer tes arguments mais à haute dose ça laisse l'impression que tu n'arrives pas forcément à prendre en considérations les autres cas que le tiens)

Tu peux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
taille = tableau.size;
for (i = 0; i < taille; ++i) {
  consommer(tableau[i]);
}
tableau.drop_from_head(taille) ;

"pop()" ? Fonction de feignant pour éviter la copie manuelle, c'est ça ?
Ce genre de chose n'est possible QUE si l'on maîtrise chaque étape, notamment les modifications de l'environnement de la fonction. Bref, que l'on maîtrise les effets de bord... Ce qui est rarement possible si on laisse des primitives et/ou des instructions complexes faire le boulot à notre place.

Je ne comprend pas bien l'idée (si ce n'est d'embrouiller les choses) d'utiliser un for pour "émuler" le comportement d'une liste FIFO. Relire un tel code serait à mon avis source de bugs pour quelqu'un n'ayant pas saisi l'idée de l'"émulation".

[jabbounet]

Cela rejoint un peu ma remarque précédente, il est évident (à la vue de tes précédents posts) que tu travailles dans un domaine pour lequel l'optimisation est cruciale, cependant cela représente 0.01% () des développements informatiques, de nombreux projets pour lesquels les performances sont importantes n'ont pas de contraintes aussi extrêmes. Il serait bien que tu arrives de temps en temps à te détacher légèrement de ton expérience perso (qui est utile pour illustrer tes arguments mais à haute dose ça laisse l'impression que tu n'arrives pas forcément à prendre en considérations les autres cas que le tiens)

il m'est aussi arrivé de trouver des bugs de compilation sans faire de l'embarqué.
le compilateur (gcc, javac, aCC, Forté, ....) ne sont que des softs parmis d'autres, il contiennent donc aussi des bugs.

le souci c'est que quand cela arrive ce n'est pas simple a identifier, et parfois tu le contourne en faisant autrement (modification d'algo en te disant que tu as fait une connerie) ou en essayant de debugger ton programme.

[alex_pi]

Non, il fait ce qu'il peut faire. Mais il ne peut absolument pas faire ce qui est du ressort du contexte d'exécution, notamment au niveau concurrence.

Les trucs où tu expliques "il ne faut jamais utiliser de foreach, parce que c'est buggé, et en plus il y a des cas où ça ne marche pas" ? Mmmh. Ouais, mais alors

1. Je reste persuadé qu'il y a vachement moins de risque de trouver un bug dans UNE implémentation ferme et définitive du foreach que dans les 5000 boucles d'un code où on a réimplémenté à la main sa sémantique
2. Ce n'est pas parce que ce n'est pas adapté à *tous* les cas que ça retire quoique ce soit au fait que c'est *effectivement* adapté dans *plein* de cas.

Et pourtant si : un "for" ne provoquerait pas de boucle infinie. Et une boucle infinie, si c'est dans un thread temps réel, ça fait très mal.

Tu as oublié de répondre à la partie "et si ton autre thread vire des éléments, ce qui est proprement capturé par le foreach, mais ce qui fait planter le for". Et il parrait qu'un comportement non défini, y a même pas besoin de "thread temps réel" pour que ça fasse mal



C'est vrai que quand on voit des discussion de plusieurs dizaines de mails sur la mailing list du noyau linux pour décider si oui ou non il est safe de virer une barrière dans un bout de code d'un spin lock, quand on lit les articles par exemple de Simon Peyton Jones dans "Beautiful code" sur le difficulté de la programmation parallèle, quand on voit le nombre de bug dans les softs dus à des erreurs de syncro entre les threads, quand on voit le nombre de tentative de proposition d'outils pour la programmation parallèle, etc.

Si les problèmes de préemptions et de sections critiques doivent être portés sur des processeurs à plusieurs dizaines, centaines, milliers de coeurs, il risque de vraiment devenir urgent de leur donner ces solutions !

Bref, c'est de la "simple" génération de code, ça reste du C/Ada derrière et non pas, tu l'auras noté, une traduction directe en code machine directement depuis le code Lustre...

Va leur dire chez Esterel technologie qu'ils ne font que de la "simple génération de code" Ca va leur faire plaisir :-D

Ce que j'ai écrit : quand tu veux un footprint minimal et/ou des performances maximales, le bas niveau est toujours plus adapté.

Et ça sort d'où ça ? Comment des gens arrivent à écrire des contrôleurs de moteur hybrides en Haskell (http://cufp.galois.com/2008/abstracts.html#HawkinsTom)? Comment des gens arrivent à programmer des réseaux de centaines de capteurs en quelques lignes avec des langages fonctionnels de super haut niveau (http://fiji.eecs.harvard.edu/Macroprogramming) ? Comment des gens torchent-ils complètement toutes les implems concurrente de transformation XML alors qu'ils sont écrits dans des langages fonctionnels (http://gallium.inria.fr/~frisch/xstream/bench.html) ? Comment des gens arrivent-ils à se servir de milliers de machines en même temps pour effectuer des tâches complexes en quelques lignes de codes (http://labs.google.com/papers/sawzall.html) ?

les abstractions, les systèmes de types poussé, les GC, la fiabilité du code, etc. leur ont permis de ce concentré sur les parties importantes.
Alors, oui, ces gens là sont aussi capable d'écrire un runtime ou une machine virtuelle en C, de coder quelques fonctions ou boucle super serrées dans un langage bas niveau. Mais ils sont surtout capable de comprendre que ces parties là se doivent d'être réduite, confinées, et surtout, minoritaire.

Mais je ne me fais pas d'illusion va, je sais très bien que l'on va continuer pendant encore de longues années à avoir des programmes qui crachent à tout va, que les multi-coeurs resteront totalement sous-exploités pendant un bon bout de temps, etc.

[nprovost]

Ce qui me surprend un peu dans la discussion c'est que je ne vois pas pourquoi lorsqu'on écrit un foreach dans un code, on n'aurait pas conscience de problèmes potentiels et effets de bord ? C'est pas ça coder, aussi ?

D'où l'intérêt de connaître des langages de haut ET bas niveaux !

Sinon des bouts de codes corrects qui ne passaient pas à l'exécution pour des raisons inconnues (compilation), ça m'est arrivé aussi.

[alex_pi]

Sinon des bouts de codes corrects qui ne passaient pas à l'exécution pour des raisons inconnues (compilation), ça m'est arrivé aussi.

Corrects ? Dans 90% des cas, les bugs qui apparaissent à un degré plus grand d'optimisation (enfin, en -O2 pour gcc. Au delà, ça devient dangereux) sont uniquement des trucs classiques genre dépassement de bornes qui n'avaient pas de conséquences néfaste dans le code moins optimisé par pure chance.
Et dans les 10% restant, 90% est du à une incompréhension de la sémantique du C (surtout des parties "non définies"), et donc des optimisations que le compilo a effectivement le droit de faire.

[nprovost]

Corrects ?

Un ou deux cas pour lesquels je suis certain que le code était correct et seul un changement de l'algorithme a résolu la chose. Dans les autres cas je finis par m'autoflageller.

[souviron34]

j'ai déjà rencontré des cas ou l'optimisation faite par le compilateur produisait des effets indésirables lors de l'exécution, cela fait longtemps que je ne fais plus d'embarqué mais j'ai déjà vu.

Absolument

Corrects ? Dans 90% des cas, les bugs qui apparaissent à un degré plus grand d'optimisation (enfin, en -O2 pour gcc. Au delà, ça devient dangereux) sont uniquement des trucs classiques genre dépassement de bornes qui n'avaient pas de conséquences néfaste dans le code moins optimisé par pure chance.

-O3 est en général une catastrophe pour tout algo un peu "sioux".. même si le code est "parfait" (i.e. zéro bug). Essaye de compiler une génération de MPEG (avec le code fourni sur le site officiel) avec -O3...

-O2 donne globalement de bons résultats..

[jabbounet]

toutes les grandes entreprises d'informatique posent des questions d'algorithmique pendant leurs entretiens. Pourquoi ? Parce que c'est ce qui fait le plus défaut aux informaticiens de nos jours.

personellement, je n'ai jamais eu de questions d'algorithmie (sauf quand j'ai débuté dans ma première boite, et encore je ne suis pas sure), j'ai du me planter dans mes recherches

Etre capable de coder dans un langage bas niveau ? Bien sûr que c'est important. Mais c'est tout à fait possible à apprendre sur le tas quand on connait un langage haut niveau et qu'on a une connaissance sommaire de son fonctionnement sous le capot.

je rencontre souvent des jeune développeur qui ne savent pas forcement ce qu'il y a sous le capot et qui après son surpris de la lenteur de leur application. et parfois rien qu'en regardant l'archi et les algo qu'ils ont pondu, je ne suis pas vraiment surpris (quelque soit le langage), tout ça rien que parce que j'ai conscience de ce qu'il se passera en dessous et des tortures qu'ils vont infliger au système (mais cela s'appelle aussi l'expérience chez certains).

Etre capable de pondre de très bons algos qui n'ont pas une complexité exponentielle ? C'est bien plus important encore. Ton algo exponentiel en C, même sur-optimisé, il aura du mal à battre un algo en n log(n) en java... Et malheureusement, à en croire les entreprises, c'est ce point là qui fait bien plus défaut aux informaticiens d'aujourd'hui. Et il est également beaucoup plus dur à apprendre sur le tas pour qui n'a jamais fait d'algorithmique.

Apres il faut bien choisir le typage des données dans ton algo, parfois un mauvais typage (des personnes n'arrêtant pas de manipuler des string la ou un entier ou u booleen suffirait) par exemple font que même les meilleurs algo du monde se mettent a ramer.

l'algorithmique permet des gains de performances incomparables aux petites optimisations spécifiques à un langage.

je suis d'accord, la dessus. a condition que la personne faisant les algo ait un minimum de bon sens et de pragmatisme, et sache faire des choix judicieux quand aux données qu'il a a traiter.

Quand tu postules dans une entreprise d'informatique assez généraliste, on veut savoir si tu es capable de sortir de bons algos.

[j.p.kopf ON] hum le bon algo fait maison par un artisant, on en trouve plus des comme ça, avec l'industrie moderne et tout ces framework tout fait que l'on ne sais pas ce qu'il y a dedans...[j.p.kopf OFF]

Si tu ne connais du tout le langage utilisé c'est pas grave, on sait que si t'es bon en algo le reste tu peux l'apprendre sur le tas assez facilement.

L'algorithmique c'est justement la seule partie de l'informatique qu'il est très difficile d'apprendre en dehors de l'école (et je parle bien d'apprendre à trouver des algorithmes efficaces dans n'importe quelle situation, pas d'apprendre par coeur des algorithmes connus), et c'est aussi la plus complexe et la plus importante.

non ce n'est jamais grave de ne pas connaitre un langage, mais avoir un minimum de connaissance système ça évite de grosse connerie dans tes choix d'implémentation (quelque soit le langage)

[Alakazam]

les résultats obtenus (par exemple sur de l'embarqué spatial : sondes lunaires, navette spatiale) sont impressionnants, mais à condition de ne pas sacrifier en sécurité, il me semble évident qu'il faut s'orienter vers plus de facilité pour les développeurs.

Ne pas réinventer la roue, réutiliser du code, des outils d'analyse statique, de tests automatisés, des boucles foreach ou de la gestion automatisée de la mémoire, sont des choses qui accélèrent forcément les développements. De la même façon qu'un programme modulaire est plus simple à maintenir, une approche par couches de la partie langage, en déléguant à des couches plus basses la gestion de problématiques indépendantes de la fonction du logiciel (les algos de tri, de parcours de graphes, de gestion de pile, l'allocation mémoire, etc.) me semble tout à fait pertinent.

C'est pourquoi utiliser des langages tels qu'Haskell, Erlang ou Lustre (utilisé dans SCADE) est pertinent. Ca ne consiste pas à dire "l'existant est nul", mais plutôt "les ordis, c'est plus rapide, efficace, et ça fait moins d'erreurs que les hommes".

C'est tout simple : si le compilateur a une erreur dans son implantation du foreach, il suffit de la corriger une fois, et l'erreur disparaît partout. De plus, comme le compilateur est un soft "simple" (en termes de portée des fonctionnalités du logiciel), il est possible d'avoir une couverture de tests unitaires et fonctionnels automatisée presque complète, et donc de s'assurer que la correction de la boucle foreach n'introduit pas une régression ou un nouveau bug.

A l'inverse, si les développeurs ont en charge de redévelopper la boucle foreach à chaque fois (avec bien entendu des conventions de code pour qu'elles se ressemblent toutes), il y a possibilité d'erreur à chaque fois. Et si la convention de code ne convient plus, il faut changer le code partout. Je ne vois vraiment aucune raison de prétendre que réinventer la roue est une bonne idée.

DRY est un principe essentiel en informatique.

[Mac LAK]

la plupart des systèmes de sécurité sont des éléments embarqués, programmés en bas niveau, et non pas des systèmes formels "théoriques"... La preuve formelle est indéniablement utile, je ne l'ai jamais contesté. Toutefois, je préfère quand même que les équipements de sécurité soient "collés" au matériel, et puissent agir dessus sans entraves, plutôt qu'ils soient tributaires d'un programme "parfait", mais appuyé sur une chaîne logicielle plus ou moins maîtrisée (VM, runtimes, etc.)...

Après, à toi de voir si tu veux par exemple un système d'aide à la survie qui coûte 1000 euros, programmé en bas niveau et fiable à 99.999%, ou le même en haut niveau à 2000 euros et fiable à "seulement" 99%... Le matériel coûte cher, et le haut niveau en réclame bien plus que le bas niveau. Et plus un matériel est complexe, plus son MTBF baisse.

Cela rejoint un peu ma remarque précédente, il est évident (à la vue de tes précédents posts) que tu travailles dans un domaine pour lequel l'optimisation est cruciale, cependant cela représente 0.01% () des développements informatiques

C'est justement la grosse erreur de la plupart des gens... Pour le citoyen lambda, le "bas niveau", c'est le driver de sa carte vidéo et, éventuellement, son OS s'il sait vraiment ce que c'est du moins.
Mais ceci, ce n'est que la partie émergée de l'iceberg, ce que tout le monde voit. L'embarqué, et les performances requises de tels systèmes, c'est totalement omniprésent dans notre vie de tous les jours, c'est simplement "caché", on ne s'en rend même plus compte en fait.
Cela recouvre aussi bien l'embarqué "temps réel" (ou pire, "temps critique") que tu vas trouver à la pelle dans ta voiture, que l'embarqué "pas cher" de ton micro-onde ou de ta machine à laver (footprints minimums), ou que les calculateurs d'à peu près tous les moyens de transport que tu peux être amené à utiliser un jour, même un bateau à voiles... A cause de son GPS !
C'est aussi la plupart des appareils médicaux à l'hôpital, la totalité des communications possibles (téléphone, radio, télévision, satellites), et j'en passe.
Si ça, c'est "0.1%" du développement, alors il faut que l'on change de planète : la nôtre va s'effondrer sous le poids des mainframes...

de nombreux projets pour lesquels les performances sont importantes n'ont pas de contraintes aussi extrêmes.

Question bête : ils s'appuient sur quoi, d'après toi, ces projets ? Sur des drivers, des cartes accélérées, des systèmes qui utilisent le moins de CPU possible pour le maximum de puissance... Ben oui, si ta carte réseau ne te "coûte" presque rien à utiliser, il y a une raison sous-jacente, tu sais : quelqu'un en a optimisé le code...

Je ne comprend pas bien l'idée (si ce n'est d'embrouiller les choses) d'utiliser un for pour "émuler" le comportement d'une liste FIFO. Relire un tel code serait à mon avis source de bugs pour quelqu'un n'ayant pas saisi l'idée de l'"émulation".

D'une part, il est évident (et ce n'est pas dans l'exemple ci-dessus) qu'un code de ce genre doit être commenté strictement.
D'autre part, c'est effectivement une FIFO, mais pas "émulée" comme tu le penses... C'est ainsi que sont faites la plupart des FIFO hautes performances, dans le bas niveau, notamment celles qui servent à franchir les "barrières" dans le logiciel (hard -> kernel et kernel -> user).
Leur principal avantage ? Aucune nécessité d'utiliser un système d'exclusion mutuelle, principal facteur de ralentissement dans ce genre d'opérations.
Leur principal inconvénient ? Si la FIFO elle-même ne requiert pas de mutex, il en faut malgré tout un entre les consommateurs (s'il n'y en a pas qu'un seul), et entre les producteurs (là aussi, s'il n'y en a pas qu'un seul).

Tu vas me dire que quand tu compile du C, tu arrêtes après la phase de préprocessing, tu relis tout pour vérifier que les macros ont bien fait ce qu'on attend d'elles, et après tu laisses continuer la compilation ?

Non, parce que je sais ce que fait une macro, je peux directement voir le résultat produit à l'exécution.
Mais oui, il m'est arrivé de faire juste un préprocess pour déplanter une horreur de débutant à base de multiples macros imbriquées les unes dans les autres.

Ce n'est pas parce que ce n'est pas adapté à *tous* les cas que ça retire quoique ce soit au fait que c'est *effectivement* adapté dans *plein* de cas.

Sauf que tu voudrais faire croire, justement, qu'il faut d'abord et avant tout utiliser un "foreach" quoi qu'il arrive...

Tu as oublié de répondre à la partie "et si ton autre thread vire des éléments, ce qui est proprement capturé par le foreach, mais ce qui fait planter le for".

Non, pour une seule et simple raison : ton "cas" est déjà expliqué



Ce qui est difficile en programmation parallèle, c'est de laisser en concurrence des choses qui vont faire on ne sait pas trop quoi... Typiquement, c'est le problème par exemple d'un scheduler d'OS.
Le parallélisme dans un cadre connu et défini, c'est tout sauf "difficile", c'est juste "complexe" et "rigoureux", ce qui n'a absolument RIEN à voir avec la difficulté.
La difficulté, c'est quand tu as peu de chances de réussir. Faire fonctionner plusieurs machines / processus / threads ensemble possède 100% de chances d'aboutir si :

• On ne cherche pas à faire faire des choses impossibles au système global,
• On possède la rigueur et la méthodologie requise pour implémenter le système.

Pour ma part, je vois pas mal de débutants être "paniqués" par un truc qui, pour eux, s'apparente à du "massivement parallèle" (ce qui ferait rigoler n'importe quel spécialiste de la chose, avec "à peine" cinq ou six cent unités d'exécutions toutes débuggables individuellement...).
A chaque fois, ils sont rassurés une fois que l'on a démystifié tout ça, et qu'on leur a expliqué le pourquoi du comment... Le "chamanisme" du bas niveau, c'est une vraie plaie, il n'y a rien de "mystérieux" ou de "difficile", c'est juste un domaine où le manque de rigueur et de méthode ne pardonne pas, c'est tout.

Surtout que si les problèmes de préemptions et de sections critiques doivent être portés sur des processeurs à plusieurs dizaines, centaines, milliers de coeurs, il risque de vraiment devenir urgent de leur donner ces solutions !

En quoi un cœur pose un problème ? C'est un problème au niveau hard, indubitablement, et au niveau OS et répartition automatique.
Pour le développeur au dessus de ça (y compris celui développant des drivers), la notion de cœur est rarement utilisée autrement que pour s'assurer d'un parallélisme vrai au lieu d'un pseudo-parallélisme...


Les solutions existent déjà, mais elles ne sont pas "performantes" : ce sont par exemple des FIFO thread-safe, ou des éléments globaux du système process-safe. Cela marche, bien entendu, mais ça n'apporte pas les performances maximales au niveau machine. Pour une application qui est la seule à tourner sur une machine, bouffer dix pourcents de CPU en plus n'est pas forcément un problème. Pour un driver utilisé simultanément par des dizaines de processus, ça l'est.

Va leur dire chez Esterel technologie qu'ils ne font que de la "simple génération de code" Ca va leur faire plaisir :-D

C'est pourtant le cas, c'est pas du Lustre qui tourne sur les calculateurs de bord... C'est du C et de l'Ada. T'inquiètes pas, va, ils en sont conscients, tu devrais parfois aller à Airbus discuter avec eux...


Tu ne sais pas t'adapter à cet "étage" de l'informatique ? C'est pas un drame, y'a plein de gens qui aiment et qui le font à ta place. Alors arrêtes un peu de nous bassiner : Non, tu ne sauras JAMAIS tout faire en informatique. Non, tu ne seras JAMAIS bon en "tout" en informatique.
Alors laisse faire les "pros" de chaque domaine, tu en profiteras toujours (par effet de bord, ça va te rendre fou, ça, non ? ). Au lieu de venir dire "Haskell il fait pareil que le C" (en moins vite et en plus gros), donnes plutôt des exemples où il fait MIEUX.
Et je te rappelle que le temps de développement est presque totalement négligeable dans tout ce qui est production en série...

Et ça sort d'où ça ? <snip>

Je parle de performances de code, il me parle de gestion... De footprint minimal, il me sort de l'XML et du calcul distribué...

Et que les abstractions, les systèmes de types poussé, les GC, la fiabilité du code, etc. leur ont permis de ce concentré sur les parties importantes.

Tu as oublié "et un bas niveau ultra performant" dans la liste de ce qui leur a permis de progresser...

Mais ils sont surtout capable de comprendre que ces parties là se doivent d'être réduite, confinées, et surtout, minoritaire.

J'adore le mot "minoritaire", alors qu'il doit y avoir dix mille fois plus de systèmes bas niveau en fonction dans le monde que de systèmes de haut niveau...

Tu vois : tu méprises le bas niveau
Alors que moi, j'ai toujours dit que le haut niveau avait son utilité, indéniable, notamment pour tout ce qui concerne les réalisations one-shot... Et ceci recouvre effectivement beaucoup de choses, notamment en modélisation. Après ceci, t'es gentil, mais tu laisses faire les spécialistes pour tout ce qui est performance brutale, production à grande échelle, et baisse des coûts. Bref, tu laisses faire ceux qui permettent à la technologie d'être présente partout, parce qu'on est capables de la rendre accessible à tout le monde, notamment financièrement.

Mais je ne me fais pas d'illusion va, je sais très bien que les roots, les Véritables dans ton genre restent tristement la majorité.

Ce qui est tout à fait normal : nos systèmes sont bien plus présents dans la vie de tous les jours des gens que les tiens.

Toi, t'es du genre à encenser un cuisinier de génie, parce que c'est de l'art et/ou plus "fin", et à mépriser l'agriculteur qui remplit son filet à provision.

les multi-coeurs resteront totalement sous-exploités pendant un bon bout de temps, etc.

Ah ? Première nouvelle, tiens... Nous, les multi-cœurs, on les mets au taquet au contraire, du moins dans la limite habituelle de sécurité (donc, 66% de charge au maximum). Peut-être parce qu'on sait utiliser efficacement le parallélisme...

Corrects ? Dans 90% des cas, les bugs qui apparaissent à un degré plus grand d'optimisation (enfin, en -O2 pour gcc. Au delà, ça devient dangereux) sont uniquement des trucs classiques genre dépassement de bornes qui n'avaient pas de conséquences néfaste dans le code moins optimisé par pure chance.

Et voilà très exactement ce qui me fait hurler de rire... "-O3", dangereux
Je ne sais pas, c'est mon niveau "normal" d'optimisation, ça... Y'en a d'autres ?

Vouloir réinventer la roue à chaque programme, c'est un peu ironique pour un informaticien...

En fait, on ne la "réinvente" pas tant que ça... On adapte un algorithme bas niveau, en supprimant/modifiant ses limites de façon à le rendre plus optimal. Un algorithme "générique" est bien souvent trop lent, on les utilise rarement en dehors des études de faisabilité et/ou des parties de code non-critiques.

M'enfin heureusement, pendant que tu réinventes la roue toutes les semaines, y a d'autres informaticiens qui apportent de l'innovation au monde de l'informatique.

C'est justement là que tu fais une erreur, et lourde... Tu crois que ton matériel est de plus en plus puissant pour quelle raison ? Bien sûr, le hardware est crucial dans l'opération... Mais sans personne pour l'exploiter à fond, et t'ouvrir toutes les nouvelles portes rajoutées, tu en ferais quoi ?

Tu crois que du matos devient "intelligent" sans raison ? Non, il y a dedans un microcontrôleur qui en optimise le fonctionnement, déchargeant le système principal de sa gestion... Mais quelqu'un doit bien le programmer, ce µC, justement ! Quelqu'un d'autre doit faire le pendant sur le système principal !

Alors arrêtes un peu de rêver : si le haut niveau est possible, c'est parce que le bas niveau est performant. Sans nous, vous ne pourriez RIEN faire. Et, pour être totalement honnête, sans vous qui réclamez toujours plus de puissance, NOUS ne ferions rien, parce qu'il n'y aurait plus de "marché" pour nos produits. Ces deux domaines de l'informatique ne sont pas incompatibles, ils sont disjoints, ce qui est différent.

Reprends l'analogie du cuistot et de l'agriculteur, ne craches plus dans la soupe, et apprends ton métier... Ainsi que son histoire.



Et sinon, non : depuis l'invention du transistor, puis du circuit intégré, il n'y a RIEN eu de "neuf" en informatique... Juste l'évolution normale et prévisible des technologies, mais en aucun cas il n'y a eu de "révolution".
Pas même Internet : il était évident qu'une fois le nombre d'ordinateurs suffisamment élevé, les gens voudraient les interconnecter... Et qu'une fois ce phénomène répandu chez le grand public, un réseau mondial émergerait. De nombreux livres de SF décrivaient déjà un tel réseau, et ceci bien avant 1962... Dès que la notion d'ordinateur a été inventée, en fait.

Vous pourrez parler de "révolution" à la prochaine VRAIE révolution : les circuits optiques très certainement en premier, puis peut-être les circuits biologiques ou quantiques. Mais en attendant, ça reste des assemblages (certes complexes) de simples transistors, les "mêmes" que ceux des laboratoires Bell... Ils sont juste plus petits, plus performants, moins chers, mais ça reste la même technologie des semi-conducteurs.

[alex_pi]

En quoi un cœur pose un problème ? C'est un problème au niveau hard, indubitablement, et au niveau OS et répartition automatique.
Pour le développeur au dessus de ça (y compris celui développant des drivers), la notion de cœur est rarement utilisée autrement que pour s'assurer d'un parallélisme vrai au lieu d'un pseudo-parallélisme...

Le "problème" de l'augmentation du nombre de coeurs, c'est que sur les machines à venir, la fréquence d'horloge va de moins en moins augmenter, et que pour bénéficier de la puissance de calcul d'un processeur, il faudra faire de la programmation concurente/parallèle/multi-thread/multi-coeur, appelle ça comme tu veux (et viens pas me bassiner avec les nuances de signification...)
Et que c'est un fait reconnu par tous les gens capable de tenir dans la même pièce que leur égo que la programmation à base de threads, de lock, de sémaphores, de barrières et de mémoire partagée est complexe, source d'un nombre incalculable de bugs, et qui passe assez difficilement à l'échelle (il y a souvent un thread qui fait de l'acquisition, un qui fait du traitement, un de l'affichage. On est bien loin des milliers qu'il faudra pour exploiter les multi-coeurs du futur). C'est en cela qu'il faut trouver de bons paradigmes. Le message passing peut en être un, les mémoires transactionnels un autre, le parallèlisme "dirigé par les données" encore un. En tout les cas, il est urgent de s'abstraire de la machine.

Au lieu de venir dire "Haskell il fait pareil que le C" (en moins vite et en plus gros), donnes plutôt des exemples où il fait MIEUX.

Ce qu'il fait de mieux ? Il réduit considérablement le temps de développement et produit des softs plus fiable. Et même si tu dis

Et je te rappelle que le temps de développement est presque totalement négligeable dans tout ce qui est production en série...

le Nist (National Institute of Standards and Technology) dit qu'en fait, les bugs coûteraient 60 milliards de dollars à l'économie américaine chaque année (http://www.nist.gov/public_affairs/releases/n02-10.htm) Et c'était en 2002. Avec l'impact croissant des produits informatique, c'est sans doute bien plus maintenant.
Voilà ce que les langages de haut niveau font beaucoup mieux que le C...

Je parle de performances de code, il me parle de gestion... De footprint minimal, il me sort de l'XML et du calcul distribué...

Bon, tu n'as évidement suivi aucun des liens... MAis bon ! Tu me dis "quand on veut des perfs ou un petit footprint, on doit faire du bas niveau".
Donc, pour bien dire à quoi je réponds :
Pour la partie perfs, j'ai parlé de Sawzall, un langage de chez google qui permet de traiter des téraoctets de données en quelques minutes et quelques lignes. Du haut niveau pour des performances excellentes donc.
Pour XML, je te parle d'un programme écrit en OCaml (langage de haut niveau s'il en est) qui ECRASE tous ses concurents, autant en terme de vitesse que d'occupation mémoire.

Ensuite pour la partie "faible footprint", "resources limités", je te parle de moteur hybride (que l'on met sur des camions. Donc pas le genre de truc où on fout un cluster de calcul) dont les programmes de contrôle sont écris dans un DSL embarqué dans Haskell (là aussi, pour le haut niveau, on ne fait pas beaucoup mieux).
Et je parle aussi de réseau de capteurs (le genre de truc avec rien comme mémoire, rien comme puissance de calcul, et rien comme batteries (ça c'est pour les limitation au niveau capteurs), et un réseau sans fil ad-hoc et totalement congestionné (genre un point de sortie pour une centaine de capteurs)). Réseaux de capteurs qu'il est possible de programmer avec deux langages, dont l'un est aussi un DSL embraqué dans Haskell.


un typeur, un compilo, un générateur de code, s'il n'y a pas d'erreur à la base, il ne se trompera alors jamais. Une fois qu'on a prouvé que le "foreach" était correctement compilé, on pourra faire tourner le compilo des milliers, des millions de fois, il n'y aura pas d'erreur. oui, je dis que dès que faire ce peux, il faut le plus possible déléguer à la machine, car elle est bien moins faillible que nous.

Et voilà très exactement ce qui me fait hurler de rire... "-O3", dangereux ?
Je ne sais pas, c'est mon niveau "normal" d'optimisation, ça... Y'en a d'autres ?

Je suis content que tu travailles pour airbus tiens... Ceux que -O0 fait frémir d'angoisse tellement c'est optimisant et donc source de bug..

[Mac LAK]

Mais non, il y a peut-être beaucoup d'embarqué et de systèmes critiques, mais ça ne reste qu'une faible partie des projets d'informatique.

Ce que je me tue à te répéter, c'est que c'est un domaine qui est presque TOTALEMENT invisible si tu n'en fais pas partie... Tu n'as absolument pas conscience de la masse colossale de projets "bas niveau", pour la simple et très bonne raison que tu ne verras jamais passer le moindre CdC, ni offre publique, ni quoi que ce soit qui aie le moindre rapport avec ce "monde".

On ne devient pas sous-traitant de grands comptes comme Airbus, Thalès et consorts "comme ça" : la plupart des petites boîtes ne sont même pas consultées, pas plus que les sociétés n'ayant aucune expérience industrielle d'ailleurs. De gros groupes SSII font d'ailleurs la "chasse" aux PMI ayant déjà un pied dans les grands comptes, pour les racheter et enfin réussir à "entrer" chez un client prestigieux... Et ce n'est pas facile, car ces PMI ont en général les reins largement assez solides pour envoyer braire n'importe quel Alten ou Cap Gemini, par volonté de garder leur indépendance.

Et de même qu'il n'y a pas que pour les drivers qu'il faut faire du bas niveau, il n'y a pas que pour les projets one shot que le haut niveau est utile et avantageux, mais pour tous les projets où le bas niveau n'est pas nécessaire, et il y en a énormément...

Dans toute activité commerciale, le moteur, c'est la rentabilité. Faudrait voir à ne pas oublier que l'on est là pour faire du pognon, pas du caritatif...

Faire un projet "court" en haut niveau, c'est pas cher, mais ça ne rapporte pas beaucoup non plus... Il est très dangereux de baser une activité là dessus, ce n'est pas stable ni fiable, c'est en général un truc de SSII en manque de chair fraîche, merci les sièges éjectables en fin de période d'essai (et de contrat client...).
Faire un projet énorme en bas niveau, ça revient cher, et il faut donc le vendre à plusieurs exemplaires pour le rentabiliser (la taille du "plusieurs" étant dépendante du domaine, bien sûr). Si un client ne paie pas l'étude initiale, il est quasi-impossible de démarrer un tel projet.

Or, moi, je ne parle que de projets vendus, pas d'outils internes ou de projets faits à titre gracieux sur le temps libre. En interne, pour faire une moulinette ou un mini-outil, on utilise en général un langage de haut niveau : il faut qu'il soit prêt vite, et les performances ne sont pas critiques car on ne l'utilise pas non plus cent fois par jour.

Sur des projets libres / gratuits, c'est encore pire : on n'exige RIEN de quelque chose de gratuit, on prends ce qu'il y a ou on va ailleurs (ou on mets la main à la pâte) si ça ne convient pas.

Mais des CdC où le client n'a pas la moindre exigence de performances, d'évolutivité ou de pérennité, je n'en ai jamais vu passer... Tout comme je n'ai jamais vu un client ne pas éplucher une propale, ni demander des justifications sur chaque ligne de coût. A haut ou bas niveau, d'ailleurs, ce qui rend difficile de justifier par exemple un PC à 5000 euros, ou l'achat d'une licence logicielle, etc.

Je suppose que tu n'as jamais vu passer un CdC de remplacement d'un existant, avec la contrainte de gagner par exemple 5% du coût d'exploitation / fabrication de l'existant ? Le prix de l'étude, ils s'en foutent, ils raisonnent en millions d'exemplaires par mois... L'étude sera payée rien qu'avec les bénéfices qu'ils feront sur le premier trimestre !!
Tout comme tu n'as jamais vu passer un CdC avec des exigences mécaniques / électronique de malade mental (genre démarrer à -40°C, et fonctionner jusqu'à 120°C), et bien sûr un soft sur mesure vu que ce matériel n'existe pas en standard ? Ou devoir fonctionner sur batteries dans un trou perdu sans électricité, à 50 km du poste de supervision ? Ou devoir sauver 32 ko de données sur coupure d'électricité, avec moins d'une milliseconde de délai (assuré par des condensateurs) pour le faire ?

Je te le répète encore une fois : c'est un monde dont tu n'as absolument aucune idée. Pour quelqu'un comme toi, c'est totalement invisible et transparent, même si tu en utilises pourtant tous les jours.


développement bas niveau = augmenter le prix de l'étude pour baisser le prix du matériel, car on l'utilise "mieux" et on peut se contenter de matériel moins performant.

Ensuite, il y a deux axes de développement à bas niveau : l'optimal, et le non-optimal.

Le premier est très coûteux, en effet, mais est réservé aux parties réellement critiques. Parfois, c'est le système complet qui est critique, mais cela reste rare (il y a presque toujours une IHM quelque part pour le piloter, par exemple).

Le second n'est pas énormément plus coûteux que le haut niveau, et reste globalement plus performant quand même. C'est un usage intensif de librairies existantes, notamment, qui permet de faire baisser les coûts de développement. Le résultat est un peu meilleur pour un peu plus cher : c'est alors exclusivement sur le prix du matériel que peut se jouer la différence, et donc sur le volume des ventes.

[Mac LAK]

Bah oué, c'est clair qu'un bug dans le code du software pipeliner, ça se voit à la première boucle venue. Parce qu'un tel bug n'est jamais du à un cas pathologique d'aliasing tordu, ou ce genre de chose. Nan, c'est toujours direct et vu par les tests.

C'est ça qui m'éclate, avec toi : tu crois qu'on se permet des "aliasing tordus" dans du code sûr, ou même dans du code dédié à la performance ???
Faudrait que tu arrêtes un peu de croire que le bas niveau, c'est tes bidouilles faites en TP, on ne fait pas n'importe quoi n'importe comment.
Quand au bug dans le pipeline : t'as réussi à comprendre que l'on n'utilise JAMAIS de composants qui n'ont pas une durée d'existence minimale, donc débarrassés de leurs pannes de jeunesse ?

On va faire un jeu !! Qui a dit ?

T'avais noté le smiley en fin de phrase, au moins, ou t'as eu des soucis avec le second degré, pourtant clair dans le post ?
Quand au fait de ne pas utiliser quelque chose qu'on ne connait/maitrise pas... Cela s'applique aussi bien à toi avec un "for" (vu qu'apparemment, tu ne sais pas le "lire" dans un source ni comprendre son fonctionnement) qu'à moi avec un "foreach"... Non pas parce que je ne le comprends pas, mais parce que je ne peux pas maîtriser ce qu'il fait.

Juste un petit pointeur, pas juste un "relis au dessus", pour aider les gens qui s'y perdent un peu

Même avec un "for", tu peux retirer des éléments avec deux threads simultanément, tant que tu es sur des intervalles disjoints.
Tu les fais comment, les intervalles disjoints, avec un foreach ? Ton fameux foreach, il t'interdit totalement tout accès concurrent en écriture sur un tableau... Bonjour le méga mutex qui bloque tout ? Cela doit être sympa, sur des buffers d'une taille un minimum décente, ça...

Bon plus sérieusement... Le "problème" de l'augmentation du nombre de coeurs, c'est que sur les machines à venir, la fréquence d'horloge va de moins en moins augmenter, et que pour bénéficier de la puissance de calcul d'un processeur, il faudra faire de la programmation concurente/parallèle/multi-thread/multi-coeur, appelle ça comme tu veux (et viens pas me bassiner avec les nuances de signification...)

Donc, les cœurs seront (unitairement) de moins en moins performants, et la finesse du parallélisme (ainsi que le coût des changements de contexte) seront cruciaux... Cool, le bas niveau va sauver le monde !

Quant aux différences que tu sembles ne pas comprendre... C'est pourtant totalement essentiel pour savoir ce que l'on fait. Tu veux exploiter une ressource matérielle sans comprendre comment elle fonctionne ? Original...

Pour le reste, c'est tout simplement le cycle classique de montée en puissance / optimisation logicielle qui continue. Pendant une certaine période, le matos prends de la puissance rapidement, permettant au logiciel d'être "à l'aise"... On y prends parfois de bonnes, parfois de mauvaises habitudes.
Ensuite, cette montée en puissance ralentit, et les gens se retournent alors vers l'optimisation logicielle pour continuer à entretenir un gain de puissance régulier, jusqu'au prochain "boum" du matériel.
Cela fait quand même un paquet d'années que ça se déroule ainsi, encore faut-il un minimum observer...

Et que c'est un fait reconnu que la programmation à base de threads, de lock, de sémaphores, de barrières et de mémoire partagée est complexe, source d'un nombre incalculable de bugs, et qui passe assez difficilement à l'échelle (il y a souvent un thread qui fait de l'acquisition, un qui fait du traitement, un de l'affichage.

Chez les gens que TU fréquentes, peut-être. Chez ceux que JE fréquente, le parallélisme et les notions sous-jacentes ne font plus "peur" depuis bien longtemps, en gros depuis que l'on a appris à éviter la plupart des pièges à cons classiques de la programmation parallèle.


On trouve toujours meilleur que soi : il y a des domaines dans lesquels je ne "joue" pas, parce que je sais d'avance que je ne suis pas parmi les meilleurs. Je discute très volontiers de ML ou de MDA avec certains collègues, mais je n'essaie pas de leur expliquer que ce qu'ils font est "nul", "trop complexe" ou quoi que ce soit d'autre : ils maîtrisent mieux le sujet que moi. Même dans le bas niveau, il y a plusieurs domaines dans lesquels je suis loin d'être au top niveau : là aussi, je laisse faire les spécialistes du sujet, et je reconnais également qu'ils sont meilleurs que moi.

Mais le parallélisme, l'optimisation, l'écriture de code "béton" et la conception modulaire, là, par contre, c'est MON domaine.

En tout les cas, il est urgent de s'abstraire de la machine.

Ce que tu ne pourras JAMAIS faire dans le cas de machines s'approchant du massivement parallèle, car le coût de transfert finira toujours par te rattraper et plomber les performances.
A quoi te servirait d'avoir 64 cœurs sur ta machine, si tu n'en tires pas plus de puissance qu'avec 32 à cause des transferts ??
As-tu conscience que ce que tu demandes, c'est tout simplement de l'IA "réelle" ?

C'est du C ou de l'Ada ?? Ils ont des interpréteur C sur leurs machines ? Classe !

Tiens, puisque tu aimes tant Wikipédia : Lustre (langage).
Tu y liras notamment, à propos de SCADE : "Il est basé sur le langage Lustre, et permet de générer du code en langage C ou Ada.".

Ce qu'il fait de mieux ? Il réduit considérablement le temps de développement et produit des softs plus fiable.

Et tu me montres ton driver en Haskell ? Juste pour rire ?

le Nist (National Institute of Standards and Technology) dit qu'en fait, les bugs coûteraient 60 milliards de dollars à l'économie américaine chaque année

Certes. Tu mets aussi le bénéfice à côté, stp, afin que l'on puisse comparer ? Faut pas confondre non plus "pertes" et "manque à gagner", là aussi, ce sont deux choses différentes.
Tu mettras aussi la ventilation langage par langage, et domaine par domaine... Faut pas confondre un bug dans un traitement de texte codé en C/C++ (ce qui est hérétique en soi, un RAD devrait être obligatoire pour faire ça), chose plutôt fréquente, et un bug dans un microcontrôleur ou un système embarqué, infiniment plus rare...

Tu noteras aussi que ça ne représente "que" 0.6% du PIB américain, et que le logiciel (ne serait-ce que via Microsoft...) contribue à bien plus que ça !! Également, tu noteras qu'ils disent bien que le principal problème est le manque de tests... Arf, tiens, c'est con, nous on en fait plein, c'est "juste" le cœur de métier...

Voilà ce que les langages de haut niveau font beaucoup mieux que le C...

Ah ben zut, alors... Pourquoi est-ce que mon OS n'est pas en Haskell, alors ? Ou mes compilos ? Ou mes outils de dév ? Ou mes jeux favoris ?
J'sais pas, moi, je dois être crédule : on me propose un produit fabuleux, qui n'est pourtant pas vastement implanté tout partout, n'y aurait-il pas quelques anguilles sous roche ?

Pour la partie perfs, j'ai parlé de Sawzall, un langage de chez google qui permet de traiter des téraoctets de données en quelques minutes et quelques lignes. Du haut niveau pour des performances excellentes donc.

Certes... Sur quel matos ? Parce que tu sais, sur mon PC pas trop mal, mais pas excellent non plus vu qu'il a bientôt deux ans, je débite jusqu'à 4 Gbit/s en C/C++ sur les transferts mémoire...
Autre chose : en quoi est écrit le runtime de ce langage ?

Pour XML, je te parle d'un programme écrit en OCaml (langage de haut niveau s'il en est) qui ECRASE tous ses concurents, autant en terme de vitesse que d'occupation mémoire.

Là, je te parle du VOLUME de l'XML de façon générale... On ne va pas embarquer un fichier XML de 20 ko sur un CPU qui possède en tout et pour tout 32 ko de RAM, alors qu'on peut faire tenir la même chose en 200 octets de données binaires !
De l'autre côté de la lorgnette : la configuration des systèmes que j'utilise, c'est une base de données dont la taille oscille entre une dizaine de mégas et, virtuellement, une taille maximale limitée uniquement par les capacités de la machine.
La même chose en XML ? Cela prendrait cinq à dix fois plus de place... Rien qu'en temps de chargement, on fait exploser le temps d'initialisation du système !!

Ensuite pour la partie "faible footprint", "resources limités", je te parle de moteur hybride (que l'on met sur des camions. Donc pas le genre de truc où on fout un cluster de calcul) dont les programmes de contrôle sont écris dans un DSL embarqué dans Haskell (là aussi, pour le haut niveau, on ne fait pas beaucoup mieux).

T'es au courant qu'un système embarqué de type console de gestion hybride, c'est juste un PC durci, avec à peu près la même puissance et le même coût ? C'est un peu comme si tu te vantais de réussir à faire tourner ton programme sur un TabletPC...

Réseaux de capteurs qu'il est possible de programmer avec deux langages, dont l'un est aussi un DSL embraqué dans Haskell.

Si tu avais lu un peu mieux ton truc, tu aurais vu qu'au final, c'est du code bas niveau qui est compilé et téléchargé dans les capteurs en question... Et qu'il serait assez étonnant qu'ils n'aient pas demandé l'aide de spécialistes du bas niveau pour savoir comment créer ce code bas niveau, justement. Mais je ne vois toujours pas d'Haskell dans les capteurs eux-mêmes...

Tu es donc vraiment imbu de toi même au point de penser que tes capacité cérébrales sont illimitées et qu'il est donc normal de ne rien automatiser ? Que tu n'as rien à gagner à perdre moins de temps "collé à la machine" ?

Elles ne sont pas illimitées... Pas même dans mes domaines de prédilection. Mais mes limites, dans MON domaine, sont suffisamment élevées pour que je puisse encore progresser. L'horreur serait de ne plus progresser, d'arriver à ses limites, justement... Super, c'est quoi le programme ensuite, la stagnation ?
Ce n'est pas être imbu de soi-même, c'est juste avoir conscience de ses propres limites. Dans mon domaine, je ne les ai pas atteintes, et progresser constamment aide aussi à les repousser. Dans d'autres domaines, ça fait longtemps que j'ai atteint mes limites.

Automatiser ? C'est aussi le but de mon métier, tu en as conscience ? Sauf que je permets aux AUTRES d'automatiser LEUR boulot, en leur fournissant un système suffisamment performant pour le leur permettre.
Et on automatise aussi au bas niveau : génération de code, de tests, d'outils... Simplement, on ne laisse pas le module "xml2c" travailler tout seul, on contrôle ce qu'il fait, on rectifie, on décide des routines critiques qu'il faut faire manuellement, ou des librairies qu'il est "safe" d'utiliser. Pour nous, le haut niveau n'est pas une fin en soi, c'est juste un outil, on maîtrise la chaîne de génération, et on contrôle ce qui est produit, du début à la fin.

Alors qu'un typeur, alors qu'un compilo, alors qu'un générateur de code, s'il n'y a pas d'erreur à la base, il ne se trompera alors jamais.

Déjà, ça sous-entends que le programmeur qui l'a réalisé n'a commis aucune erreur, ce qui est impossible d'après toi... On tourne en boucle, là !!

Je ne dis absolument pas que l'ordinateur doit prendre la place du programmeur, de ses idées, de ses algorithmes, de sa vision du projet, etc. Par contre, oui, je dis que dès que faire ce peux, il faut le plus possible déléguer à la machine, car elle est bien moins faillible que nous.

Apprends à raisonner aussi comme une machine : cela aide beaucoup pour faire moins d'erreurs... Penser froidement, logiquement, suivre une procédure à la lettre même si l'on pense la connaître par cœur, ne jamais présupposer de rien et vérifier les entrées, toujours contrôler les sorties...
On ne peut pas être bon en bas niveau si l'on ne sait pas, dans les cas critiques, raisonner comme la machine.

Je suis content que tu travailles pour airbus tiens... Ceux que -O0 fait frémir d'angoisse tellement c'est optimisant et donc source de bug..

En SdF, effectivement, on n'optimise pas via le compilateur, mais "à la main". Dans les autres domaines, c'est le contraire, on optimise au maximum possible dans tous les coins, manuellement comme via le compilateur.

Et si tu penses que -O3 est toujours mieux que -O2, alors laisse moi participer à ta "super tranche de rigolade"..

Sur du code bas niveau correctement écrit, c'est toujours le cas. Je te rappelle quand même que l'on teste sans optimisations auparavant, et que l'on applique une non-régression sur le code optimisé...