Discussion :

[souviron34]

d'ailleurs, et même si c'est un peu HS, je le re-mentionne


Si tout était si beau dans le meilleur des mondes possibles, et que les nouveaux langages, de même que les nouveaux concecpts et les nouvelles méthodologies étaient si meilleurs que ce qui existait avant, comment expliquer que Thalès (pourtant ISO 9001, 2, et toute la série, CMMMi-compliant, etc etc, grand utilisateur de preuves formelles, etc etc) soit aujourdhui face à de graves problèmes pour ses sondes PITO pour les Airbus, que même les sondes nouvelles générations remplacées depuis le crash du vol Rio-Paris apparaissent suffisamment peu fiables pour que le Syndicat des Pilotes de Ligne recommande officiellement de changer de fournisseurs ??

[jabbounet]

d'ailleurs, et même si c'est un peu HS, je le re-mentionne


Si tout était si beau dans le meilleur des mondes possibles, et que les nouveaux langages, de même que les nouveaux concecpts et les nouvelles méthodologies étaient si meilleurs que ce qui existait avant, comment expliquer que Thalès (pourtant ISO 9001, 2, et toute la série, CMMMi-compliant, etc etc, grand utilisateur de preuves formelles, etc etc) soit aujourdhui face à de graves problèmes pour ses sondes PITO pour les Airbus, que même les sondes nouvelles générations remplacées depuis le crash du vol Rio-Paris apparaissent suffisamment peu fiables pour que le Syndicat des Pilotes de Ligne recommande officiellement de changer de fournisseurs ??

une application, un métériel ne peux etre parfait quelque soit le process, c'est pour cela que dans pratiquement tous les processus qualité tu as des boucle d'amélioration continue..

Et je suis certain que qu'il y'a tous un process qui se met en place pour que ce problème ne se reproduise plus.

[souviron34]

une application, un métériel ne peux etre parfait quelque soit le process, c'est pour cela que dans pratiquement tous les processus qualité tu as des boucle d'amélioration continue..

Et je suis certain que qu'il y'a tous un process qui se met en place pour que ce problème ne se reproduise plus.

ce qui était exactement le cas avec les anciens langages et les anciennes méthodologies et les anciens process

[chaplin]

Les mainefraimes tirent leur puissance principalement de leur code "assembleur" optimisé et aussi du hardware, il suffit de voir à quel point l'OS et le SGBDR sont liés l'un à l'autre ne serait-ce que pour la sécurité et la gestion des Batchs au niveau du processeur. Mais peut être que d'autres personnes seront plus calés pour parler du sujet.

[Mac LAK]

tout dépend si cette transformation a été "prouvée" statiquement... auquel cas on connait exactement le coût de cette transformation (voire ses avantages )

Ce qui demande à avoir les preuves du programme d'analyse statique, ainsi que ce genre de détail d'implémentation... On arrive dans l'usine à gaz.

certains domaines comme l'aéronautique utilisent encore des 68'000

Encore plus "vieux" que ça, même, pour pas mal de secteurs... Trouver un CPU en gamme militaire, par exemple, ce n'est pas trivial.

sans aucun effet de bord que peut ensuite utiliser l'implémentation de foreach.

Merci de relire les posts précédents avant de troller encore une fois sur n'importe quoi.

J'espère que quand tu compiles, t'es toujours au niveau 0 des optimisations. Parce que sinon, sans vouloir t'inquiéter, il y a quand même beaucoup plus de chance que les bugs du compilo soient dans l'allocation de registre ou le software pipelining, que dans le foreach...

Bien entendu que le test nominal est fait sans optimisations... Seul un demeuré pourrait faire les premiers tests en mode ultra optimisé. Une fois que l'on a la preuve que le code tel qu'il a été écrit tourne suivant la spécification (= validation), on peut alors générer une version optimisée et vérifier la non-régression : si différence il y a, alors elle est dûe à l'optimisation (que ce soit par modification du timing ou erreur d'optimisation, ça n'a aucune importance).

Qui a déjà vu un dépassement de borne dans le descriptif d'une faille de sécurité ????

Regarde mieux les problèmes de buffer overrun, par exemple... Typiquement, c'est une borne de fin qui est réévaluée pendant l'itération et finit par un dépassement.

