Conception et r�alisation de programmes hautes performances et/ou s�rs

Bonjour � tous,

Je vous propose de vous exprimer ici au sujet des crit�res � respecter pour concevoir et coder des programmes "rigoureux"... histoire de sortir du train quotidien des hello world, ou des projets o� le langage n'est pas important tant qu'il est orient�-objet plein de webservices

Pour cela, il me semble utile d'orienter cette discussion sur des axes tels que :

• la rigueur du codage employ�e
• le choix d'un sous-ensemble d'un langage
• la rigueur d'un syst�me de type
• les possibilit�s de v�rification formelle
• les contraintes "incompressibles" de certains syst�mes embarqu�s et/ou temps r�el

cette liste n'est pas exhaustive bien �videmment...

� tous les participants


Attention

1. � moins que vous ne demandiez de plus amples explications sur un point pr�cis, poster dans cette discussion est strictement r�serv� aux personnes qui estiment avoir une expertise ou une exp�rience int�ressante � partager
2. tous les propos HS (m�me techniques) seront supprim�es

Ada est un langage qui :

• A �t� le premier langage objet norm�,
• Est une r�f�rence en mati�re de code s�curitaire tout en supportant les contraintes temps r�el,
• Permet de faire de la programmation parall�le m�me si l'OS ne le supporte pas nativement,
• Impl�mentait la g�n�ricit� bien avant C++ et les langages manag�s,
• Poss�de une syntaxe non ambig�e,
• Peut permettre la preuve formelle,
• Te permet aussi d'avoir des processeurs complexes dignes de ce nom (VHDL),
• Est plus connu (et plus utilis�) que quelques "beaux" langages sortant finalement assez peu des labos ou niches restreintes.

