En effet, j'ai commencé les manips sans avoir en tête de le raconter, et j'ai reconstitué le début de l'histoire ensuite, avec l'historique des commandes.
De mémoire, j'avais ouvert gparted au début (et aussi un petit outils graphique lvm : system-config-lvm, pour me rassurer) et j'ai du faire une unique partition primaire sur le SSD avec gparted.
Bon, voilà, j'ai fais un script qui déroule des "make" en balayant les trois paramètres possibles sur mon kernel : noop, deadline, cfq.
J'ai pris pour "stresser" un peu mon SSD ce qui traînait dans mon home, la recompilation des exemples de la libgtkada, ce qui génère un usage intensif de gcc.
Les résultats sont anormalement identiques, en particulier le temps perçu par l'utilisateur (voir première colonne ci-dessous).
IO scheduler (elevator)
Real (s)
User (s)
Sys (s)
Nb of file system inputs
Nb of file system outputs
Average total memory (in KB)
Nb of voluntary context-switch
noop
27.71
25.48
1.51
0
17048
0
1050
noop
27.69
25.35
1.62
0
17048
0
1046
noop
27.71
25.38
1.60
0
17056
0
1046
noop
27.68
25.42
1.54
0
17048
0
1052
noop
27.69
25.49
1.48
0
17056
0
1050
deadline
27.69
25.38
1.59
0
17056
0
1047
deadline
27.65
25.35
1.59
0
17048
0
1045
deadline
27.69
25.44
1.52
0
17048
0
1050
deadline
27.72
25.48
1.50
0
17048
0
1050
deadline
27.72
25.35
1.62
0
17048
0
1045
cfq
27.74
25.37
1.64
0
17048
0
1049
cfq
27.69
25.49
1.48
0
17048
0
1044
cfq
27.59
25.22
1.68
0
17048
0
1044
cfq
27.63
25.41
1.50
0
17048
0
1043
cfq
27.56
25.38
1.48
0
17048
0
1042
Ça me laisse perplexe.
J'y vois deux explications possibles :
- ma façon de changer l'algo n'est pas prise en compte au vol par le kernel, et donc j'ai fait tous les tests avec le même algo;
- ces optimisations n'ont réellement aucun impact sur des systèmes aussi petit que les notre, et même une grosse compilation ne secoue pas vraiment le bouzin, car les caches du kernel, le tmpfs en RAM, le cache du SSD et son propre réordonnancement des écritures aplatissent les résultats.
Mon programme de test (qui fait donc 27 secondes de compilations), n'est sans doute pas assez gros.
D'un autre côté, j'ai trouvé un article qui comparait les temps de compilations du kernel, et pareil, il n'y avait pas de différences notables : Linux I/O schedulers benchmarked - anticipatory vs CFQ vs deadline vs noop
Et là, on parle de 9 minutes de compilation…
Des idées?
De mon côté, il ne reste plus qu'a le refaire tourner avec noatime, pour voir.
Le voici, libre à vous de le faire tourner chez vous :
#! /bin/bash
#
#------------------------------------------------------------------------------
# Lionel Draghi, 1 janvier 2014, v0
#
# Ce script permet de comparer l'impact du choix de l'algo d'ordonnancement du
# scheduler d'IO sur une tache quelconque (il faut juste avoir un "make" et un
# "make clean" executable à l'endroit du test).
#
# Attention :
# 1 - il faut adapter le device X dans /sys/block/X/queue/scheduler
# (ici "sda") à sa propre situation;
# 2 - il faut donner les droits en écriture à l'utilisateur courant sur le
# fichier en question : sudo chmod o+w /sys/block/X/queue/scheduler.
#
# Le fichier de résultat s'importe directement dans votre tableur préféré.
#------------------------------------------------------------------------------
# création de la ligne de header : elle doit bien sûr correspondre au paramètre
# "--format" passé ci-dessous à la commande time.
echo "IO scheduler (elevator=);\
Real (s);\
User (s);\
Sys (s);\
Nb of file system inputs;\
Nb of file system outputs;\
Average total memory (in KB);\
Nb of voluntary context-switch" > $0.log
for i in noop deadline cfq
do
echo $i > /sys/block/sda/queue/scheduler
# pour vérifier qu'on a effectivement changé l'algo :
echo
echo
echo '-----------------------------------------------------------------------------------'
cat /sys/block/sda/queue/scheduler
echo '-----------------------------------------------------------------------------------'
echo
echo
for j in 1 2 3 4 5
do
make -s clean
/usr/bin/time --output=$0.log --append --format "$i;%e;%U;%S;%I;%O;%K;%w" make -s
done
done
Et voilà, c'est le problème quand on publie presque deux mois après avoir fait le travail : je ne me rappelle plus de tous les pourquoi des arbitrages.
Je n'ai en effet pas vu de référence à un autre logiciel que Mutt qui présenterait une dépendance à la date de dernier accès.
Si les bench de Ted Ts'o sont sans ambiguïté sur les gains en performance, j'aurai du faire en toute logique ce choix.
Bon, finalement, que se soit pour cette question ou pour celle de l'algo d'ordonnancement, il nous faut un bench.
J'adore cette façon d'employer le mot "intégrisme" quand on n'est pas d'accord avec une méthode d'évaluation ;)
En ce qui me concerne, ce n'est pas la méthode d'évaluation qui est en cause, c'est juste l'évaluation elle même.
Ludovic a déjà répondu point par point sur la page de l'article en question.
La réponse de Julien à Ludovic parle de mauvaises pratiques, comme un code volontairement confus et pas de CVS publique, et l'évaluation met en doute la GPL.
Il est très simple de vérifier que c'est faux :
GNAT est intégré régulièrement dans gcc : est-ce que accéder aux sources de gcc et à la mail list de gcc est un problème?
Pour les autres logiciels d'AdaCore, l'accès à chaque CVS est décrit sur ces pages, ainsi que la mail list correspondante : https://libre2.adacore.com/aws/ https://libre2.adacore.com/gps/ https://libre2.adacore.com/xmlada/ https://libre2.adacore.com/GtkAda/ https://libre2.adacore.com/polyorb/
Il y a bien sur des sociétés qui ne joue pas le jeu du logiciel libre mais essayent d'en profiter : alors laminer une boîte pour qui c'est presque une religion, et qui contribue depuis des années un code exemplaire au monde du libre me paraît bien injuste.
Et si vous doutez de la sincérité d'AdaCore dans cet engagement au point de qualifier de démarche marketing le sponsoring des RMLL ou l'adhésion à l'APRIL, demandez-vous juste quel intérêt elle peut bien y trouver, vu la nature de son business.
Il ne s'agit pas d'une réaction épidermique, je ne fait pas partie d'AdaCore et n'en ai pas d'actions. C'est juste pour vous donner des arguments.
Vous ne saviez pas tout sur GNAT, c'est pas grave. Reconnaissez juste que au vu de ces infos (en particulier bien sur la réponse de Ludovic), et au regard de vos propres critères, vous l'avez massacré.
Il peut (potentiellement) détecter beaucoup plus d'erreur que Java ou Ada à la compilation.
Que Java, je n'en doute pas. Que Ada me paraît être une bien plus belle performance.
Au passage, si tu les mets au même niveau, comme ta phrase peut le laisser penser, alors jette un coup d'oeil sur https://libre2.adacore.com/Software_Matters/, en particulier la présentation Programming in the Small: C/C++/Java Pitfalls & Ada Benefits
J'en recommande également la lecture à ceux qui pense que reprendre la syntaxe du C est un bon choix pour un nouveau langage.
Etant donné que nous sommes nombreux à considèrer la détection d'erreur à la compilation comme une qualité essentielle du couple langage/compilo, nous donner quelques exemples d'erreurs que ne détecte pas Ada ferait une excellente publicité pour Lissac.
Ada est de plus en plus remplacé par le C car personne ne connait Ada.
T'abuses, là!
C'est même plutôt le contraire : les propos éronnés sur Ada dans ces colonnes se font rares, je trouve que les allusions sont plus justes ces derniers temps. J'y vois preuve d'une meilleure connaissance (j'espère), ou au moins d'une meilleure reconnaissance.
C'est peut-être lié au fait qu'on a pas mal parlé du langage dans la presse du "libre" depuis 2005. Bravo au passage à Yves Bailly pour sa série d'article dans GNU/Linux mag, et à Etienne Baudin pour ses articles dans Login.
J'espère que d'autres articles exposeront les nouveautés d'Ada 2005.
Utiliser la syntaxe Pascal/Ada pour l'affectation plutot que celle du C me paraît assez absurde, le nombre de programmeurs Pascal/Ada se comptant sur les doigts d'une main..
Si la syntaxe provoque les erreurs, ce qui parait absurde c'est de ne pas la changer.
Et en l'occurence, c'est pas ça qui va t'amener les neurones dans la zone rouge lors de l'apprentissage d'un nouveau langage.
J'en prends un extrait : The mainstream state of the art revolves around lock-based programming, which is subtle and hazardous. We desperately need a higher-level programming model for concurrency than languages offer today; I'll have more to say about that soon.
<mode cynisme>
Encore un qui semble vachement au fait de l'état de l'art (son papier ne cite que Java). Je suis impatient de voir ce qu'il va nous pondre.
</fin du cynisme>
Ca me parait être l'occasion de rappeler que dans gcc, il y a un compilateur Ada, et que Ada propose un modèle de programmation parallèle d'une puissance inégalée.
Ces concepts sont intégrés depuis toujours dans le langage, ils ne s'agit pas d'une bibliothèque externe ou d'un concept minimaliste ajouté avec difficultés dans un langage pas du tout pensé pour ça.
En Ada, les taches ou les objets protégés sont des citoyens de première classe. Ils peuvent être manipulés comme beaucoup d'autres types. On peut par exemple déclarer un tableau de tache.
Si vous souhaitez faire un logiciel de calcul, de jeux, ou de traitement d'image, intégrant un tasking performant, basé sur un standard ISO, portable entre compilateur, portable entre OS, alors pas la peine d'attendre, c'est déjà dans gcc.
J'espère que la banalisation des dual-core augmentera l'intéret des développeurs pour Ada, qui permet d'écrire un code unique pour Linux/Solaris/Windows/etc., exploitant les ressources disponibles sur la machine, quel que soit le nombre de processeurs.
Je crois que l'on parle de deux choses différentes : l'optimisation du code et la conception d'un logiciel.
Au niveau optimisation, le processeur fait tout son possible pour explorer en avance de phase plusieurs chemins d'exécution, le compilateur va faire de son mieux pour détecter dans le code source des choses vectorisables, etc. etc.
Mais le parallélisme de l'application, par exemple les politiques d'ordonnancement ou d'accès aux donées partagées, si ce n'est pas décrit dans le code source, le compilateur ne peut pas l'inventer.
Non, Ada n'a pas été conçu par l'armée américaine. L'armée américaine a juste fait le constat de ce qu'elle utilisait (au début des anées 70) 450 langages différents, et que c'était un gouffre financier. Certains corps d'armées c'atait fait vendre un langage temps réel propriétaire, avec un seul compilateur, tournant sur un hardware spécifique. Le rêve de tout fournisseur, un client vérouillé!
Le DOD américain a donc réunit un collège d'expert, ouvert sur le civil et l'étranger (une grande première alors), pour faire non pas un langage mais un cahier des charges d'un langage.
Le cahier des charges mettait l'accent sur quelques points, comme une certaine universalité et la prise en compte des problème de génie logiciel apparaissant alors sur l'écriture des premier gros logiciel.
Ensuite, 5 équipe ont présenté leur travail, et c'est l'équipe verte, dirigé par Jean Ichbiah qui a gagné.
Ada est né ainsi, de parents civils, en gagnant un concours militaire.
Par contre, ce qui est plus gênant, c'est le manque de bindings (par exemple pour XSLT), et le manque de ressources d'aide sur le web...
Pour les bindings, c'est vrai.
Pour atténuer celà, on peut rappeler que l'interfaçage en général et l'interfaçage avec C en particulier est facile.
J'avais un collègue qui n'a pas hésité à faire vite fait un binding à xerces, pour gagner 20 secondes au chargement d'un gros fichier xml par rapport à xmlada, sur un outils sans importance.
Pour les ressources web, il y a http://www.adapower.com/(...) et http://www.adaworld.com.(...)
Tu y trouves pas mal de chose comme des exemples de code, ou plusieurs livres sur Ada sous license libre.
(J'ai un bon souvenir de Ada Distilled)
ça a de grosses conséquances sur la génération de code sûr (au sens de la sûreté de fonctionnement) pour des missions critiques comme les codes embarquées par exemple. Les autres méthodes de code sûr pour ce genre de tâches (Lustre et Esterel pour ne pas les citer) ont d'autres avantages mais ne servent jamais qu'à générer du code C à recompiler derrière.
Oui, Ada n'a pas de définition formelle, mais c'est quand même un des rares langages dont la définition soit à la fois suffisement complète et non ambigu pour que l'on puisse en extraire des sous-ensemble prouvable formellement, sans dépendance au compilateur.
Pour les autres langage de ce type, les outils doivent compenser les trous de sémantiques de la définition du langage par la connaissance du comportement constaté du compilateur. C'est vrai par exemple, même pour un sous-ensemble de C comme MISRA-C, pourtant spécifiquement dédié à ces applications critiques.
Par exemple, ses paradigmes objets ne sont pas classiques par rapports aux autres langages.
Tout à fait d'accord, c'est le point le plus inhabituel du langage.
Mais d'un autre coté, il offre tellement de caractéristiques uniques.
Au hasard, quel plaisir d'avoir un tasking complètement intégré dans le langage : pouvoir définir des types taches pas plus dificilement qu'une classe, déclarer un tableaux de 500 taches, etc.
Tout ça de façon portable, sans faire appel à la moindre API externe.
J'insiste sur le fait que cela a un cout à l'execution
Tout à fait, mais justement le bench montre que ce coût peut-être faible.
Par ailleurs, dans le cas de Ada, de nombreux checks sont fait à la compilation, car le source est sémantiquement riche. Ceci est sans conséquence au niveau du code généré.
Quand aux vérifications à l'exécution, tu as la possibilité de les enlever là ou tu le souhaite, soit par les options de compilation, soit directement par des pragmas dans le source. Ceci est utile par exemple lorsque qu'un outils externe te fournit une preuve formelle de ce que ces vérifiations sont inutiles.
Mais en fait, c'est rarement utile, car le compilateur fait un très bon boulôt d'optimisation.
Tu as donc le beurre et l'argent du beurre :
- vérif en abondance à la compil,
- vérif à l'execution pour le reste,
- performance quand il le faut.
Pour finir, il y a un compilateur Ada qui fait très fort car il ajoute de nombreux warnings et optimisations par dessus ce qui est imposé par le langage (et même des suggestions de corrections pour les erreurs bateau et les typos).
Et pour la chance du monde du libre, il se trouve que c'est justement GNAT, le compilo Ada de gcc.
Le fait de lancer trois fois le test fait que la JVM est encore dans la mémoire (si la machine n'est pas intensivement utilisée en parallèle du bench). La première fois tu vas la chercher sur le disque.
Alors je serai surpris que ca ne fasse pas une belle différence, même si ce ne sont pas encore les conditions idéales.
Je comprends bien ce que tu dis sur l'aprentissage.
Mais concernant le développement, il ne s'agit de rien d'autre que de ton temps : tu le gaspilles ou tu l'utilises.
Débuggez ou développez, that is the question.
La plupart des dev Ada utilisent leur debugger tous les trois mois. Ca parait incroyable, mais c'est la stricte vérité.
Et pour ta dernière phrase, je me félicite que les dev de LL ne fassent pas le même choix que les entreprises, car curieusement les entreprises ne sont que rarement rationnelles, et elles vivent dans la psychose de prendre du retard et ne pas être dans le "mainstream".
Tu as raison, j'en ai trop fait sur le bench, et les précautions pour éviter les trolls sont parfaitement inutiles sur ce genre de sujets. J'ai en fait commencé une réponse dans la discussion Java et OOo, mais ca m'embettait de participer à ce troll.
Alors, j'ai fais un article.
Toutefois, ce que tu dis est exactement la première moitié de la news. Ta conclusion sur la l'inutilité de C dans la plupart des développement moderne est exactement l'essence de l'article.
L'autre message que je voulais faire passer, c'est que les solutions "mainstream" ne sont pas forcément les meilleures, mais, bon, c'est si rassurant d'être dans la masse. Utiliser une solution originale demande d'être cultivé déjà rien que pour en avoir eu connaissance, encore plus pour bâtir un argumentaire comparatif (alors que si tu fais du C personne ne te demande rien).
Faut être un peu couillus ou associable, je trouve :-).
Tiens, sans le faire exprès je t'ai donné une réponse à ta question sur pourquoi C domine toujours outrageusement :-)
Tu as parfaitement raison, et c'est pourquoi le test est lancé trois fois de suite, et que seul le meilleur temps est retenu (tandis que pour la conso mémoire c'est la plus grande qui est conservé).
Ceci répond également partiellement a l'objection faite plus haut sur le désavantage des interpréteurs par rapport au test compilés : le désavantage est réel, mais pas si important que celà.
un code OCaml est beaucoup plus compact qu'un code C, ce qui ajoute encore à sa lisibilité et à sa facilité de compréhension
Attention à ne pas en faire une généralité : il n'y a aucune corrélation entre longueur et facilité de compréhension.
Fait lire un test même OCaml par un non informaticien, et le même test Ada dont le source est peut-être quatre fois plus long, vois ce qu'il comprend et tu en aura la preuve.
Personellement, je trouve ce critère tellement non significatif que je me demande ce qu'il fait sur ce comparatif.
Je VEUX faire un buffer overflow à cet endroit, et je ne comprend pas pourquoi je n'y arrive pas dans en Ada).
C'est une caractéristique essentiel d'Ada : tout est possible, y compris un buffer overflow.
Mais pour faire une goretterie pareille il faut faire un effort une fois. (Je me demande bien pourquoi, au passage).
Dans d'autre langage c'est pour éviter le buffer overflow qu'il faut faire des efforts... tout le temps.
L'esprit n'est pas le même, et ca fait une grosse différence.
Curieux je n'ai pas ce problème. Tu as fais un petit upgrade avant d'installer bootsplash? Il a pu y avoir des modifs.
Merci pour ton mail, ca m'a donné à réfléchir : c'est probablement du a ce que j'ai restauré la base de mon système avec une Knoppix.
Il y a quelques paquetages qui gardent l'empreinte Knoppix, entre autre sysvinit : je force la mise à jour vers une version Debian et je vais bien voir le résultat.
Si je ne poste plus rien dans les jours à venir, c'est que c'était une mauvaise idée :-)
Du moment qu'il trouve des bugs que le développeur peut confirmer ensuite, ce n'est pas inutile.
En général oui, mais pas toujours : pour une commande de vol électrique d'avion de ligne, il faut prouver que le logiciel est complètement correct.
Mais bon, comme passer d'un bon auxiliaire dans la chasse au bug à la preuve formelle du programme implique des changements considérables dans le processus et les outils de développement, ce n'est franchement pas applicable sur le kernel (et au logiciel libre en général, d'ailleurs).
En gros, je ne comprend pas trop [...] pourquoi c'est pas intégré dans le compilateur directement.
Le compilateur ne peut pas faire de miracle : en amont, il y a la définition du langage utilisé. Si la définiton est imprécise, et la sémantique de bas niveau, la tâche devient virtuellement impossible pour les outils d'analyse statique.
Alors à fortiori pour le compilateur dont ce n'est pas la vocation.
[^] # Re: juste, wouah, un journal qui vaut son pesant de caracteres.
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 3.
Merci, ça fait plaisir à lire!
[^] # Re: MBR sans partition
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 1.
Bien vu!
En effet, j'ai commencé les manips sans avoir en tête de le raconter, et j'ai reconstitué le début de l'histoire ensuite, avec l'historique des commandes.
De mémoire, j'avais ouvert gparted au début (et aussi un petit outils graphique lvm : system-config-lvm, pour me rassurer) et j'ai du faire une unique partition primaire sur le SSD avec gparted.
[^] # Re: noatime et deadline
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 2.
Bon, voilà, j'ai fais un script qui déroule des "make" en balayant les trois paramètres possibles sur mon kernel : noop, deadline, cfq.
J'ai pris pour "stresser" un peu mon SSD ce qui traînait dans mon home, la recompilation des exemples de la libgtkada, ce qui génère un usage intensif de gcc.
Les résultats sont anormalement identiques, en particulier le temps perçu par l'utilisateur (voir première colonne ci-dessous).
Ça me laisse perplexe.
J'y vois deux explications possibles :
- ma façon de changer l'algo n'est pas prise en compte au vol par le kernel, et donc j'ai fait tous les tests avec le même algo;
- ces optimisations n'ont réellement aucun impact sur des systèmes aussi petit que les notre, et même une grosse compilation ne secoue pas vraiment le bouzin, car les caches du kernel, le tmpfs en RAM, le cache du SSD et son propre réordonnancement des écritures aplatissent les résultats.
Mon programme de test (qui fait donc 27 secondes de compilations), n'est sans doute pas assez gros.
D'un autre côté, j'ai trouvé un article qui comparait les temps de compilations du kernel, et pareil, il n'y avait pas de différences notables :
Linux I/O schedulers benchmarked - anticipatory vs CFQ vs deadline vs noop
Et là, on parle de 9 minutes de compilation…
Des idées?
De mon côté, il ne reste plus qu'a le refaire tourner avec noatime, pour voir.
Le voici, libre à vous de le faire tourner chez vous :
[^] # Re: noatime et deadline
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 2.
Et voilà, c'est le problème quand on publie presque deux mois après avoir fait le travail : je ne me rappelle plus de tous les pourquoi des arbitrages.
Je n'ai en effet pas vu de référence à un autre logiciel que Mutt qui présenterait une dépendance à la date de dernier accès.
Si les bench de Ted Ts'o sont sans ambiguïté sur les gains en performance, j'aurai du faire en toute logique ce choix.
Bon, finalement, que se soit pour cette question ou pour celle de l'algo d'ordonnancement, il nous faut un bench.
Je m'y attelle!
[^] # Re: Evaluation de projets libres
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche QSOS ou comment gagner en objectivité dans l'évaluation et la sélection de logiciels libres. Évalué à 2.
En ce qui me concerne, ce n'est pas la méthode d'évaluation qui est en cause, c'est juste l'évaluation elle même.
Ludovic a déjà répondu point par point sur la page de l'article en question.
La réponse de Julien à Ludovic parle de mauvaises pratiques, comme un code volontairement confus et pas de CVS publique, et l'évaluation met en doute la GPL.
Il est très simple de vérifier que c'est faux :
GNAT est intégré régulièrement dans gcc : est-ce que accéder aux sources de gcc et à la mail list de gcc est un problème?
Pour les autres logiciels d'AdaCore, l'accès à chaque CVS est décrit sur ces pages, ainsi que la mail list correspondante :
https://libre2.adacore.com/aws/
https://libre2.adacore.com/gps/
https://libre2.adacore.com/xmlada/
https://libre2.adacore.com/GtkAda/
https://libre2.adacore.com/polyorb/
Il y a bien sur des sociétés qui ne joue pas le jeu du logiciel libre mais essayent d'en profiter : alors laminer une boîte pour qui c'est presque une religion, et qui contribue depuis des années un code exemplaire au monde du libre me paraît bien injuste.
Et si vous doutez de la sincérité d'AdaCore dans cet engagement au point de qualifier de démarche marketing le sponsoring des RMLL ou l'adhésion à l'APRIL, demandez-vous juste quel intérêt elle peut bien y trouver, vu la nature de son business.
Il ne s'agit pas d'une réaction épidermique, je ne fait pas partie d'AdaCore et n'en ai pas d'actions. C'est juste pour vous donner des arguments.
Vous ne saviez pas tout sur GNAT, c'est pas grave. Reconnaissez juste que au vu de ces infos (en particulier bien sur la réponse de Ludovic), et au regard de vos propres critères, vous l'avez massacré.
[^] # Re: Euh ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Que Java, je n'en doute pas. Que Ada me paraît être une bien plus belle performance.
Au passage, si tu les mets au même niveau, comme ta phrase peut le laisser penser, alors jette un coup d'oeil sur https://libre2.adacore.com/Software_Matters/, en particulier la présentation Programming in the Small: C/C++/Java Pitfalls & Ada Benefits
J'en recommande également la lecture à ceux qui pense que reprendre la syntaxe du C est un bon choix pour un nouveau langage.
Etant donné que nous sommes nombreux à considèrer la détection d'erreur à la compilation comme une qualité essentielle du couple langage/compilo, nous donner quelques exemples d'erreurs que ne détecte pas Ada ferait une excellente publicité pour Lissac.
[^] # Re: Euh ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
T'abuses, là!
C'est même plutôt le contraire : les propos éronnés sur Ada dans ces colonnes se font rares, je trouve que les allusions sont plus justes ces derniers temps. J'y vois preuve d'une meilleure connaissance (j'espère), ou au moins d'une meilleure reconnaissance.
C'est peut-être lié au fait qu'on a pas mal parlé du langage dans la presse du "libre" depuis 2005. Bravo au passage à Yves Bailly pour sa série d'article dans GNU/Linux mag, et à Etienne Baudin pour ses articles dans Login.
J'espère que d'autres articles exposeront les nouveautés d'Ada 2005.
[^] # Re: Euh ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 5.
Si la syntaxe provoque les erreurs, ce qui parait absurde c'est de ne pas la changer.
Et en l'occurence, c'est pas ça qui va t'amener les neurones dans la zone rouge lors de l'apprentissage d'un nouveau langage.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 8.
J'en prends un extrait :
The mainstream state of the art revolves around lock-based programming, which is subtle and hazardous. We desperately need a higher-level programming model for concurrency than languages offer today; I'll have more to say about that soon.
<mode cynisme>
Encore un qui semble vachement au fait de l'état de l'art (son papier ne cite que Java). Je suis impatient de voir ce qu'il va nous pondre.
</fin du cynisme>
Ca me parait être l'occasion de rappeler que dans gcc, il y a un compilateur Ada, et que Ada propose un modèle de programmation parallèle d'une puissance inégalée.
Ces concepts sont intégrés depuis toujours dans le langage, ils ne s'agit pas d'une bibliothèque externe ou d'un concept minimaliste ajouté avec difficultés dans un langage pas du tout pensé pour ça.
En Ada, les taches ou les objets protégés sont des citoyens de première classe. Ils peuvent être manipulés comme beaucoup d'autres types. On peut par exemple déclarer un tableau de tache.
Si vous souhaitez faire un logiciel de calcul, de jeux, ou de traitement d'image, intégrant un tasking performant, basé sur un standard ISO, portable entre compilateur, portable entre OS, alors pas la peine d'attendre, c'est déjà dans gcc.
J'espère que la banalisation des dual-core augmentera l'intéret des développeurs pour Ada, qui permet d'écrire un code unique pour Linux/Solaris/Windows/etc., exploitant les ressources disponibles sur la machine, quel que soit le nombre de processeurs.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 5.
Au niveau optimisation, le processeur fait tout son possible pour explorer en avance de phase plusieurs chemins d'exécution, le compilateur va faire de son mieux pour détecter dans le code source des choses vectorisables, etc. etc.
Mais le parallélisme de l'application, par exemple les politiques d'ordonnancement ou d'accès aux donées partagées, si ce n'est pas décrit dans le code source, le compilateur ne peut pas l'inventer.
[^] # Re: Ada answers
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 4.
Non, Ada n'a pas été conçu par l'armée américaine. L'armée américaine a juste fait le constat de ce qu'elle utilisait (au début des anées 70) 450 langages différents, et que c'était un gouffre financier. Certains corps d'armées c'atait fait vendre un langage temps réel propriétaire, avec un seul compilateur, tournant sur un hardware spécifique. Le rêve de tout fournisseur, un client vérouillé!
Le DOD américain a donc réunit un collège d'expert, ouvert sur le civil et l'étranger (une grande première alors), pour faire non pas un langage mais un cahier des charges d'un langage.
Le cahier des charges mettait l'accent sur quelques points, comme une certaine universalité et la prise en compte des problème de génie logiciel apparaissant alors sur l'écriture des premier gros logiciel.
Ensuite, 5 équipe ont présenté leur travail, et c'est l'équipe verte, dirigé par Jean Ichbiah qui a gagné.
Ada est né ainsi, de parents civils, en gagnant un concours militaire.
[^] # Re: Ada answers
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 3.
Pour les bindings, c'est vrai.
Pour atténuer celà, on peut rappeler que l'interfaçage en général et l'interfaçage avec C en particulier est facile.
J'avais un collègue qui n'a pas hésité à faire vite fait un binding à xerces, pour gagner 20 secondes au chargement d'un gros fichier xml par rapport à xmlada, sur un outils sans importance.
Pour les ressources web, il y a http://www.adapower.com/(...) et http://www.adaworld.com.(...)
Tu y trouves pas mal de chose comme des exemples de code, ou plusieurs livres sur Ada sous license libre.
(J'ai un bon souvenir de Ada Distilled)
Sur http://libre.act-europe.fr/,(...) en dehors des composants, il y a des cours très interessants en français.
Sinon, pour avoir de l'aide : http://www.ada-france.org/article13.html(...)
[^] # Re: Ada answers
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Oui, Ada n'a pas de définition formelle, mais c'est quand même un des rares langages dont la définition soit à la fois suffisement complète et non ambigu pour que l'on puisse en extraire des sous-ensemble prouvable formellement, sans dépendance au compilateur.
Pour les autres langage de ce type, les outils doivent compenser les trous de sémantiques de la définition du langage par la connaissance du comportement constaté du compilateur. C'est vrai par exemple, même pour un sous-ensemble de C comme MISRA-C, pourtant spécifiquement dédié à ces applications critiques.
Si celà t'intéresse, actuellement un produit original nomé SPARK fait une percée remarquée dans le monde de la preuve formelle Ada : http://www.praxis-his.com/sparkada/intro.asp(...)
Quoi qu'il en soit, le marché des applis embarqués critiques est justement LE marché dominé par Ada.
[^] # Re: Ada answers
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Tout à fait d'accord, c'est le point le plus inhabituel du langage.
Mais d'un autre coté, il offre tellement de caractéristiques uniques.
Au hasard, quel plaisir d'avoir un tasking complètement intégré dans le langage : pouvoir définir des types taches pas plus dificilement qu'une classe, déclarer un tableaux de 500 taches, etc.
Tout ça de façon portable, sans faire appel à la moindre API externe.
[^] # Re: Dommage ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Tout à fait, mais justement le bench montre que ce coût peut-être faible.
Par ailleurs, dans le cas de Ada, de nombreux checks sont fait à la compilation, car le source est sémantiquement riche. Ceci est sans conséquence au niveau du code généré.
Quand aux vérifications à l'exécution, tu as la possibilité de les enlever là ou tu le souhaite, soit par les options de compilation, soit directement par des pragmas dans le source. Ceci est utile par exemple lorsque qu'un outils externe te fournit une preuve formelle de ce que ces vérifiations sont inutiles.
Mais en fait, c'est rarement utile, car le compilateur fait un très bon boulôt d'optimisation.
Tu as donc le beurre et l'argent du beurre :
- vérif en abondance à la compil,
- vérif à l'execution pour le reste,
- performance quand il le faut.
Pour finir, il y a un compilateur Ada qui fait très fort car il ajoute de nombreux warnings et optimisations par dessus ce qui est imposé par le langage (et même des suggestions de corrections pour les erreurs bateau et les typos).
Et pour la chance du monde du libre, il se trouve que c'est justement GNAT, le compilo Ada de gcc.
[^] # Re: Et vb.net ?
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 1.
Regarde http://shootout.alioth.debian.org/faq.php?sort=fullcpu#acceptable(...)
Tu vas comprendre pourquoi :-)
[^] # Re: bidon
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 0.
Alors je serai surpris que ca ne fasse pas une belle différence, même si ce ne sont pas encore les conditions idéales.
[^] # Re: Dommage ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 3.
Mais concernant le développement, il ne s'agit de rien d'autre que de ton temps : tu le gaspilles ou tu l'utilises.
Débuggez ou développez, that is the question.
La plupart des dev Ada utilisent leur debugger tous les trois mois. Ca parait incroyable, mais c'est la stricte vérité.
Et pour ta dernière phrase, je me félicite que les dev de LL ne fassent pas le même choix que les entreprises, car curieusement les entreprises ne sont que rarement rationnelles, et elles vivent dans la psychose de prendre du retard et ne pas être dans le "mainstream".
[^] # Re: Dommage ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 5.
Tu as raison, j'en ai trop fait sur le bench, et les précautions pour éviter les trolls sont parfaitement inutiles sur ce genre de sujets. J'ai en fait commencé une réponse dans la discussion Java et OOo, mais ca m'embettait de participer à ce troll.
Alors, j'ai fais un article.
Toutefois, ce que tu dis est exactement la première moitié de la news. Ta conclusion sur la l'inutilité de C dans la plupart des développement moderne est exactement l'essence de l'article.
L'autre message que je voulais faire passer, c'est que les solutions "mainstream" ne sont pas forcément les meilleures, mais, bon, c'est si rassurant d'être dans la masse. Utiliser une solution originale demande d'être cultivé déjà rien que pour en avoir eu connaissance, encore plus pour bâtir un argumentaire comparatif (alors que si tu fais du C personne ne te demande rien).
Faut être un peu couillus ou associable, je trouve :-).
Tiens, sans le faire exprès je t'ai donné une réponse à ta question sur pourquoi C domine toujours outrageusement :-)
[^] # Re: bidon
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Ceci répond également partiellement a l'objection faite plus haut sur le désavantage des interpréteurs par rapport au test compilés : le désavantage est réel, mais pas si important que celà.
[^] # Re: Un petit test custom
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 7.
Attention à ne pas en faire une généralité : il n'y a aucune corrélation entre longueur et facilité de compréhension.
Fait lire un test même OCaml par un non informaticien, et le même test Ada dont le source est peut-être quatre fois plus long, vois ce qu'il comprend et tu en aura la preuve.
Personellement, je trouve ce critère tellement non significatif que je me demande ce qu'il fait sur ce comparatif.
[^] # Re: Dommage ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 7.
C'est une caractéristique essentiel d'Ada : tout est possible, y compris un buffer overflow.
Mais pour faire une goretterie pareille il faut faire un effort une fois. (Je me demande bien pourquoi, au passage).
Dans d'autre langage c'est pour éviter le buffer overflow qu'il faut faire des efforts... tout le temps.
L'esprit n'est pas le même, et ca fait une grosse différence.
[^] # Re: Sysv-rc ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal Bootsplash et alternative /bin/sh dans Debian. Évalué à 1.
Merci pour ton mail, ca m'a donné à réfléchir : c'est probablement du a ce que j'ai restauré la base de mon système avec une Knoppix.
Il y a quelques paquetages qui gardent l'empreinte Knoppix, entre autre sysvinit : je force la mise à jour vers une version Debian et je vais bien voir le résultat.
Si je ne poste plus rien dans les jours à venir, c'est que c'était une mauvaise idée :-)
[^] # Re: SWAT exempté?
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche 985 bugs dans le noyau Linux. Évalué à 0.
En général oui, mais pas toujours : pour une commande de vol électrique d'avion de ligne, il faut prouver que le logiciel est complètement correct.
Mais bon, comme passer d'un bon auxiliaire dans la chasse au bug à la preuve formelle du programme implique des changements considérables dans le processus et les outils de développement, ce n'est franchement pas applicable sur le kernel (et au logiciel libre en général, d'ailleurs).
[^] # Re: je comprend pas trop...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche 985 bugs dans le noyau Linux. Évalué à 3.
Si tu veux un panel complet en quelques pages des techniques de vérification, tu peux lire le chapitre "Verification Techniques" du Guide d'utilisation d'Ada dans les systèmes de haute intégrité http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c029575_I(...)).zip
Le compilateur ne peut pas faire de miracle : en amont, il y a la définition du langage utilisé. Si la définiton est imprécise, et la sémantique de bas niveau, la tâche devient virtuellement impossible pour les outils d'analyse statique.
Alors à fortiori pour le compilateur dont ce n'est pas la vocation.