Il n'y a pas vraiment de raison, j'ai juste repris les exemples de ce tuto
Après je pense que c'est plus clair pour comprendre ces histoires de sources et de cibles d'avoir les cibles de façon explicite dans la ligne de commande.
Mais on est bien d'accord que ça ne change rien pour smk, puisque l'outils regarde les fichiers réellement accédés, pas la ligne de commande ni le smkfile.
Hello, pas sur de comprendre ta question le calcul de dépendance, tu parles bien du cas ou l'output d'une commande invalide l'input d'une autre?
Dans ce cas, oui, c'est fait.
L'implémentation est naïve aujourd'hui, car je n'ai pas implémenté de graphe de dépendance.
C'est fait ainsi : je parcours la liste des commandes, si l'une d'entre elle est exécutée, alors je re-parcours toute la liste. Quand plus aucune commande n'est exécutée, je sors.
Pour éviter des cas pathologiques de dépendances récursives, le nombre de boucles est limité au nombre de commande, qui est le max du worst-case.
Pas forcément optimal en terme de perf, mais tellement plus simple à coder dans un premier temps.
Sur le second point, justement l'overhead, pas encore de mesure à ce point. Mais vu que vous êtes plusieurs à poser la question, je ferai un "time" comparatif d'un Makefile et d'un smkfile équivalent
(j'ai créé une issue sur GitHub).
Du coup en te basant sur les appels systèmes pour déterminer les dépendances (et sans faire d'optimisations propre au langage pour rester agnostique) j'aurai tendance à croire à un gros overhead (aussi bien en temps qu'en taille de logs dans tes fichiers .smk.*).
Tu as des chiffres là dessus ?
Non, et je n'ai pas envie de me lancer dans ces mesures tant que je n'aurai pas les idées claires sur l'intérêt de l'outil, et sur son domaine d'emploi.
Dans mon intention, l'idée principale est de gagner du temps lors de l'écriture / l'automatisation du process.
A première vue, l'exécution est rapide.
Mais peut-être que sur mes cas de tests simple, l'overhead est supérieur au temps d'exécution d'une commande gcc que l'on cherche à éviter, c'est tout à fait possible!!
(en taille de fichier, ça reste négligeable, mais je n'ai pas encore mis dans ma suite de test un gros build avec plein de fichier lu et écrits, type prod de site web).
J'imagine que tu n'as pas pu résister à l'envie de compiler smk avec smk ;-)
Bien sûr :-)
Mais mon Makefile est déjà trop complexe. Par exemple, je pipe des commandes les unes dans les autres sur certaines lignes. Et smk ne sait pas lancer de shell, juste des commandes.
Et bien sûr j'utilise des variables, pas encore supportées non plus.
Mais je garde en tête cet objectif, qui est de faire la même chose que mon Makefile, et de voir si j'y arrive vraiment de façon plus simple.
Merci pour le journal et le projet, ça fait très plaisir de voir une approche audacieuse à un problème ancien ;-)
Merci!
Dans mes souvenir un pauvre hello world en C++ se retrouve tout de suite avec des tonnes d'includes en cascade, dont beaucoup ne sont des bibliothèques standards fournies par le compilo (donc ne devant jamais changer en théorie…).
Oui, c'est amusant dans mon exemple de voir que pour gcc -o hello.o -c hello.c, il y a 55 fichiers accédés en read, alors qu'un seul nous intéresse, hello.c!
D’ou mon choix d'ignorer par défaut les fichiers systèmes dans les affichages, sinon c'était illisible.
(pour voir les fichiers systèmes, il y a une option --shows-all-files)
Par contre, tous les fichiers sont bien pris en compte: si /usr/include/stdio.h est mis à jour, la recompilation sera bien faite.
oui, on m'a déjà fait des retours de ce type (je crois même que c'est l'issue #1 sur GitHub!).
Je ferai une section "hints", donnant quelques commandes habituelles pour générer les dépendances, c'est toujours intéressant, mais ce sera pour mieux préciser que ce n'est pas la cible de smk.
Je ne prétends pas faire mieux qu'un outil dédié qui recompile ce qui doit l'être (comme gprbuild que j'utilise pour le code de smk), et qui peut même faire une analyse sémantique des sources et ne pas recompiler si par exemple seul les commentaires ont étés modifiés.
L'idée est plutôt d'optimiser des enchaînements de commandes plus simple (le make complexe de compilation pouvant d'ailleurs être une de ces commandes), avec un outil universel (non dépendant de la sémantique de ce qui est construit).
Cela montre l'urgence d'avoir dans ma doc d'autres exemples que du build gcc!
Est-ce que tu vois un intérêt à l'outil pour des choses autres, que tu traiterais par exemple par shell script?
(et merci en tout cas pour le retour)
Merci Adrien pour ta super appréciation sur l'idée!
Mon intention est de limiter au maximum le travail fait pour être compatible avec un shell file ou un Makefile.
Mais j'ai posté ce journal exactement pour avoir ce genre de retour.
Je suppose que tu fait allusion aux lignes du genre:
CFLAGS=-W -Wall -ansi -pedantic
Oui, je ne suis pas sûr de pouvoir passer au travers.
J'y ai réfléchi, et la partie substitution de variable n'est pas si compliquée, je créé une entrée dans github pour m'y atteler pendant les vacances de Noël!
la force de l'outils, c'est qu'il est complètement indépendant des commandes exécutées.
Il n'a pas la moindre idée de ce qui est compilé, il ne sait même pas si c'est de la compilation, et c'est tout à fait ce que je veux.
Il fonctionne donc aussi bien avec Fortran qu'avec n'importe quel langage y compris pas encore inventé (sauf à ce que les sources ne soient pas dans des fichiers).
J'ai utilisé un build typique C, mais c'est par facilité parce que c'est ce que l'on trouve dans tout les tutos de make.
En fait, je suis aussi preneur d'autres scripts que vous auriez, pour varier mes exemples et mes tests, comme par exemple la production de sites web, ou de documents, type:
latex <file>.tex
dvips <file>.dvi
ps2pdf <file>.ps
pdf2eps <pagenumber> <file>
En fait, ce n'est pas dans le cas du SSD une optimisation de performance, mais une optimisation de durée de vie.
Ma compréhension est qu'avec l'algo deadline, il y a moins de chance de se trouver dans la situation d'une écriture de bloc, suivie dans la milliseconde de la réécriture du même bloc parce que un second write a été fait sur d'autres octets dans la même zone.
Pour les DD on voulait optimiser le point faible : la mécanique. Pour les SSD on veut réduire les write, mais le principe reste le même, regrouper les écritures par bloc.
Bien sûr, je n'ai aucun moyen de vérifier si cela a un impact réel sur la durée de vie, c'est pourquoi je disais faire confiance (même si ce cas pathologique de réécriture me semble un peu théorique).
Pour ma référence à l'expérimentation à la fin de ce même paragraphe, je pensais à l'algo noop : les premiers tests, qu'il faut prendre avec des pincettes, semble en effet confirmer que cet algo plus simple donne les mêmes performances que les deux autres sur un SSD.
Mais d'un autre côté, sa simplicité n'occasionne pas des gains de CPU substantiels qui à leur tour amélioreraient les performances (ce qui est normal, puisque sur nos PC de bureau, SSD ou pas SSD la CPU n'est toujours pas le maillon faible, l'optimiser dans les coins ne sert donc pas à grand chose).
Après, si quelqu'un veut dérouler le script donné plus haut sur un DD pour voir si ce paramètre change les choses, ce pourrait être intéressant dans les situation mixte DD/SSD car on peut faire un choix d'algo différent par device.
Merci pour le truc,je vais essayer.
Pour éviter aux lecteurs de chercher comme je viens de le faire, echo 3 dans ce paramètre free pagecache, dentries and inodes.
Maintenant, le but étant d'évaluer l'impact de certain réglages relatifs au SSD sur les performances dans des conditions réelles, là on s'en éloigne un peu.
Au pire la première compilation sera plus lente que les suivantes, mais quant on code, on en fait en général quelques une à la suite, donc au total l'impact ne devrait pas être marquant.
Le j c'est par réflexe, je ne voulais pas m'en servir dans la boucle.
Mais ton idée d'un -j64 est excellente (quoi que je doute que gcc arrive à en faire autant en // sur ce code pas si gros que ça).
J'ai un rdiff-backup qui tourne tous les soirs sur un DD dédié au backup, donc une panne totale n'aurait pas d'effet catastrophique.
Mais surtout, cela rejoint les considération générales sur la fiabilité des SSD : je pense qu'on a maintenant un recul suffisant (mais je me fait peut-être des idées…) pour supposer que leur fiabilité est supérieure à celle des DD classique, et ce sur une durée raisonnablement longue.
Par ailleurs, j'ai bien regardé les retour d'expérience sur les SSD, et j'ai choisi un beau modèle (pas à un prix plancher), sans problème connu de fiabilité.
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.
[^] # Re: pourquoi -o machin.o
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 1.
Il n'y a pas vraiment de raison, j'ai juste repris les exemples de ce tuto
Après je pense que c'est plus clair pour comprendre ces histoires de sources et de cibles d'avoir les cibles de façon explicite dans la ligne de commande.
Mais on est bien d'accord que ça ne change rien pour smk, puisque l'outils regarde les fichiers réellement accédés, pas la ligne de commande ni le smkfile.
[^] # Re: Yet another build system
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3.
Hello, pas sur de comprendre ta question le calcul de dépendance, tu parles bien du cas ou l'output d'une commande invalide l'input d'une autre?
Dans ce cas, oui, c'est fait.
L'implémentation est naïve aujourd'hui, car je n'ai pas implémenté de graphe de dépendance.
C'est fait ainsi : je parcours la liste des commandes, si l'une d'entre elle est exécutée, alors je re-parcours toute la liste. Quand plus aucune commande n'est exécutée, je sors.
Pour éviter des cas pathologiques de dépendances récursives, le nombre de boucles est limité au nombre de commande, qui est le max du worst-case.
Pas forcément optimal en terme de perf, mais tellement plus simple à coder dans un premier temps.
Sur le second point, justement l'overhead, pas encore de mesure à ce point. Mais vu que vous êtes plusieurs à poser la question, je ferai un "time" comparatif d'un Makefile et d'un smkfile équivalent
(j'ai créé une issue sur GitHub).
[^] # Re: Quid des perfs ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 5.
Non, et je n'ai pas envie de me lancer dans ces mesures tant que je n'aurai pas les idées claires sur l'intérêt de l'outil, et sur son domaine d'emploi.
Dans mon intention, l'idée principale est de gagner du temps lors de l'écriture / l'automatisation du process.
A première vue, l'exécution est rapide.
Mais peut-être que sur mes cas de tests simple, l'overhead est supérieur au temps d'exécution d'une commande gcc que l'on cherche à éviter, c'est tout à fait possible!!
(en taille de fichier, ça reste négligeable, mais je n'ai pas encore mis dans ma suite de test un gros build avec plein de fichier lu et écrits, type prod de site web).
Bien sûr :-)
Mais mon Makefile est déjà trop complexe. Par exemple, je pipe des commandes les unes dans les autres sur certaines lignes. Et smk ne sait pas lancer de shell, juste des commandes.
Et bien sûr j'utilise des variables, pas encore supportées non plus.
Mais je garde en tête cet objectif, qui est de faire la même chose que mon Makefile, et de voir si j'y arrive vraiment de façon plus simple.
[^] # Re: Quid des perfs ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 6.
Merci!
Oui, c'est amusant dans mon exemple de voir que pour
gcc -o hello.o -c hello.c, il y a 55 fichiers accédés en read, alors qu'un seul nous intéresse, hello.c!D’ou mon choix d'ignorer par défaut les fichiers systèmes dans les affichages, sinon c'était illisible.
(pour voir les fichiers systèmes, il y a une option --shows-all-files)
Par contre, tous les fichiers sont bien pris en compte: si /usr/include/stdio.h est mis à jour, la recompilation sera bien faite.
[^] # Re: Yet another build system
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3.
oui, on m'a déjà fait des retours de ce type (je crois même que c'est l'issue #1 sur GitHub!).
Je ferai une section "hints", donnant quelques commandes habituelles pour générer les dépendances, c'est toujours intéressant, mais ce sera pour mieux préciser que ce n'est pas la cible de smk.
Je ne prétends pas faire mieux qu'un outil dédié qui recompile ce qui doit l'être (comme gprbuild que j'utilise pour le code de smk), et qui peut même faire une analyse sémantique des sources et ne pas recompiler si par exemple seul les commentaires ont étés modifiés.
L'idée est plutôt d'optimiser des enchaînements de commandes plus simple (le make complexe de compilation pouvant d'ailleurs être une de ces commandes), avec un outil universel (non dépendant de la sémantique de ce qui est construit).
Cela montre l'urgence d'avoir dans ma doc d'autres exemples que du build gcc!
Est-ce que tu vois un intérêt à l'outil pour des choses autres, que tu traiterais par exemple par shell script?
(et merci en tout cas pour le retour)
[^] # Re: Bravo pour le concept et le "hack" de strace !
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 5.
https://github.com/LionelDraghi/smk/issues/14
[^] # Re: Bravo pour le concept et le "hack" de strace !
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 5. Dernière modification le 11 décembre 2018 à 10:19.
Merci Adrien pour ta super appréciation sur l'idée!
Mon intention est de limiter au maximum le travail fait pour être compatible avec un shell file ou un Makefile.
Mais j'ai posté ce journal exactement pour avoir ce genre de retour.
Je suppose que tu fait allusion aux lignes du genre:
Oui, je ne suis pas sûr de pouvoir passer au travers.
J'y ai réfléchi, et la partie substitution de variable n'est pas si compliquée, je créé une entrée dans github pour m'y atteler pendant les vacances de Noël!
[^] # Re: seulement pour du C ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 8.
Hello Jean-Baptiste,
la force de l'outils, c'est qu'il est complètement indépendant des commandes exécutées.
Il n'a pas la moindre idée de ce qui est compilé, il ne sait même pas si c'est de la compilation, et c'est tout à fait ce que je veux.
Il fonctionne donc aussi bien avec Fortran qu'avec n'importe quel langage y compris pas encore inventé (sauf à ce que les sources ne soient pas dans des fichiers).
J'ai utilisé un build typique C, mais c'est par facilité parce que c'est ce que l'on trouve dans tout les tutos de make.
En fait, je suis aussi preneur d'autres scripts que vous auriez, pour varier mes exemples et mes tests, comme par exemple la production de sites web, ou de documents, type:
latex <file>.tex
dvips <file>.dvi
ps2pdf <file>.ps
pdf2eps <pagenumber> <file>
[^] # Re: En passant par le chemin de mon SSD
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 2.
En fait, ce n'est pas dans le cas du SSD une optimisation de performance, mais une optimisation de durée de vie.
Ma compréhension est qu'avec l'algo deadline, il y a moins de chance de se trouver dans la situation d'une écriture de bloc, suivie dans la milliseconde de la réécriture du même bloc parce que un second write a été fait sur d'autres octets dans la même zone.
Pour les DD on voulait optimiser le point faible : la mécanique. Pour les SSD on veut réduire les write, mais le principe reste le même, regrouper les écritures par bloc.
Bien sûr, je n'ai aucun moyen de vérifier si cela a un impact réel sur la durée de vie, c'est pourquoi je disais faire confiance (même si ce cas pathologique de réécriture me semble un peu théorique).
Pour ma référence à l'expérimentation à la fin de ce même paragraphe, je pensais à l'algo noop : les premiers tests, qu'il faut prendre avec des pincettes, semble en effet confirmer que cet algo plus simple donne les mêmes performances que les deux autres sur un SSD.
Mais d'un autre côté, sa simplicité n'occasionne pas des gains de CPU substantiels qui à leur tour amélioreraient les performances (ce qui est normal, puisque sur nos PC de bureau, SSD ou pas SSD la CPU n'est toujours pas le maillon faible, l'optimiser dans les coins ne sert donc pas à grand chose).
Après, si quelqu'un veut dérouler le script donné plus haut sur un DD pour voir si ce paramètre change les choses, ce pourrait être intéressant dans les situation mixte DD/SSD car on peut faire un choix d'algo différent par device.
[^] # Re: noatime et deadline
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 1.
Merci pour le truc,je vais essayer.
Pour éviter aux lecteurs de chercher comme je viens de le faire, echo 3 dans ce paramètre free pagecache, dentries and inodes.
Maintenant, le but étant d'évaluer l'impact de certain réglages relatifs au SSD sur les performances dans des conditions réelles, là on s'en éloigne un peu.
Au pire la première compilation sera plus lente que les suivantes, mais quant on code, on en fait en général quelques une à la suite, donc au total l'impact ne devrait pas être marquant.
Le j c'est par réflexe, je ne voulais pas m'en servir dans la boucle.
Mais ton idée d'un -j64 est excellente (quoi que je doute que gcc arrive à en faire autant en // sur ce code pas si gros que ça).
J'essaierai avec ces deux modifs.
[^] # Re: Sauf que...
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 2.
Alors là, tous les deux vous m'avez satellisé!
[^] # Re: plus de RAID ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 4.
J'ai un rdiff-backup qui tourne tous les soirs sur un DD dédié au backup, donc une panne totale n'aurait pas d'effet catastrophique.
Mais surtout, cela rejoint les considération générales sur la fiabilité des SSD : je pense qu'on a maintenant un recul suffisant (mais je me fait peut-être des idées…) pour supposer que leur fiabilité est supérieure à celle des DD classique, et ce sur une durée raisonnablement longue.
Par ailleurs, j'ai bien regardé les retour d'expérience sur les SSD, et j'ai choisi un beau modèle (pas à un prix plancher), sans problème connu de fiabilité.
Je ne suis donc pas plus inquiet que ça!
[^] # 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.