Selon moi, un GC, c'est la porte ouverte au je-m'en-foutisme sur la lib�ration m�moire, et la notion de pointeur reste importante quoi que l'on dise : il est fondamental de comprendre ce que c'est, m�me si c'est pour �viter de l'utiliser derri�re (en fonction de ses go�ts personnels et de ce que l'on veut faire en programmation bien s�r).

Envoy� par alex_pi

Je ne comprends pas... D'un cot�, tu es contre le GC parce que �a inciterait � trop se reposer sur la machine, mais de l'autre, tu veux du typage statique.

Le typage statique demande un minimum de r�flexion de la part du d�veloppeur... Et plus il est strict, plus il doit r�fl�chir.

Envoy� par alex_pi

Ca n'insiterait pas � ne pas r�fl�chir et � juste faire confiance au typeur ?

Justement : c'est un �chec � la compilation, et non pas � l'ex�cution, qui se produit avec un typage statique... Les erreurs de typage dynamique sont en g�n�ral assez infectes � lever, et dans le pire des cas on a un d�butant qui ne comprends m�me pas la diff�rence entre un nombre (variable enti�re) et sa repr�sentation textuelle (variable cha�ne contenant la repr�sentations ASCII du nombre en question)...

La plupart des langages ont un GC "global" au programme, c'est � dire que l'allocation se fait dans une zone r�serv�e par le runtime... Une fuite m�moire peut exister, certes, mais sans mettre en p�ril le syst�me d'exploitation. Ce n'est pas "propre", certes, mais c'est un moindre mal.

De l'autre c�t�, il y a de bonnes habitudes, parmi lesquelles on a :

• Documenter son code,
• Le tester un minimum s�rieusement,
• Savoir � l'avance ce que l'on va faire, et non pas "bidouiller" en avan�ant � t�tons,
• V�rifier la lib�ration de ce que l'on a allou�.

Envoy� par alex_pi

Quand on voit le faible nombre de programmeur C qui utilisent des outils comme Valgrind, et le nombre incroyable de mem leak dans les programmes de tous les jours, j'avoue que �a me fait douter sur le fait que "programmer sans GC fait qu'on fait plus attention � la gestion des ressources"..

C'est un fait.
Moi aussi, je connais h�las trop cette situation...

Envoy� par alex_pi

Et en plus, �a interdira un paquet d'algorithme ou de paradigme parce qu'il n'arrivera pas � faire une gestion manuelle de la m�moire l� dessus.

Lesquels ? L'algorithmique, �a s'apprend par le commencement, pas par la fin... Tu arrives � accepter, toi, qu'un stagiaire passe une heure � trouver une librairie pour faire un tri au lieu de l'impl�menter lui-m�me ? Surtout quand �a porte � l'origine sur un tableau d'une vingtaine d'�l�ments, tri� une seule fois ?

Envoy� par alex_pi

Est ce que devoir avoir compris les magic pointeur avant de coder est vraiement indispensable...

Utiliser les "smart pointers" est n�faste en soi pour un d�butant, car cela le fait ignorer un m�canisme crucial qui n'existera pas toujours sur les plate-formes qu'il sera amen� � utiliser. L'embarqu� se porte bien, tr�s bien m�me... Et l� dessus, tu as rarement une usine � gaz type JRE pesant plus lourd que la capacit� m�moire disponible pour faire n'importe quoi n'importe comment... Et de toutes fa�ons, les performances exig�es mettent hors concours tout ce qui n'est pas langage compil� natif.

Or, � force d'apprendre le d�veloppement "fa�on assist�", tu vois de moins en moins de d�veloppeurs r�ellement comp�tents d�s qu'il s'agit de d�veloppement bas niveau, temps r�el ou embarqu�... Certes, ils savent faire de belles IHM en Java et ouvrir tout plein de communications TCP/IP en m�me temps, ou se connecter � une BDD. Mais ils sont pas foutus de faire un syst�me d'acquisition temps r�el, un driver ou un module exigeant des performances s�v�res.

Envoy� par alex_pi

Quoi ?? "Langage de haut niveau" ne veux pas dire performance catastrophique ! Il faut arr�ter avec �a...

Preuves ? Tu as un programme Java, Haskell ou OCaml (un minimum complexe bien s�r) qui tourne aussi vite que son �quivalent C/C++, � comp�tence de d�veloppeur �gale bien entendu ?

Envoy� par alex_pi

qui ont des perfs de l'ordre de 1,5 � 2,5 fois plus lent que C.

... Ce qui est un gouffre dans le domaine du temps r�el ou de l'embarqu�, et un surco�t colossal sur le mat�riel pour l'adapter � certains runtimes.

Envoy� par alex_pi

Tu nous dis que �a �limine tout une palanqu� de domaine o�, si je comprends bien, il faudrait tout g�rer � la paluche pour avoir la moindre chance d'obtenir un r�sultat probant. Permet moi d'en douter

Tu en seras plus convaincu en devant g�rer plusieurs liens Ethernet gigabit � plein d�bit, par exemple... Ou en devant acqu�rir deux ou trois mille signaux chaque milliseconde, et les traiter au passage, et ceci sur plusieurs cartes CPU en m�me temps.
Mon unit� de calcul "pr�cise", c'est la MICROseconde... La milli, c'est mon unit� "macroscopique", celle "de base".
Et quel que soit le cas, la charge CPU doit �tre mesur�e, et rester sous les 66% de fa�on � assurer les pics de charge.

Ce n'est absolument pas le m�me monde. Et dans le mien, les langages "usines � gaz" n'ont pas leur place avant des d�cennies, et encore !! Car quel que soit le cas, les gens voudront toujours faire cracher le moindre bout de puissance � ces machines...

Envoy� par alex_pi

Pour le temps r�el, il existe des GC "temps r�el", c'est � dire ne consommant pas plus que N milisecondes par tour de GC, et M milisecondes en tout par secondes.

Des MILLIsecondes ?? Et je perds mes signaux, moi, pendant que ton GC fait mumuse ?

Envoy� par alex_pi

Pour le r�seau, il me semble quand m�me qu'Erlang n'est pas tout � fait absurde comme option. De fa�on anecdotique, acebook l'utilise pour son chat par exemple, mais surtout, il est tr�s utilis� entre autre par Erikson et bien d'autres. Et pourtant, c'est un langage fonctionnel.

Je te parle de "remplir" des liens Gigabit, moi... Et oui, y'a un pluriel.

Envoy� par alex_pi

Pour l'imagerie et le calcul, je te conseille de jeter un �il � ce que fait le labo de York l� dessus, notamment des papiers comme celui ci : http://eprints.whiterose.ac.uk/5000/ . Ils sont capable de g�rer des terra de donn�es avec Haskell et de les afficher franchement joliment (j'ai pu voir une d�mo il y a un an de �a, c'est vraiment chouette.)

Je n'ai pas dit que certaines choses �taient impossibles avec des langages de haut niveau... Juste que ce n'�tait pas applicable dans certains domaines.

Faire une belle image ? Oui, et alors ? Haskel est-il capable, par exemple, de traiter un flux vid�o en temps r�el ? Si oui, � quel pourcentage de charge CPU par rapport � du C/C++ ? Et pour quelle consommation m�moire ? Quel est la taille de l'empreinte sur la m�moire de masse ?
Ces points conditionnent le co�t direct (en terme de CPU, RAM, m�moire Flash) d'une carte de d�codage... Et donc de son prix ! Et en g�n�ral, si c'est une production de s�rie, le co�t du logiciel devient vite d�risoire par rapport � celui du mat�riel, ce qui fait que le surco�t de temps de d�veloppement du C/C++ devient n�gligeable.

Envoy� par alex_pi

Et pour l'embarqu� ? Prenons l'exemple des r�seau de capteurs.

Attention, l� : un capteur, ce n'est pas forc�ment quelque chose contenant du logiciel (c'est m�me rarement le cas). De plus, il est tr�s courant en automatisme d'avoir des automates de centralisation, qui permettent de s'affranchir du bus de terrain au profit d'un m�dium plus "courant" et, surtout, plus r�pandu dans l'informatique classique.
Typiquement, tu vas avoir un automate qui servira de passerelle CAN / Ethernet, programm� en C/C++, et qui permettra de d�charger le PC de supervision de la phase d'acquisition. L'automate est cadenc� sur le bus de terrain, en acquisition permanente.
Et c'est souvent transparent pour le PC de supervision, tout comme cela permet d'exploser les limites de bande passante des bus de terrain en ne polluant pas la BP d'un sous-r�seau avec le trafic "inutile" d'un autre sous-r�seau.