Et pourquoi il serait forcément détecté ? Non mais sérieusement, tu crois qu'un compilo ne fait rien avec une boucle ? Qu'il la laisse telle quelle ? Qu'il ne la déroule jamais, ne fais jamais de software pipelining ? D'élimination de code mort ? De permutation d'instruction ?

Ce qui entre dans la catégorie des optimisations de traduction, pas de la validité du code source (ou de l'algo correspondant si tu préfères).

Si tout était si beau dans le meilleur des mondes possibles, <snip>

Il arrive même souvent qu'un grand compte refuse systématiquement toute technologie qui n'a pas été longuement éprouvée par l'usage en conditions réelles... Donc, inutile de leur proposer le dernier joujou, il n'en voudront pas. Certains n'acceptent les métamodèles que parce que ce n'est qu'un moyen de générer du code, et qu'ils peuvent relire le code en question.

[alex_pi]

Merci de relire les posts précédents avant de troller encore une fois sur n'importe quoi.

J'ai apporté une preuve qu'un foreach peut être vu sans aucun effet de bord. Donc j'attends une explication de "l'effet de bord inhérent"..

Une fois que l'on a la preuve que le code tel qu'il a été écrit tourne suivant la spécification (= validation)

Faudrait voir à distinguer "on a fait plein de tests" et "on a la preuve que" hein...

Regarde mieux les problèmes de buffer overrun, par exemple... Typiquement, c'est une borne de fin qui est réévaluée pendant l'itération et finit par un dépassement.

Truc qu'on ne peux pas faire avec un foreach. J'aime quand tu es d'accord avec moi
Mais sérieusement, un jour, achète toi "le second degré pour les nuls" hein...



Un jour, tu regarderas l'analyse de durée de vie, l'analyse d'alias (et les optims qui en découlent), l'allocation de registre (coloration de graphe d'interférence, spilling, coalescing, blablabla), le software pipelining, etc, etc. Et après, j'aimerais que tu viennes m'expliquer ce que le sucre syntaxique qu'est un foreach a de compliqué par rapport à tout ça,

Et ça aurait coûté beaucoup, beaucoup plus cher, ne serait-ce qu'en matériel. Un système matériel, pour ma branche, c'est environ un million d'euros. Doubler les performances, c'est doubler le matos.

on a décidé de coder le coeur du coeur en C pour que ça aille vite, et le reste en plus haut niveau pour qu'on puisse coder vite, bah en fait, il a une baisse de perf négligeable mais un coup de dével deux fois plus faible, donc un produit deux fois moins cher, il sera moins mécontent que prévu ?

[Mac LAK]

J'ai apporté une preuve qu'un foreach peut être vu sans aucun effet de bord. Donc j'attends une explication de "l'effet de bord inhérent"..

Ben tu vas relire les posts précédents, j'en ai marre de me répéter avec toi.

Faudrait voir à distinguer "on a fait plein de tests" et "on a la preuve que" hein...

La "preuve" par validation est suffisante pour des certifications de sécurité, alors tu m'excuseras si l'avis d'un étudiant aigri n'arrive pas à m'inquiéter à ce sujet ?

Truc qu'on ne peux pas faire avec un foreach.

Et justement, si, c'est tout à fait possible avec un "foreach", tu n'as qu'à aller lire les posts précédents. Un foreach peut ne jamais se terminer.

Ah ouais mais en fait, tu n'as vraiment aucune compréhension de ce que fait un compilo C, c'est ça ?

Ah ouais mais en fait, tu n'as vraiment aucune capacité de lecture, c'est ça ?
Tests de validation = sans optimisations, je l'ai écrit un peu plus haut. Donc, sans trucs et astuces d'optimisation pouvant modifier lourdement le code.
Ensuite, une fois le code validé sans possibilité d'ingérance de l'optimisation, on peut le tester en optimisé pour augmenter encore les performances.

Quand on a besoin de performances et de footprint minimal, on ne va pas s'amuser à jouer avec des langages inadaptés à ça. Ce qui est super con, c'est ta "méthode" qui consisterait à faire casquer au client le double de matos pour entretenir ton incompétence à faire un truc un peu complexe en bas niveau ?

on a décidé de coder le coeur du coeur en C pour que ça aille vite, et le reste en plus haut niveau pour qu'on puisse coder vite, bah en fait, il a une baisse de perf négligeable mais un coup de dével deux fois plus faible, donc un produit deux fois moins cher, il sera moins mécontent que prévu ?

Contrairement à certains (oui, toi), je n'ai jamais dit que le haut niveau était inutile... Le seul à cracher, ici, c'est toi en général. Je ne fais pas d'IHM en C de base, j'utilise un RAD pour ça. Je ne fais pas de scripts de configuration en C, j'utilise un langage de script pour ça. Mais en aucun cas je ne laisserai un coeur temps réel et/ou critique en autre chose qu'un langage bas niveau et/ou sécuritaire. Donc, C ou Ada.

Mais le haut niveau n'est pas adapté à du code critique : jamais dans le cas des performances et du footprint, et il n'y a QUE si ces deux éléments sont d'importance négligeable dans le projet qu'un langage de haut niveau peut éventuellement venir concurrencer côté sûreté de fonctionnement... Sachant qu'il est également très courant de valider la SdF par preuve de bon fonctionnement, ce qui met directement en tête certains "vieux" programmes qui ont fait leurs preuves depuis des dizaines d'années.

[alex_pi]

Ben tu vas relire les posts précédents, j'en ai marre de me répéter avec toi.

Tout ce que tu dis dans les "posts précédents", c'est que soit disant, le "foreach" ne serait pas résistant aux effets de bord, parce que si on rajoute des éléments trop vite, ça risque de boucler à l'infini (ce qui n'est donc pas du tout un effet de bord inhérent au foreach). Et là, je me permets de te signaler que dans le cas d'un for où tu aurais "déterminé par avance les bornes" (avant que tu me répondes "j'ai jamais dit ça", voilà la citation :

Via un "for", tu récupères à un instant T le nombre d'éléments du tableau (donc "tous" en début de boucle), puis tu les consommes, quel que soit le nombre d'éléments ajoutés au tableau pendant la consommation. Ton algorithme s'arrête, pas de boucle infinie, les contextes d'exécution multitâche ne sont pas bloqués et tout va bien.

), donc, dans le cas où tu aurais déterminé les "bornes" par avance, si un autre thread RETIRE des éléments au lieu d'en ajouter, BAM, tu sors du tableau, et soit tu as une exception (dans le cas où tu es un noob qui utilise un langage qui vérifie dynamiquement les bornes. Bouuuuuh le loozer !), soit tu as un crash, soit vachement mieux, tu as un comportement non déterminé pouvant mener à une faille.
Et là bien sûr, tu vas me répondre "il faut vraiment être le dernier des abrutis pour retirer des éléments d'un tableau alors qu'on le parcours avec un for". Ce à quoi je te répondrais que quand on en ajoute alors qu'on le parcours avec un foreach et qu'on ne veut pas que ça boucle, le diagnostique est finalement le même.

On en revient d'ailleurs à ce que je disais avant, les effets de bords, c'est le bordel, et pour de la programmation multi-thread, rien de tel que des bonnes structures persistantes. Programmation fonctionnelle, tu es notre sauveuse.

La "preuve" par validation est suffisante pour des certifications de sécurité, alors tu m'excuseras si l'avis d'un étudiant aigri n'arrive pas à m'inquiéter à ce sujet ?

Je suis quand même content qu'Airbus programme ses codes critiques en SCADE qui permet de prouver formellement que l'on est conforme aux spécifications, qu'ils imposent des normes strictes sur les façons de coder, qu'ils fassent tourner Astrée sur l'intégralité du code extraits, qu'il y ait de très nombreuses relecture de code, et finalement qu'aucun organisme de certification n'accepte "nan mais c'est bon les gars, on a fait des tests unitaire, c'est donc prouvé par validation, on peut faire tourner.

Tests de validation = sans optimisations, je l'ai écrit un peu plus haut. Donc, sans trucs et astuces d'optimisation pouvant modifier lourdement le code.
Ensuite, une fois le code validé sans possibilité d'ingérance de l'optimisation, on peut le tester en optimisé pour augmenter encore les performances.

Donc, pour résumer : test de validation, sans optimisation, et après on optimise, et on re-teste.

Quand on a besoin de performances et de footprint minimal, on ne va pas s'amuser à jouer avec des langages inadaptés à ça. Ce qui est super con, c'est ta "méthode" qui consisterait à faire casquer au client le double de matos pour entretenir ton incompétence à faire un truc un peu complexe en bas niveau ?

Ou alors lui faire payer le soft 4 fois moins parce qu'on l'a développé beaucoup plus vite, et qu'il y a eu beaucoup moins de bugs ?

Mais le haut niveau n'est pas adapté à du code critique

Encore une fois, il est tellement pas adapté au code "critique" que les gens d'Airbus code en SCADE.

Mais le haut niveau n'est pas adapté à du code critique : jamais dans le cas des performances et du footprint, et il n'y a QUE si ces deux éléments sont d'importance négligeable dans le projet qu'un langage de haut niveau peut éventuellement venir concurrencer côté sûreté de fonctionnement...

Est ce que tu pourrais reformuler cette phrase ?

[ZoinX]

Ce qui est super con, c'est ta "méthode" qui consisterait à faire casquer au client le double de matos pour entretenir ton incompétence à faire un truc un peu complexe en bas niveau ?

Je rejoins un peu ce qu'a dit alex_pi, mais tu es tellement ancré dans ton monde de l'embarqué que tu en oublies que dans le cas d'un hardware PC standard, doubler la puissance du hardware (soit dit en passant, la différence de perfs entre les langages bas niveau et les meilleurs langages haut niveau est bien moindre qu'un facteur 2...) coûte généralement infiniment moins cher que doubler le temps ou les effectifs de développement (ce qui est à mon avis un facteur réaliste de gain de temps entre coder en bas niveau et haut niveau), en particulier pour les gros projets.

[souviron34]

Je rejoins un peu ce qu'a dit alex_pi, mais tu es tellement ancré dans ton monde de l'embarqué que tu en oublies que dans le cas d'un hardware PC standard, doubler la puissance du hardware (soit dit en passant, la différence de perfs entre les langages bas niveau et les meilleurs langages haut niveau est bien moindre qu'un facteur 2...) coûte généralement infiniment moins cher que doubler le temps ou les effectifs de développement (ce qui est à mon avis un facteur réaliste de gain de temps entre coder en bas niveau et haut niveau), en particulier pour les gros projets.

Et voilà !!!


Un truc de paresseux et l'appat du gain comme justification !!!!!


Alors que notre métier est de tenter de faire quelque chose de propre et d'efficace, vous circulez et admettez et soutenez le fait que la paresse intellectuelle et l'argent seront forcément la solution...

Et simultanément vous râlez pour tout avoir gratis


C'est, à mon avis, le fond du problème et là où je rejoins Mac LAK.


Que ce soit les langages de haut niveau, la place disque, mémoire, la vitesse d'exécution, l'argument entendu partout est "bah !! ça coûte pas cher, du disque, de la mémoire, du CPU"...

Vous rendez-vous compte de ce que vous dites ?????

[jabbounet]

Et voilà !!!


Un truc de paresseux et l'appat du gain comme justification !!!!!


Alors que notre métier est de tenter de faire quelque chose de propre et d'efficace, vous circulez et admettez et soutenez le fait que la paresse intellectuelle et l'argent seront forcément la solution...

Et simultanément vous râlez pour tout avoir gratis


C'est, à mon avis, le fond du problème et là où je rejoins Mac LAK.


Que ce soit les langages de haut niveau, la place disque, mémoire, la vitesse d'exécution, l'argument entendu partout est "bah !! ça coûte pas cher, du disque, de la mémoire, du CPU"...

Vous rendez-vous compte de ce que vous dites ?????

je vous rejoins la dessus (mak et souviron) et j'ajouterai ceci:

l'ajout de matériel n'est pas toujours possible/souhaitable.

Tiens mon appli ram sur mon I-pod like comment améliorer les perf?
rajoute un Quad-Core Extreme avec ventilo tu verra ton appli marchera mieux. Ok mais ensuite cela ne tiendra plus dans la poche

Autre exemple:

l'ajout de matériel n'apporte pas forcement le gain de performances espéré/attendu..... tu peux avoir des soucis avec la scalabilité de ton application, et la non seulement tu aura acheté un matériel pour rien, mais en plus tu devras quand même te tapper un recherche d'optimisation.

[ZoinX]

Un truc de paresseux et l'appat du gain comme justification !!!!!

Alors que notre métier est de tenter de faire quelque chose de propre et d'efficace, vous circulez et admettez et soutenez le fait que la paresse intellectuelle et l'argent seront forcément la solution...

Je ne dis pas que c'est bien ni que c'est une excuse pour coder comme un pied. Jamais rien ne justifiera de coder comme un pied.

Seulement notre monde est régi par l'économie, et même nous autres informaticiens devont bien manger aussi... Donc si un choix coûte moins cher qu'un autre, il est normal et réaliste qu'il soit choisi. C'est triste mais l'argent est la solution...

De plus, autant coder comme un pied n'est pas excusable, autant coder avec un langage de haut niveau l'est nettement plus. Il permet généralement de coder deux fois plus vite, pour des performances *peu* inférieures (eh oui de nos jours les langages de haut niveau ne sont plus si mauvais que ça en termes de performances, et l'écart se réduit toujours plus !)

Enfin un dernier point à ne pas oublier. Les logiciels mal optimisés sont effectivement une plaie en général, mais ils ont quand même un avantage non négligeable. Si Vista tournait correctement sur 256 Mo de ram, est-ce que vous croyez qu'aujourd'hui on aurait 4 Go de ram pour 30 euros ? Si les développeurs de jeux vidéos savaient optimiser leurs jeux, est-ce que vous croyez qu'aujourd'hui on aurait des cartes graphiques atteignant les 2 TFlops ?
Et même tout simplement, sans les langages de haut niveau, pensez-vous qu'il existerait autant de logiciels hyper complets avec autant de fonctionnalités ? Autant de PME capables de coder d'énormes projets avec si peu d'employés ?

Il faut arrêter de cracher sur les langages de haut niveau. Ils ne sont peut-être pas au top du top des performances (mais ils en sont de moins en moins loin), ils donnent peut-être de mauvaises habitudes à certains mauvais programmeurs, mais ils sont aussi les moteurs de l'innovation du hardware, des logiciels de plus en plus complexes et des petites entreprises capables de coder de grandes choses.

[jabbounet]

Je ne dis pas que c'est bien ni que c'est une excuse pour coder comme un pied. Jamais rien ne justifiera de coder comme un pied.

Seulement notre monde est régi par l'économie, et même nous autres informaticiens devont bien manger aussi... Donc si un choix coûte moins cher qu'un autre, il est normal et réaliste qu'il soit choisi. C'est triste mais l'argent est la solution...

le souci c'est que l'on oubli de prendre en compte le surcout de consommation électrique entre autre..... et on ne vois souvent que le cout d'achat rarement les cout indirect engendrés. tres ecologique la solution.

A une époque les développeurs de jeu vidéo optimisaient leur code comme tout le monde (il n'avaient pas le choix). ce qui fait que l'informatique a poussé sur le matériel c'est en partie les besoin croissant en calcul (pour la recherche notamment). et que les technologies mise au point pour la recherche finissent tôt ou tard par arriver dans le grand public.

maintenant les jeux vidéo poussent aussi avec des besoins croissant en bandes passantes pour les jeux vidéo ou l'envie d'avoir des environnement de plus en plus réalistes.

mais quand je regarde les rfc sur les protocoles qui arrivent je me dit qu'avec le formatage des messages utilisés je ferais passer un bible sur mon tuyau avec deux fois moins d'octets.

[Alakazam]

Au contraire, dans les situations décrites par Zoinx (où les serveurs ont besoin d'être hébergés), les coûts de climatisation et d'hébergement des serveurs sont toujours pris en compte (car ils sont en effet élevés).

Et malgré cela, bien souvent, doubler la capacité serveur et coder en C# plutôt qu'en C permet d'avoir considérablement plus de fonctionnalités (en exploitant les très nombreuses libraries existantes, plutôt qu'en réinventant la roue), avec moins de développeurs (libraries, modularité, frameworks préexistants, documentation très poussée, focus sur les fonctionnalités et non les problématiques bas niveau "génériques"), en moins de temps : débugguer du C# est considérablement plus simple que débugguer du C ! Et en plus, de nombreuses erreurs que même un développeur chevronné réalise à l'occasion (buffer overflow, etc.) sont prémunies par les structures de données ou modèles de programmation haut niveau (objet, fonctionnel). De plus, la syntaxe des langages plus haut niveau (C++, C#, java, python, etc.) est presque toujours plus agréable que celle des langages plus bas niveau (C, ADA).

[jabbounet]

Au contraire, dans les situations décrites par Zoinx (où les serveurs ont besoin d'être hébergés), les coûts de climatisation et d'hébergement des serveurs sont toujours pris en compte (car ils sont en effet élevés).

Et malgré cela, bien souvent, doubler la capacité serveur et coder en C# plutôt qu'en C permet d'avoir considérablement plus de fonctionnalités (en exploitant les très nombreuses libraries existantes, plutôt qu'en réinventant la roue), avec moins de développeurs (libraries, modularité, frameworks préexistants, documentation très poussée, focus sur les fonctionnalités et non les problématiques bas niveau "génériques"), en moins de temps : débugguer du C# est considérablement plus simple que débugguer du C ! Et en plus, de nombreuses erreurs que même un développeur chevronné réalise à l'occasion (buffer overflow, etc.) sont prémunies par les structures de données ou modèles de programmation haut niveau (objet, fonctionnel). De plus, la syntaxe des langages plus haut niveau (C++, C#, java, python, etc.) est presque toujours plus agréable que celle des langages plus bas niveau (C, ADA).

C++,C#, java on pratiquement la même syntaxe. je me demande ce qui fait que l'une est plus agréable à lire que l'autre.

maintenant Ada je ne sais pas si tu a lu la syntaxe, mais elle est d'un clareté rarement vu dans les languages.

quelques exemples:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 function Count_Letters(Item : String) return Natural is
       Count : Natural := 0;
    begin
       for I in Item'Range loop
          if Is_Letter(Item(I)) then
             Count := Count + 1;
          end if;
       end loop;
       return Count;
    end Count_Letters;

Code :

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

1
2
3
4
5
6
7
8
9
   procedure Print_Message(For_Day : in Days) is
   begin
      if For_Day in Saturday..Sunday then
         Ada.Text_Io.Put_Line("Go Fishing!");
      else
         Ada.Text_Io.Put_Line("Go To Work!");
      end if;
   end Print_Message;

exemple de délaration de package

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
---------------------------------------------------------------
-- Ada operator examples
---------------------------------------------------------------
package Operator_Examples is
   type Days is (Monday, Tuesday, Wednesday, Thursday, Friday,     Saturday, Sunday);

   procedure Print_Message(For_Day : in Days);

   type Daily_Sales is array(Days) of Float;

   function Total(Sales : in Daily_Sales) return Float;

   function Geometric_Mean(Sales : in Daily_Sales)
      return Float;
end Operator_Examples;

tiré de
http://www.adaic.org/whyada/intro4.html

[_skip]

Deux mondes qui méritent de coexister je pense...
Et il est aussi vrai que ce n'est pas parce qu'un langage est dit *de haut niveau* qu'il faut plus faire attention aux structures de données qui sont utilisées et à l'efficacité de l'implémentation.

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. Le bas niveau est nécessaire lorsqu'on a besoin d'un degré de contrôle très fin de ce qui se passe sous le capot, mais plus de contrôle amène souvent plus de responsabilité...

En fait je comprend pas pourquoi ces deux mondes doivent impérativement être en guerre alors qu'ils répondent simplement à des besoins différents.

Certains ont raisons lorsqu'ils disent qu'un investissement supplémentaire en hardware est souvent moins coûteux que des retards de développement d'un soft, peut être que c'est pas éthique mais c'est juste une réalité économique. Faut juste savoir jusqu'à quel point on peut s'appuyer dessus car les limites existent et arrivent parfois vite.

[jabbounet]

Deux mondes qui méritent de coexister je pense...
Et il est aussi vrai que ce n'est pas parce qu'un langage est dit *de haut niveau* qu'il faut plus faire attention aux structures de données qui sont utilisées et à l'efficacité de l'implémentation.

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. Le bas niveau est nécessaire lorsqu'on a besoin d'un degré de contrôle très fin de ce qui se passe sous le capot, mais plus de contrôle amène souvent plus de responsabilité...

En fait je comprend pas pourquoi ces deux mondes doivent impérativement être en guerre alors qu'ils répondent simplement à des besoins différents.

Certains ont raisons lorsqu'ils disent qu'un investissement supplémentaire en hardware est souvent moins coûteux que des retards de développement d'un soft, peut être que c'est pas éthique mais c'est juste une réalité économique. Faut juste savoir jusqu'à quel point on peut s'appuyer dessus car les limites existent et arrivent parfois vite.

Aucun problème la dessus, simplement ce n'est pas sale de mettre un peu les main dans la graisse de processeur et dans le cambouis du disque dur.

Personnellement j'ai navigué du haut vers le bas et du bas vers le haut en terme de techno, du code mal fait on en vois a tous les étages et ce n'est pas du tout lié au langage et à la techno utilisé. mes préférences restent tout de même dans le milieu et le bas, car c'est celui qui offre le plus de liberté je trouve.

[Mac LAK]

C'est bien, quand tu le développes tu sais ce que tu fais, alors que l'auteur du compilo, quand il développe le partie qui désucre le foreach, il est complètement bourré, et il tape sur le clavier avec le front.

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.

Tout ce que tu dis dans les "posts précédents", c'est que soit disant, le "foreach" ne serait pas résistant aux effets de bord, parce que si on rajoute des éléments trop vite, ça risque de boucler à l'infini (ce qui n'est donc pas du tout un effet de bord inhérent au foreach).

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.

Or, utiliser un buffer de cette manière est courant, c'est finalement une simple FIFO protégée par l'algorithme d'utilisation et non pas par un mutex coûteux en performances. Des cas similaires, en programmation concurrente, tu en as autant que tu veux, ce n'est limité que par l'imagination.

Je suis quand même content qu'Airbus programme ses codes critiques en SCADE

... qui génère du code en langage C ou Ada. Code relu, et cela n'empêche pas de valider le code C/Ada résultant. De toutes façons, c'est le plus souvent de l'Ada qui est utilisé pour les systèmes supercritiques, et le C pour le reste.

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...

aucun organisme de certification "nan mais c'est bon les gars, on a fait des tests unitaire, c'est donc prouvé par validation, on peut faire tourner.

Non, en effet. Mais c'est les tests en question qui seront acceptés par le client, puis intégrés, re-testés et finalement c'est le système dans sa globalité que l'on certifie. Via par exemple des bancs de test, ou des équipements de stub et/ou d'espionnage. Pour ma part, j'ai aussi bien fait des équipements de contrôle que des équipements de banc.

Les normes de SdF définissent comment développer pour être certifiable, et le processus de développement est contrôlé par audits et les procédures ISO 9001 (suivi documentaire et de processus de développement).

Sans déconner : t'as déjà travaillé "pour de vrai", avec un salaire conditionné par tes résultats, et/ou vu la réalité industrielle ?? T'as idée du coût d'une certification pour un produit ? On réserve ça soit au système dans sa globalité, soit à des éléments supercritiques (calculateurs principaux à redondance par exemple).

Et la plupart des certifications sont faites "par étage" : on développe par exemple des sous-systèmes unitaires suivant une approche SIL2, pour valider SIL2 le sous-système, et on valide en SIL4 l'ensemble des sous-systèmes SIL2 pour finir par certifier le système complet SIL4. C'est bien moins cher, et dans plusieurs cas c'est même plus efficace qu'un système totalement SIL4, ne serait-ce que par la redondance obligatoirement induite pour passer de SIL2 à SIL4...

Donc, pour résumer : test de validation, sans optimisation, et après on optimise, et on re-teste.

Oui. Seules les étapes (et les personnes) changent entre les deux : la validation "sans optimisations" est faite par le développeur, afin de valider suivant sa propre spec (=cas nominaux bien sûr, ainsi que tous les cas dégradés connus et attendus). Il effectue au passage bien sûr des tests de pré-intégration, et c'est après cette phase que l'on passe en optimisé : test de non-régression immédiat sur la version optimisée (pas gênant, on vient de le dérouler sur la version non-optimisée "à l'instant"), puis passage à l'intégration "réelle" où c'est validé par une autre équipe.

le code optimisé n'aura plus aucun rapport avec le code qu'on a testé avant ?

On teste les deux. Le premier pour l'algorithme global, les changements de contexte, etc. Bref, les cas prévus et connus, qui permettent de tester le code et l'implémentation.
Puis, les tests sur la version optimisée, en intégration "réelle", où on trouve soit des bugs "faciles", soit des bugs plus difficiles à trouver. 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é).


La puissance des machines n'évolue pas sur du matos qui va tourner 10 ans quasiment non-stop sans maintenance. Et le matériel, ça commence en même temps que le soft (et souvent un peu avant), parce que :

• Ce ne sont pas des PC Auchan, achetés par palettes.
• Il faut également faire la conception du matériel, le développement, prendre en compte les délais de fabrication / approvisionnement (un délai d'appro de 3 mois sur des composants un peu évolués, c'est plus que courant...).
• Le matériel est AUSSI certifié, et cela prends du temps de dérouler LES campagnes d'essai dessus.
• Dans tous les cas, le matériel doit être au minimum en tenue industrielle, souvent plus, et doit avoir fait un minimum ses preuves auparavant. On n'achète pas le dernier joujou à peine débuggé pour l'intégrer direct sur des éléments critiques.

Bref, quand on livre un produit, c'est sur du matériel (relativement) ancien de façon systématique. Et que l'on a commencé à construire dès le début du projet, avec "ce qui est disponible sur le marché".

Ca veut dire quoi alors ??

Ce que j'ai écrit : quand tu veux un footprint minimal et/ou des performances maximales, le bas niveau est toujours plus adapté. Si ces deux contraintes n'ont plus aucun poids sur le développement, alors tu peux choisir ce que tu veux comme langage (y compris du très haut niveau) sans impératifs d'implémentation.

[ZoinX]

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.

Genre un for (i = 0; i < tableau.size; ++i) avec un tableau qui grossit rapidement, ça fera pas une boucle infinie comme le foreach ?

[Mac LAK]

Je rejoins un peu ce qu'a dit alex_pi, mais tu es tellement ancré dans ton monde de l'embarqué que tu en oublies que dans le cas d'un hardware PC standard, doubler la puissance du hardware (soit dit en passant, la différence de perfs entre les langages bas niveau et les meilleurs langages haut niveau est bien moindre qu'un facteur 2...) coûte généralement infiniment moins cher que doubler le temps ou les effectifs de développement (ce qui est à mon avis un facteur réaliste de gain de temps entre coder en bas niveau et haut niveau), en particulier pour les gros projets.

Quel hardware ? Le gros PC surgonflé acheté "à peine" 3000 euros ?
J'utilise des cartes CPU qui valent quasiment 5000 euros l'unité... Juste un CPU, de la RAM, des liens de communication et un bus : loin d'être quelque chose d'autonome... Et il y en a plusieurs par produit !!

Doubler la puissance ? Cela a un coût monumental, et ça n'accélère pas le développement logiciel en plus, car cela double (au moins !!) le nombre de machines à gérer... Donc, les problèmes de synchronisation entre tout ça explosent littéralement, rendant le projet au final plus coûteux en hard ET en soft.

Également : quand tu as un produit qui tire plusieurs milliers de watts pour fonctionner, tu commences aussi à penser au coût de l'utiliser, on a AUSSI des contraintes à ce niveau, même si elles ne concernent que rarement le logiciel... Tu brancherais un de nos produits chez toi, ton compteur disjoncterait immédiatement, tu en as conscience ?

Paradoxal ? Non. Simplement le fait que l'on n'utilise pas de composants "grand public", mais du matériel très spécifique... Peu de choix, donc, et prix élevés. C'est comme si, pour toi, tu n'avais en serveur que des supercalculateurs : tu crois vraiment que tu jouerais alors à "doubler" le hard juste pour le confort ?


De plus, plusieurs ont fait remarquer que le coût d'exploitation explose également, et pire : le MTBF du produit global baisse si l'on rajoute des éléments dedans (ce qui est mon cas, car doubler la puissance = doubler le nombre de cartes, on utilise déjà les CPU les plus puissants disponibles). Donc, on augmente le taux de pannes, les stocks de spare, les coûts de maintenance, etc.

Complètement irréaliste, donc. "Doubler" le hard n'est pas toujours possible, encore faut-il comprendre pourquoi ça ne l'est pas toujours, et pourquoi l'optimisation logicielle est alors indispensable pour effectuer toujours plus de traitements et de fonctions...

Genre un for (i = 0; i < tableau.size; ++i) avec un tableau qui grossit rapidement, ça fera pas une boucle infinie comme le foreach ?

É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.