[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gulliver] c'est de l'heure de la sieste chez debian


From David MENTRE <david dot mentre at gmail dot com>
Subject Re: [gulliver] c'est de l'heure de la sieste chez debian
Date Tue, 10 Nov 2009 16:42:03 +0100

Bonjour David,

Le 9 novembre 2009 21:25, David Fort <popo dot enlighted at free dot fr> a écrit :
> C'est bizarre je ne croyais pas m'être inscrit sur la liste de Trolls ;-)

Tu devrais, le meilleur est pour troll.

> Mais pour contredire un peu tout ça, la fameuse gestion formidable des
> exceptions ne se fait pas sans coût.

Évidemment. Mais tu auras sans doute remarqué qu'on ne programme plus
sur un ordinateur avec un Z80 à 1MHz. ;-)

> Et on obtient soit une augmentation de
> consommation CPU, soit une augmentation mémoire, soit une augmentation de la
> taille du code, voire les 3 quand c'est mal fait.

Et quand c'est bien fait le surcout est faible voire négligeable, cf.
le compilateur OCaml où les exceptions peuvent être utilisées dans une
boucle de contrôle (par exemple sortir d'une boucle for).

> Pour évoquer le bug, je crois qu'on peut résumer ça à: "le fait qu'on ai un
> déréférencement de pointeur NULL vient du fait que le kernel est en C".
> Tout est dit :

Malheureusement oui. :)

> *si le kernel était codé en ADA ou en JAVA, ce ne serait pas possible
> d'exploiter cette faille. On aurait la fameuse exception cité avant,
> d'ailleurs on aurait sans doute un plantage du kernel un peu plus loin, car
> le propre des bugs c'est de mettre le programme dans un état inattendu et
> peut-être même que le résultat serait pire (corruption des caches disques,
> altération de mémoire un peu plus loin, etc..)

Non. Si tu as un langage et son runtime bien conçus (par ex. Ada), une
erreur du programme ne dois *jamais* entrainer une corruption mémoire.
Les cas d'erreur sont automatiquement détectés, dynamiquement à
l'exécution ou idéalement statiquement à la compilation.

Si tu as une erreur, elle est gérée par le runtime et in fine par le
programme (ou pas, cf. Ariane 501).

> * Effectivement le langage C a ce désavantage qu'on peut facilement faire
> des bêtises et que la partie la plus visible de ce désavantage c'est un *0 =
> <code malicieux>. Mais c'est aussi un de ces avantages, car il permet de
> faire de optimisation "à la main", on pourrait citer par exemple le switch à
> chaud des capacité SMP de spinlock.

Tu peux expliciter ce que tu appelles le « switch à chaud des capacité
SMP de spinlock » ?

Ada permet d'écrire du code bas niveau (il a été fait pour ça), sans
pour autant sacrifier généricité (cf. les modules paramétrés comme en
Eiffel) ni cohérence (toutes les erreurs sont gérées par exception,
pas comme en C++).

Bien évidemment, dans tout système bas niveau, il y a un peu
d'assembleur écrit à la main. Mais c'est l'exception plutôt que la
règle.

> * Aujourd'hui les approches systématiques qui permettrait "à froid" de
> générer du code sans segfault possibles sont du domaine de la science
> fiction, ou bien ne sont pas performantes (ce qui est le cas de codes
> embarqués dans les fusées et autres engins volants).

Assertion sans fondement.

Pour prendre un exemple, le compilateur compcert de Xavier Leroy
programmé en Coq compile un code C qui a un temps d'exécution
équivalent à gcc en -O1 ou -O2
(http://gallium.inria.fr/~xleroy/publi/compcert-CACM.pdf). C'est
largement utilisable pour le temps réel critique et même la plupart
des programmes. Ce compilateur te garanti par construction que tout
programme C sera correctement compilé en un assembleur PowerPC
equivalent (bug pour bug diront certains ;-). Et le temps de
compilation avec compcert est aussi raisonnable.

Sinon, la performance est aussi en mythe. En temps réel dur (càd si je
loupe la deadline, j'ai mort d'homme comme dans les avions ou les
trains), comme on a du mal à évaluer le temps d'exécution au pire cas
des programmes (notamment dû aux effets de cache), on utilise des
processeurs surpuissants pour les programmes considérés. Quand à ton
Quad Core, il passe son temps à attendre.

> Pour donner un ordre
> d'idée on peut aller voir "Unladden Swallow" une implémentation de python
> (pas de segfault en python) qui génère à la volée du code machine "abstrait"
> pour avoir des perfs acceptables sur le CPU cible. Ca reste un projet du
> future !

Ouais enfin Python n'est pas pour moi la référence en terme de langage
vérifié et vérifiable. :-) (normal, il n'est pas fait pour ça mais est
par contre idéal pour le prototypage rapide)

> * Pour finir, les bugs trouvent plus souvent leurs sources entre les deux
> oreilles des concepteurs, que dans le langage qui a traduit les idées. Coder
> au niveau kernel nécessite d'avoir une vue d'ensemble de l'objet que peu de
> contributeurs ont, et inévitablement des erreurs passent au travers des
> relectures les plus attentives.

Oui. C'est pour ça qu'on développe des techniques qui permettent
d'exprimer ces idées en expressions informatiques compréhensibles et
vérifiables par une machine. Les assertions et invariants d'Eiffel, de
la Méthode B ou de Spark Ada en sont un bon exemple.

> Je n'ai plus la source, mais la réponse à "Mais pourquoi Linux n'est pas
> écrit en C++ comme windows ?" se trouve facilement sur le net, avec des
> arguments étayé qui je crois n'ont pas perdu de leur fraicheur.

Parce que le C++ n'apporte pas vraiment au niveau vérif (tout au plus
un type bool distinct de int, les exceptions) et garde tous les
inconvénients de C (arithmétique de pointeurs incontrôlée, cast sous
le tapi, chaines de taille non contrôlée, surcoût du runtime, etc.).

J'ai jamais dit que C++ était la référence. ;-)

Amicalement,
d.