Ceci ne change absolument pas le fait que la plupart des PC de supervision sont programm�s avec des langages de haut niveau, d'ailleurs... Mais l'acquisition des donn�es des capteurs est en g�n�ral hors de leur port�e vu les contraintes temporelles, ils les r�cup�rent donc "en bloc" avec un tr�s l�ger diff�r�, les automates passerelles �tant, eux, programm�s pour r�agir instantan�ment � certaines conditions ("arc-r�flexe" avant d'informer la supervision d'un probl�me)...

Envoy� par alex_pi

En m�me temps, outre java-card, je ne connais pas beaucoup de technologie embarqu� qui ont des certifications allant de EAL4 � EAL7 pour certaines parties

Moi, j'en connais plein... Certifications SIL4, DO178-B, etc, tous en C ou en Ada.

Envoy� par alex_pi

Pour le calcul ? Prenons l'exemple de la crypto. M�me la NSA fait le paris du langage de haut niveau : http://swik.net/nsa+cryptol

Langage de MOD�LISATION... Pour �tre derri�re impl�ment� notamment en VHDL (plus bas niveau, tu meurs) et C. La partie Haskell reste, � mon sens, anecdotique : si c'est pour crypter un mail, le temps d'ex�cution n'est pas critique en effet.

Envoy� par alex_pi

m�me au contraire quand je vois � quel point il est simple de faire crasher Amarok2 en cliquant un peu trop vite.

Pas de probl�mes avec WinAmp, pour ma part... Et ce serait �tonnant qu'il ne soit pas en C/C++ !
Je n'aime pas Unix, ni Linux : je dois avoir la scoumoune avec, faut croire, mais je fais exploser les Linux � la cha�ne. Je trouve toujours crevant de "tuer" un XTerm en faisant un "cat" d'un fichier binaire dedans, pour ma part...

Envoy� par alex_pi

Mon gestionnaire de bureau, je pr�f�rerais qu'il soit �ventuellement un poil de cul moins r�actif mais en contre partie crash moins souvent (KDE 4.2 n'est vraiment pas au point...).

L� encore, je n'ai pas de soucis avec le GDI Windows... Et celui d'XP n'est pas en C#, hein...

Envoy� par alex_pi

Le probl�me de faire du bas niveau pour d�buter, c'est qu'apr�s, on reste toute sa vie persuad� qu'il n'y a pas d'autres moyens pour produire du code efficace, alors que les compilos font des *vraies* merveilles (allez, encore un exemple ! http://www.cse.unsw.edu.au/~dons/papers/CLS07.html ) et qu'il existe plein de DSL (domain specific languages) de haut niveau et de grande qualit�.

Un programme est �crit pour effectuer une action pr�cise : c'est son but premier, le "non n�gociable".
Ensuite, tu as deux choses � consid�rer : le temps de d�veloppement, et le temps d'ex�cution. Le premier est crucial dans certains domaines o� un programme n'est ex�cut� qu'une ou deux fois, mais il faut le r�sultat apr�s le moins de temps possible, quitte � passer autant de temps en ex�cution qu'en d�veloppement. Les langages de haut niveau ont leur place ici.
Le deuxi�me, c'est le temps d'ex�cution, qui dans d'autres domaines sont totalement fondamentaux, car le programme est �crit une seule fois, mais est ex�cut� des millions de fois... Le temps de d�veloppement est n�gligeable par rapport au temps d'exploitation, et c'est le royaume des langages bas niveau o� la performance est le seul crit�re accept�.

Entre les deux, tu as les petits softs ex�cut�s sur stations de travail personnelle, plus ou moins souvent, et qui peuvent �tre d�velopp�s aussi bien en C "hardcore" qu'en langage de tr�s haut niveau. Car l'utilisateur veut alors juste la FONCTION, peu importe que le programme s'ex�cute en 3 ms ou en une seconde, tant que �a reste "rapide" � l'�il humain.

Mets un jour les pieds dans l'informatique industrielle, tu verras alors que les contraintes n'ont absolument rien � voir avec celles que tu connais...

Envoy� par alex_pi

Et �tre contraint � le faire d�s le d�part, c'est s'exposer � ne JAMAIS d�couvrir un gros paquet d'algorithme et de structure de donn�e qui ne tol�rent pas la gestion manuelle de la m�moire (sauf �ventuellement les "smart pointers"), comme toutes les structures de donn�es persistantes � partage implicite. Encore une fois, je pr�f�re que le d�butant explore un maximum des possibilit�s offertes, quitte � se limiter le jour o� il est oblig� d'utiliser un langage bas niveau � gestion manuelle des ressources.

Qui peut le plus peut le moins : je n'ai JAMAIS vu un d�veloppeur "bas niveau" ne pas r�ussir � ma�triser un langage de plus haut niveau... Et, souvent, mieux que quelqu'un qui a d�marr� avec (le GC, c'est bien, mais lib�rer soi-m�me, c'est encore mieux, �a �vite les pics de charge et les micro-blocages le temps de lib�rer le bouzin).

Par contre, la r�ciproque est souvent fausse...

Envoy� par ZoinX

J'ai appris � programmer sur des langages de haut niveau, et pourtant j'ai toujours r�ussi � programmer en C sans avoir trop de probl�mes li�s � la m�moire.

J'aime bien le "sans avoir trop de probl�mes"... Normalement, c'est "jamais", tu sais ?

Envoy� par ZoinX

�a ne me fait pas oublier d'appeler les m�thodes Dispose() de mes objets.

Sauf qu'avec un GC, si tu oublies, �a n'a pas de cons�quences. Sans un GC, c'est critique, et les mauvaises habitudes sont rapides � prendre... Trop rapides, d'ailleurs.

Envoy� par ZoinX

Si tu apprends *correctement* un langage haut niveau

C'est l� que le b�t blesse, justement : le "correctement" semble plut�t rarissime.

Envoy� par ZoinX

Par contre �a m'a permis de passer bien plus de temps � apprendre de bons algorithmes et � utiliser les subtilit�s des langages de haut niveau au lieu de le passer � d�bugger des segfaults.

Je connais les m�mes algorithmes, pour en avoir impl�ment� quelques uns d'assez velus. Les langages de haut niveau n'y sont absolument pour rien...

Envoy� par ZoinX

Si des gens se sont emmerd�s � cr�er des langages de haut niveau, c'est pour que nous puissions les utiliser pour impl�menter rapidement des algorithmes p�chus au lieu d'allouer notre m�moire � la main.

Tu as raison sur ce point : c'est pour faire un programme rapidement que ces langages existent. Mais ce n'est absolument pas pour qu'ils soient performants, ni donner de "bonnes" habitudes de programmation, cf. mon post du dessus.

Envoy� par alex_pi

Parce que moi, quand je regarde un mec qui a d�but� en bel imp�ratif bien main dans le cambouis et qui tente de faire du Caml ou du Haskell, le r�sultat n'est pas mauvais, il est catastrophique. Parce qu'ils pensent optimisationnnnnnnn avant de penser correction et lisibilit� de l'algo.

cet avis est certes tout aussi cat�gorique, et donc certainement aussi erronn� que celui de Mac_Lak, mais je pense qu'il faut quand m�me essayer de ne pas tout m�langer... a priori toute personne ouverte d'esprit, et faisant preuve d'un minimum de bonnes volont�s, comprendra rapidement les concepts d'un nouveau paradigme, et seulement apr�s � force de pers�v�rance r�ussira � obtenir un r�sultat potable hors d'un simple cas d'�cole

Envoy� par ZoinX

Je suis tout � fait d'accord avec �a. Sauf que 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.

Je ne sais pas pour toi, mais pour ma part, j'avais des cours d'algorithmique qui n'�taient s�rement pas faits en m�me temps que les cours de programmation... Les deux choses n'ont rien � voir, du moins dans un premier temps.

Envoy� par ZoinX

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.

Et t'as alors un mauvais d�veloppeur "bas niveau"... Le genre qu'on ne peut laisser seul, et qui fait plus le boulet que le coll�gue. Que crois-tu ? Que c'est "facile" � apprendre, qu'on peut le faire "sur le tas" comme �a, en un clin d'oeil ?
Non : sur le tas, � partir de th�ories de langages de haut niveau, tu n'apprends pas � d�velopper, mais soit � bidouiller pour franchir les barri�res syntaxiques, soit � faire des usines � gaz. En g�n�ral, c'est les deux en m�me temps.

Envoy� par ZoinX

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 en quoi le langage de haut niveau permet-il d'avoir un algorithme qui ne serait pas impl�mentable en C/C++ ?

Envoy� par ZoinX

C'est pour �a qu'il est beaucoup plus important d'apprendre � l'�cole l'algorithmique plut�t que l'optimisation des performances gr�ce aux langages bas niveau.

Ce n'est s�rement pas � l'�cole que j'ai appris l'optimisation... Ce serait plut�t par obligation professionnelle, les clients �tant rarement comiques au sujet des performances.

Envoy� par ZoinX

Parce que l'algorithmique permet des gains de performances incomparables aux petites optimisations sp�cifiques � un langage.

Merci de m'apprendre mon m�tier, hein... S�r, j'ai jamais appris ce qu'�tait une complexit� !

Envoy� par ZoinX

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.

Dans une bo�te � viande, peut-�tre. Dans ma bo�te, on exigera les deux, et nous ne sommes pas les seuls � agir ainsi.

Envoy� par ZoinX

Et coup de bol, c'est aussi la plus int�ressante et la plus p�dagogique, et celle qui donne en g�n�ral le plus envie aux �tudiants de se lancer dans l'informatique.

Tiens, � ce sujet, tu remarqueras que la syntaxe usuelle (=la plus courante) des algos est extr�mement proche du Pascal/Ada... Tiens donc...

Envoy� par ZoinX

Or tu auras du mal � justifier qu'un langage de bas niveau soit plus adapt� (ou m�me aussi adapt�) qu'un langage de haut niveau � l'apprentissage de l'algorithmique.

Donc, je vais �tre direct et brutal : apprends � lire.

La d�fense du C/C++ que je fais, c'est afin de montrer que si ce ne sont pas des langages "visibles", ils restent n�anmoins essentiels � tout point de vue, et forment une tr�s vaste partie de l'informatique... Certes, c'est plus du march� cach� qu'autre chose, mais cela reste quelque chose d'�norme.

Le monde du temps r�el, de l'embarqu� et des optimisations, c'est un monde invisible pour la plupart des gens. Reste quand m�me le fait que sans eux, ton langage de haut niveau serait sur du papier uniquement.