# [OPTIMISATION] A la recherche d'âmes charitables

## X-Ryl669

Bonjour, 

   Je suis actuellement à la recherche de personnes qui voudraient bien tester un concept nouveau de site web destiné à l'optimisation pure et dure, benchmark à l'appui.

Le site est en phase beta (voire pre release, car déjà fonctionnel)

Le but du site est le suivant :

   - associer à chaque package de portage un script qui, soit interroge la base de donnée (voir ci dessous) pour selectionner les meilleurs CFLAG pour ce package, en fonction de la config materielle, soit, s'il n'y a pas encore de données pour ce package, effectue une serie de test (en utilisant acovea) pour sélectionner les meilleurs CFLAG, il les envoie ensuite pour insertion dans la base de données.

Actuellement, le site est presque terminé. Il manque bien sûr les scripts de bench, qu'il reste à faire (desfois, un simple time + logiciel + gros_fichier suffit). 

Aussi, je cherche des gens qui aurait un peu de temps CPU à perdre pour m'aider à créer quelques scripts, et commencer à remplir la base de donnée.

Je cherche également des gens qui me donnerait leurs impressions (béta testeurs en l'occurence) sur l'interface du site, ce qu'il manque.

Je ne vous cache pas que ce site est principalement un site de benchmark, et que les CFLAG ne sont pas les seuls à être testés (nous prévoyons des tests de Kernel bientôt, ainsi que le NTPL / LinuxThread, etc, puisque l'architecture du site nous le permet). 

Le but extreme de ce site est bien sûr l'optimisation maximale du système, où le moindre pouième (piece of second?) compte, ce qui est, je crois le coeur même de l'esprit gentoo.

Voila, donc pour ceux qui seraient intéressés, soit vous répondez à ce sujet, soit vous déposez un message privé.  

Merci d'avance  :Wink: 

----------

## sebweb

Avec l'URL du site ca serait mieu non ?   :Laughing: 

----------

## X-Ryl669

Le site est actuellement en beta test. Je ne sais pas encore s'il sera capable de supporter la charge des visites d'un forums.gentoo.org entier (même la partie french uniquement)

Désolé pour cela, mais je vous envoie cette addresse dès que vous répondez à ce sujet, ou m'envoyez un mp. 

Dans quelques jours, si tout ce passe bien, je mettrais l'addresse ici. C'est le principe d'un béta test.

Merci pour votre intéret.

----------

## Neo_13

Eventuellement, ça peut m'interesser... d'autant que j'ai aussi un alpha sous la main... Mon seul prob, c'est que gentoo ne passe pas sur MON alpha

Mais sinon, sur le principe, ça m'intéresse

----------

## X-Ryl669

Visiblement, beaucoup de personnes me demandent comment ça marche, ou comment cela fonctionne, voire quels sont le genre de tests que l'on voudrait vous faire faire.

Le genre de test, c'est de compiler un logiciel (par exemple LAME pour ne pas le citer) avec different flags (par ex -O2, puis -O3, etc...) ou différent compileur. Ensuite, on execute avec chaque logiciel un benchmark (pour LAME, ce sera de compresser le même fichier, en mesurant le temps mis pour cela).

On recupère les résultats et on les rentre dans notre base de données, et ce, en fonction des configs des utilisateurs. C'est la phase d'apprentissage.

Ensuite, (c'est à dire dès que ces données sont entrées), n'importe quel utilisateur qui aurait la même config (ou une config similaire) pourrait voir quels sont les meilleurs flags pour ce logiciel, sans avoir à tous les essayer. 

Ainsi, quand une débian (compilée en -O2) dépasse en performance une gentoo, sur tel ou tel logiciel, c'est qu'il faut changer les flags (desfois -O3 donne des résultats pire que -O2) 

Notre système permet cependant de savoir, immédiatemment, quels sont les meilleurs flags à utiliser, et donc d'éviter les messages du type "Débian c'est mieux que Gentoo". 

Coté développeur, c'est un moyen d'avoir un banc de test pour un logiciel qui est en cours de développement.

Merci pour vos contributions. N'oubliez pas soit de m'envoyer un mp soit de répondre ici directement

----------

## Marsoinator

c'est une bonne idée mais je ne compile pas encore avec des flags bien spécifiques

----------

## Arcord

Cette idée est très intéressante.

J'ai un PC qui serait très tenté de participer.

Par contre, j'ai un doute là: on va peaufiner nos CFLAGS pour chaque logiciel. Mais les CFLAGS ne sont définis que dans /etc/make.conf, il n'y a pas moyen de spécifier de CFLAGS précis pour chaque soft; si bien qu'un simple 'emerge -u world' réduirait tout à néant.

On perdrait donc une fonction importante d'emerge.  :Shocked: 

----------

## sebweb

Il me semble que la configuration des CFLAG par package devrait arriver avec la prochaine évolution majeur de portage. Ca semble marcher comme le package.keywords actuel.

----------

## Arcord

Alors ça se serait une excellente nouvelle.  :Very Happy: 

----------

## X-Ryl669

Pour une compilation avec les meilleurs CFLAGS, il faudrait créer, comme avec le keywords de package un CFLAGS de package, et ce pour pouvoir utiliser emerge.

Cependant, lorsque l'on a choisi la solution proposée ici, les packages les plus utilisés (compilés avec un CFLAGS="quelquechose" emerge quelquechose) ne sont pas forcément mis à jour à chaque emerge -u world.

C'est clair qu'il va falloir modifier, soit la manière dont emerge selectionne ces cflags (donc solution à la package.keywords du style package.cflags), soit le nombre de package (sorte de ebuild perso lorsque vous avez trouvé de meilleurs flags). La première solution est plus propre (et peut être automatisée), alors que la deuxième solution fonctionnerait dès aujourd'hui.

C'est toujours expérimental, je vous l'accorde.

----------

## Duncan117

Euh je crois qu'il faut aussi prendre en compte les USE flags de chaque paquet car il se peut que ça modifie la vitesse d'un paquet.

Tu peux faire ça de manière automatisée avec le fichier /etc/portage/package.use et ce sera pris en compte même lors d'un emerge world.

Par contre comment tester un soft basé sur une ou plusieurs librairies. Est-ce que ton idée comprend l'optimisation du soft couplée à celles de ses librairies dépendantes ?

Un soft supra optimisé sur des librairies qui ne le sont pas, ça risque d'être moyen le gain de perf, nan ?

My 2 Cents

----------

## X-Ryl669

Voila, tu as raison pour les use flags sur le temps de compilation, pas sur le temps d'exécution (les use flags disent qu'il y a telle ou telle librairie d'installée, voire permettent de compiler un software supplémentaire (genre interface graphique pour gnome ou gtk) mais ne modifient pas le prog principal, ou alors je me trompe)...

Pour les librairies, on ne peux tester que les logiciels qui les utilisent. Je m'explique :

Quand un fabriquant de librairie sort une version, il est fréquent qu'il sorte un soft simple de test, ne serait-ce que pour tester que toutes les fonctions de la lib marchent. C'est ce genre de logiciel qui faut tester (d'où l'importance des scripts de bench).

----------

## piecq

ok, moi noobs de base, je suis pret a vous donnez de la puissance de calculs si vous voulez!  :Smile:  faudras juste car noobs oblige que sa ne soit pas trop compliquer pour ma pauvre petite cervelle et que je n ai pas a modifier toutes les 5 min un fichier de conf!!!  :Smile: 

----------

## YuLin

J'ai vu le site, il est sympa au niveau design sauf peut-être les trucs écrits en gros, ça fait pas trop pro, quand même (je sais que ce n'est pas forcément l'objectif, mais bon, plus c'est précis et concis et plus on aime, pas besoin d'en faire une tonne pour faire passer un message). Par rapport au menu de gauche, je pense que le "thanks to" n'y a pas sa place, le but étant d'y introduire un sommaire, en quelque sorte, des composantes du site.

Je trouve l'idée fort intéressante mais il me semble que, comme cela a été dit précédemment, ça paraît désuet si l'on compile les applications et les librairies avec des CFLAGS différents. A moins de remettre à jour son système avec des CFLAGS bien précis  :Rolling Eyes: 

En ce qui concerne le site, je n'ai pas vu de partie française (y en a peut-être pas en fait). Pour ce qui est de la version anglaise, je trouve que c'est une bonne initiative, mais attention aux fautes d'anglais / de frappe et tout (oui, je suis rabat-joie mais bon, je suis étudiant en linguistique anglaise alors forcément, si je peux aider...).

Le projet semble vraiment intéressant, on attend de voir l'intérêt que ça va susciter chez les gentooistes  :Wink: 

----------

## dune2

Salut,

 c'est vraiment tres interressant, pour ma part, j'ai utilisé gacovea pour chercher le meilleur CFLAG que je pouvais mettre ... mais c'est vrai que ce n'est pas la solution ideale pour tout le monde de plus ça nécéssite une synthèse des FAQs trouvés traitant du sujet.

Et je suis sûr que mettre en place une base de CFLAGs à  dispo des utilisateurs de gentoo permettra de rassurer les utilisateurs dans leur choix d'optimisations.

----------

## X-Ryl669

C'est clair que si dans un but immédiat l'intérêt de ce site est de fournir une "vraie" base de données de résultats sur l'impact de chaque CFLAG avec résultat à l'appui, le système d'emerge actuel peut tout ruiner (avec un emerge -u world).

D'après toutes les réponses que nous avons eu, il en ressort que pas mal de monde est prêt à nous prêter du temps processeur pour les tests, A CONDITION que ces scripts de bench soient tout automatisés et simple à mettre en oeuvre.

Nous écrivons des scripts de bench actuellement, aussi dès que les premiers script génériques sont testés et validés, on commencera à réunir (et remplir) la base de données associée. L'avantage de ce système c'est qu'il peut être totalement automatisé.

Comme le dit YuLin, nous attendons également de voir l'intérêt que ce site va susciter chez les utilisateurs de Linux (pas de Gentoo seulement). Pour le moment, on a fait 3100 visites en 2 jours, ça commence bien.

----------

## dju`

idée fort intéressante, mais il faudra un maximum de testeurs avec un maximum de configurations matérielles pour la phase d'apprentissage, pour tester un maximum de combinaisons de cflags, ce qui risque de faire beaucoup d'informations...ah, l'adresse du site est déjà sur dlfp.

----------

## Duncan117

Lut X-Ryl669,

Effectivement ton site n'est pas mal du tout. Cependant, n'étant ni webmaster, ni linguiste en anglais, je ne pourrais pas critiquer quoi que ce soit à ce niveau.

Sinon, je rejoins une remarque précédente qu'une page française sur le sujet serait la bienvenue.   :Wink: 

Effectivement, le gros avantage par rapport à d'autres projets, c'est qu'il y a une véritable lacune dans le domaine et que tout reste à faire. Donc à priori, tu es libre de partir dans toutes les directions et de sortir des sentiers battus.   :Very Happy: 

L'idée de faire une base de donnée par machine est réellement la bienvenue et ce pour deux points :

1) Comme tu le dis, ça peut rassurer sur les optimisations que certains ont mis dans leur CFLAGS.

2) Il n'est pas exclu qu'à l'avenir portage sache prendre en compte l'utilisation de CFLAGS personnalisés pour chaque package à l'instar d'un /etc/portage/package.{use,keywords}. C'est-à-dire un /etc/portage/package.cflags   :Very Happy: 

Or il se peut que ton projet soit à la base de cette nouvelle fonctionnalitée dans portage.   :Wink:   En effet, l'utilisateur télécharge un fichier de CFLAGS directement de ta base de données. Enfin bref, il n'y a pas de problème mais que des solutions..

Bah en fait, pas tant que ça. Je vais me faire l'avocat du diable. Imaginons qu'un tel système existe. Je vois déjà arriver les messages sur le forum du genre. "Tel prog ne compile pas, est-ce du à un mauvais CFLAGS ?"   :Shocked:  Il va falloir avoir les reins solides pour pouvoir répondre à de tels messages. C'est pas tant que ces messages n'existent pas déjà mais ils ne sont pas majoritaires. Si manipuler qqes cflags, ca convient encore dirons-nous, maintenant s'il faut en manipuler plusieurs dizaines, outch, ca risque d'être bcp plus complexe.

Remarque en même temps, il se peut que ton projet solutionne ce genre de problème.

Courage

My 2 Cents

----------

## YuLin

 *Duncan117 wrote:*   

> Bah en fait, pas tant que ça. Je vais me faire l'avocat du diable. Imaginons qu'un tel système existe. Je vois déjà arriver les messages sur le forum du genre. "Tel prog ne compile pas, est-ce du à un mauvais CFLAGS ?"   Il va falloir avoir les reins solides pour pouvoir répondre à de tels messages. C'est pas tant que ces messages n'existent pas déjà mais ils ne sont pas majoritaires. Si manipuler qqes cflags, ca convient encore dirons-nous, maintenant s'il faut en manipuler plusieurs dizaines, outch, ca risque d'être bcp plus complexe.

 

Se faire l'avocat du diable est une très bonne chose à laquelle je témoigne ma sympathie  :Smile: 

Ce que tu dis, Duncan117, peut se révéler vrai dans un premier temps, mais si ce site et plus particulièrement cette base de donnée devient populaire (j'entends par là qu'elle devient la base de donnée majeure en le domaine), alors elle sera considérée comme une référence et, de fait, lorsque dans le forum on aura un post genre "mon programme ne veut pas se compiler, vilain méchant" on pourra se baser sur les recherches possibles depuis ladite base de données ou alors simplement donner le lien de référence aux personnes dans le besoin afin de prophétiser une solution à leur épineux problème. Du moins, c'est comme ça que je vois ce projet.  :Rolling Eyes: 

----------

## Synnalagma

Je trouve que le projet est une excellente idée.

Ce que je ne comprend pas c'est comment vous allez faire pour assemblé des résultats similaires.

Comment définir ce qui est similaire ? Quels critères utilisés ?

Peut-être que je me trompe, mais est-ce que les cflags pour un package ont une influence sur un seule package ?

Est-ce que le système ne forme pas pour certains packages un tout dans le genre si je compile QT avec -O2 alors les meilleurs flags pour KDE3.2 sont -03 mais si je compile QT avec -O3 alors le mieux pour KDE3.2 est -O1 et peut-être que l'optimum global se trouve avec -o1 pour QT et KDE alors que -o1 n'est pas un optimum pour QT.

Je dis ça parce que j'ai déjà fait plusieurs expérience en IA où l'optimisation individuelle ne permet que de trouver un optimum local mais en tout cas pas un optimum global.

Il s'agit surtout de questions et pas d'afirmation, je ne sais pas c'est tout

Continuez je trouve que c'est une bonne idée.

Et je participerais au tests.

----------

## letoff

 *Quote:*   

> Le but extreme de ce site est bien sûr l'optimisation maximale du système, où le moindre pouième (piece of second?) compte, ce qui est, je crois le coeur même de l'esprit gentoo

 

Et bien moi je vais me permettre de cracher un peu dans la soupe si celà ne vous gène pas. Si j'aime Gentoo c'est parce que LFS est trop difficile à maintenir, et gagner un pouième de seconde sur le lancement de Mozilla ne me met pas du tout en transe. D'autre part mon expérience me laisse penser que cette initiative est dores et déjà vouée à l'échec. En effet comment s'assurer de la validité et de la répétabilité des résultats sur des machines qui peuvent être si différentes? D'abord d'un point de vue matériel:

le comportement des cflags doit certainement changer en fonction du proc, de la mémoire, des bus, du paramétrage et de la version du Bios, etc... Voire même de l'environnement (T° excessive ou comportement en charge soutenue: j'ai rien à foutre de gagner une seconde au démarrage si c'est pour avoir un core-dump après 20 mn d'utilisation intensive.) Imaginez un peu le nombre de combinaisons possibles !

Ensuite d'un point de vue logiciel: l'impact des cflags n'est certainement pas le même avec un kernel 2.6 ou 2.4. L'exemple qui me parait significatif est celui d'apache. Primo ce qui compte le plus c'est la stabilité et la tenue en montée en charge, pas la milliseconde gagnée grace à un -O3 pour répondre à une requête HTTP. Ici le modèle MPM choisi est certainement bien plus important que les cflags. De même qu'un layout en phase avec le partitionnement... (this is not a troll despite what u could think)

Pour terminer avec ce long message, vous aurez compris que je suis plus interessé par les applis serveur (bind, postfix, apache, tomcat, postgresql) et que je vois mal l'impact des flags (et surtout la définition de rêgles génériques) sur de telles applis.

Mais que mon post ne vous décourage pas de continuer, c'est juste que je fais partie d'une autre branche des adorateurs de Gentoo.  :Wink: 

----------

## Angelion

Sinon pour ceux qui veulent tester des flags Debian il suffit de dl les sources Debian du paquet, dedans se trouve un fichier rules contenant entre autres les CFLAGS utilisés.

On y trouve meme des infos comme quoi certains CFLAGS font apparaitre des bugs non resolus sur certains softs.

Attention, si vous partez de Woody, gcc 2.95 est utilisé, pour Sarge c 3.2 ou 3.3 je ne sais plus.

Point amusant, presque tous les paquets sont compilés avec l'option -g , pour etre ensuite 'strippé' ...

----------

## X-Ryl669

Compiler avec l'option -g puis stripper permet d'avoir les positions des tables de symboles aux mêmes endroits. C'est à dire que, dans une première phase, on est en -g pur, on débug. Ca passe tous les vecteurs tests du package. On strippe, on beta release, et diffuse. Si il y a un problème, on peut retrouver la fonction incriminé via le symbole dans la version non strippée. Sans l'option -g, c'est quasi impossible (à part dans le cas des librairies). Ceci dit, c'est moins optimisé.

Mais c'est vrai que tous les packages débian ont été marqués par leurs CFLAGS (comme quoi, il est nécessaire de s'en occuper). Cependant, il n'y a aucun résultat des tests de ces CFLAGS dans le package (donc pas utilisable dans ce projet). 

Note pour les personnes qui m'ont contacté, le site est maintenant totalement automatisé. Les premiers bench scripts génériques sont presques finis, et la saisie des résultats (sera) incluse dans les benchs scripts. Corrections des bugs que vous avez trouvés, etc... Que du bonheur quoi...

Merci à tous.

----------

## Arcord

Tiens, je viens de remarquer un truc.

On a besoin d'acovea pour les tests, et il n'y a pas d'ebuild pour ce soft;

C'est un détail, mais je suis assez étonné.  :Wink: 

----------

## X-Ryl669

Mais si....  :Wink: 

https://forums.gentoo.org/viewtopic.php?t=157108

----------

## Arcord

Considérons que je n'ai rien dis.  :Laughing: 

----------

## Martin LORANG

Je veux bien aider, mais sur le site lorsque je tente de visualiser ou de charger testme 0.1 j'obtiens cela :

```
@charset "iso-8859-1";

/* Style for this site */

/* By X-Ryl669         */

body

{

   background-color : #BBAAFF;

   font-family : Tahoma, Verdana, Helvetica, Arial;

   font-size : 12px;

}

etc...
```

ça m'a pas l'air normal   :Very Happy: 

Avec alma 1.0 et huff 1.0 j'obtiens une page blanche...

Et c'est pareil avec konqueror et mozilla-firefox.

Martin

----------

## X-Ryl669

Oui, bien vu!  :Wink: 

 C'est vrai, et c'est comme je le disais en privé à ceux qui m'ont répondu.

Donc, pour être exact, concernant la présentation, la phase de béta test est quasiment terminée (site fonctionnel sur quasi tous les navigateurs qui gèrent le HTML 4). 

Concernant le contenu maintenant, nous avons passé des sondages pour savoir quels sont les logiciels que vous voudriez voir optimisés. Nous étudions les réponses. Ceci dit, pour chaque logiciel il va falloir écrire un script de benchmark (n'ayez pas peur, nous sommes en train d'en écrire un qui soit générique à tous les projets qui utilise la procédure configure && make && make install, soit la quasi totalité des projets). Le but est, comme l'on fait très justement remarqué certains de vos post, d'automatiser à fond le système. J'avais écrit des scripts en bash pour detecter le matériel, le compilateur, et l'application, modifier les CFLAGS, etc... mais finalement, nous avons pensé tout réecrire en python (comme portage). Ce, pour 2 raisons :

 :Arrow:  Une fois les résultats trouvés, il faut les transmettre, et piloter un telnet en bash (ou ne serait-ce qu'ouvrir une socket) est trop dépendant des logiciels du système, alors qu'avec Python, il y a déja les sockets en lib.

 :Arrow:  Le calcul des résultats est très long (avec le processeur utilisé à 100 %). L'arrêt du calcul entraîne la perte de tous les résultats calculés précédemment... Grr   :Evil or Very Mad:  . 

Pour éviter ce dernier problème, nous sommes en train de modifier l'architecture d'acovea, afin de pouvoir distribuer une phase de calcul (ou run) sur différentes machines et d'enregistrer les résultats. En gros, cela va permettre de faire un script en python qui serait lancé quand la machine est idle et qui fera :

0] Détection de la configuration matérielle (et enregistrement dans un fichier pour les lancements suivants)

1] Détection du compilateur, de la présence de distributed acovea

     Si DAcovea (distributed acovea) est absent, l'installer

2] Interrogation de la base de donnée pour connaitre les pools de CFLAGS à tester pour le tuple configuration + compiler + software

3] Téléchargement du fichier d'archive du logiciel benchmarké (pour pas interférer avec portage) et décompression

4] Modification des CFLAGS

5] Compilation du run (autant de compilations que de populations (typiquement 5) du projet) 

6] Lancement de dacovea avec les résultats (avec le calcul du nouveau pool à tester)

7] Transmission des résultats (et du nouveau pool) pour la tuple configuration + compiler + software

8] Retour à 4, et ce tant que le script n'est pas interrompu, ou que le test est fini

Le script est écrit jusqu'à l'étape 6, puisque nous n'avons pas encore fini de modifier acovea. Ceci dit, acovea est très bien écrit, et cela ne devrait pas prendre trop de temps. 

En effet, acovea a été écrit pour une compilation d'un fichier unique, en utilisant des librairies très bien faites. Nous sommes en train de modifier acovea pour qu'il puisse séparer les runs et les résultats, reprendre où il s'était arrêté et compiler tout un projet.

Bref, il faut nous laisser encore un peu de temps, nous sommes plus près de la pre release que de la béta maintenant. Patience...

----------

## Martin LORANG

Bon ben je patiente...

----------

## Pachacamac

Juste une idée comme çà, est-il prévu d'utiliser des pc connectés sur internet pour aider ceux qui compilent ?

Car ceux qui vont se taper tous les paquets avec leurs différentes possibilités n'auront meme pas fini avant la sortie d'une nouvelle version  :Wink: 

Ca serai bien de referencer (pour les inscrits par exemple) quelques volontaires qui donnerai de leur puissance CPU, non ?

----------

## Corto

Un petit up ? Ça en est où cette histoire ?

PS: selon l'idée de Pachacamac, faire des bin en distribué pour les petites config ça peut être pas mal non ?

----------

## X-Ryl669

Bon, 

  En fait, ça avance (plus doucement que ce que je croyais...). J'ai modifié acovea pour supporter la sérialisation (possibilités de sauvegarde à chaque génération) pour permettre la distribution des runs de tests (un utilisateur fait run par run, et ce jusqu'au run final, ou l'arret des tests). Ainsi pour des projets énormes tels que glibc, Xfree, etc... Il ne sera(it) pas nécessaire de faire mouliner le système pendant des semaines.

Ceci dit, dans le code originel d'acovea, il y avait des bugs (que je supprime peu à peu, en plus de ceux que j'ai introduits). Et donc, nous tenons à ce que le système soit totalement fonctionnel avant de le faire tester. Je cherche toujours un débugger correct sous linux (avec call stacks, RTTI, etc...), j'ai essayé DDD, mingwstudio, etc... mais comme ils s'appuient tous sur gdb, ça ne fonctionne pas terrible...

C'est plus long que ce que je pensais. Mais ça avance (possibilité de sauvegarder les runs fonctionnelle, chargement non fonctionnel pour l'instant... 

Les scripts invoquant Dacovea sont écrits, donc dès que le soft est prêt, je poste un nouveau message, et contacte tous ceux qui m'ont répondu.

Allez, A+

----------

## Martin LORANG

Un p'tit up pour savoir ce qui ce passe sur ce projet "à priori" intéressant ?

Est-ce que ça va fonctionner avec gcc-3.4 ? (amd64 oblige...)

A+

----------

## X-Ryl669

Bon alors, pour ceux qui s'impatientent, voila des news toutes fraîches du projet :

 - Dacovea est terminé, il est débuggé, il fonctionne et selectionne les meilleurs CFLAGS.

Je suis en train de tester l'architecture et les scripts que j'ai écrits. 

Nous allons donc très rapidement contacter les gens qui nous ont écrit pour leur soumettre une version de test, et voir comment le site (et le webmaster) supporte la charge.

  - Voilà finalement comment cela va se passer :

 1]  Un utilisateur s'inscrit sur le site pour proposer du temps de calcul

2]  De là, il télécharge le script général (A) pour l'ensemble des tests

3]  Il sélectionne ensuite un logiciel dans la liste des logiciels proposés pour faire son optimisation, et télécharge le script adéquat (L)

4]  Il lance ensuite ce script (L) qui télécharge les sources du logiciel à tester, détecte la configuration matérielle, le compilateur actuel (gcc 3.4, 3.3 ou icc), détecte la présence de dacovea, et l'installe si nécessaire, et télécharge le script de benchmark du logiciel en question, et les fichiers (par exemple un script qui execute "time lame -f -V 4 monfichier.wav out.mp3") 

5]  Enfin, les tests à proprement parler sont exécutés avec un indicateur de progression (voir screenshot). Ces tests peuvent être interrompus et repris plus tard (grâce à l'ajout de la sérialization), le script détectant automatiquement le dernier run effectué.

6]  A la fin des tests, un fichier est écrit avec les meilleurs CFLAGS trouvés, deux dernières compilations sont faites pour mesurer les performances, comparée à un O3

7]  Finalement, les résultats sont codés et envoyés sur le site, d'où ils seront validés par le webmaster puis intégrés dans la base de données

Il me reste à modifier les scripts pour intégrer les numéro 6 et 7, et donc c'est pour bientôt.

Un petit aperçu de dacovea (version en test actuellement) :

 *Quote:*   

> 
> 
> dacovea -- a command-line driver program for the Distributed Acovea framework
> 
> ACOVEA - Analysis of Compiler Options Via Evolutionary Algorithm
> ...

 

----------

## fafounet

le cote je lance et j´ai rien a faire ma plait pas mal. Vivement que tout soit fini qu´on optimisationne

----------

## X-Ryl669

Bon, merci de votre attente.

Pour ceux qui connaissent déjà l'addresse du site, nous vous invitons à participer à notre béta-test.

Là, c'est encore chaud!!!

Pour les autres, soyez patients, après les bétas, les releases...

Bien sûr, nous attendons de vous que vous nous fassiez part de vos remarques, des bugs, et autres vermines virtuelles qui auraient échappé à notre vigilance via la nouvelle interface à la bugzilla. Ca va sentir le silicium fondu bientôt...

Merci encore de votre patience.

----------

## Pachacamac

Ah c'est génial ! 

Demain je regarde ça de plus près, la je suis épuisé, je vais faire dodo.

Merci pour ton taff, on va vraiment pouvoir optimiser a donf.

----------

## X-Ryl669

Alors ?

  Qu'en pensez vous ?

----------

## Pachacamac

Je n'ai pas retrouvé l'@ du site, tu peux me la renvoyer stp. Via un PM ou mail comme tu préfère.

Merci.

----------

## YuLin

Salut tout le monde  :Smile: 

Je me suis donc rendu sur le site web du projet et ai téléchargé le script magique qui est censé tout télécharger lui-même.

Seulement voilà, j'ai une erreur qui s'affiche et comme je n'y connais rien au python, je ne vais pas pouvoir régler le problème :

```
--11:27:57--  http://foo.bar.fr/SNIP/InOut.py

           => `InOut.py'

Resolving foo.bar.fr... 212.xx.xx.xxx

Connecting to foo.bar.fr[212.xx.xx.xxx]:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 32,151 [text/plain]

 

100%[====================================>] 32,151       110.30K/s

 

11:28:01 (110.29 KB/s) - `InOut.py' saved [32151/32151]

 

--11:28:01--  http://foo.bar.fr/SNIP/Modify

           => `Modify'

Resolving foo.bar.fr... 212.xx.xx.xxx

Connecting to foo.bar.fr[212.xx.xx.xxx]:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 403 [text/plain]

 

100%[====================================>] 403           --.--K/s

 

11:28:01 (3.84 MB/s) - `Modify' saved [403/403]

 

--11:28:01--  http://foo.bar.fr/SNIP/Mirrors.py

           => `Mirrors.py'

Resolving foo.bar.fr... 212.xx.xx.xxx

Connecting to foo.bar.fr[212.xx.xx.xxx]:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 279 [text/plain]

 

100%[====================================>] 279           --.--K/s

 

11:28:01 (2.66 MB/s) - `Mirrors.py' saved [279/279]

 

Traceback (most recent call last):

  File "./cflagselect.py", line 34, in ?

    import InOut

  File "/root/cflags/InOut.py", line 711

    projtext += EmbedValue(Boundary, "bestctime", str( int((float(proj[0]) * 100.0) / Max))

           ^

SyntaxError: invalid syntax
```

C'est quoi donc qui est cassé ?  :Sad: 

----------

## X-Ryl669

Je te remercie d'avoir supprimé l'URL du site dans ton post. 

Sinon, mea culpa, j'ai oublié de transmettre la derniere version de script sur le site. 

Efface tout, retélécharge ça devrait être réglé.

----------

## YuLin

OK, j'ai donc téléchargé la nouvelle version qui m'a donc permis d'aller plus loin, cependant, une autre erreur est survenue pendant le test de lame 3.96 :

```
[HCG] Archive found now and modified                                                                                                                [  OK  ]

[HCG] Dacovea command line below \/\/\/                                                                                                             [  OK  ]

dacovea -config gcc33_processor.dacovea -srcdir /tmp/ts/lame-3.96/ -bts /tmp/ts/testlame -run /tmp/ts/lame000.run -out /tmp/ts/lame.out -g 4 -n 5 -p 7 -sr 0.15 -ir 0.143

[HCG] Report this command line if any problem(no tests) occured                                                                                     [ WARN ]

[HCG] Starting the test...                                                                                                                          [  OK  ]

dacovea -- a command-line driver program for the Distributed Acovea framework

 

[HCG] Test finished transmitting the result...                                                                                                      [  OK  ]

[HCG] Testing result is enabled so test is running                                                                                                  [  OK  ]

[HCG] Testing with -O3 flag                                                                                                                         [  OK  ]

sh: line 1: /tmp/ts/gslame: Permission denied

[HCG] Compilation took 29s                                                                                                                          [  OK  ]

Traceback (most recent call last):

  File "/root/cflags/cflagselect.py", line 154, in ?

    InOut.TransmitResult(listname[softname], dr, result, Conf, teston != -1)

  File "/root/cflags/InOut.py", line 560, in TransmitResult

    OutStrWithOk("-O3 returned " + o3time[0] + " with binary size " + o3size[0] + " bytes")

IndexError: list index out of range
```

Désolé pour la typo, pas facile de copier ce genre de trucs...   :Rolling Eyes: 

P.S. : je précise que le script était lancé en root, je ne comprends donc pas  le sens du "Permission denied" oO

----------

## YuLin

D'accord, je viens de comprendre. le fichier /tmp/ts/gslame est un script bash, mais comme il n'était pas chmod en +x il ne pouvait pas s'exécuter.

C'est donc un bug à corriger  :Smile: 

Cependant, en chmodant ce script de façon à le rendre exécutable une nouvelle erreur se produit :

```
[HCG] Testing with -O3 flag                                                                                                                         

[HCG] Compilation took 30s                                                                                                                          

[HCG] -O3 returned 2.727 with binary size 318659 bytes                                                                                              

[HCG] Testing with fitted flags                                                                                                                     

Traceback (most recent call last):

  File "/root/cflags/cflagselect.py", line 154, in ?

    InOut.TransmitResult(listname[softname], dr, result, Conf, teston != -1)

  File "/root/cflags/InOut.py", line 565, in TransmitResult

    resultfile = open(result, "r")

IOError: [Errno 2] No such file or directory: '/tmp/ts/lame.out'
```

NOTE : j'ai enlevé tous les "[ OK ]" sinon c'est indigeste à lire sur le forum.

----------

## X-Ryl669

Okay, mea culpa, j'avais oublié un chmod +x dans les script... Bon, les nouveaux scripts sont sur le serveur...

Sinon, YuLin, en fait, le test par Dacovea n'a pas été fini (normalement c'est assez long, genre 2 ou 3 heures), c'est pour cette raison que la suite du script s'arrête. Cela est dû au manque du fichier gcc33_processor.dacovea qui contient le fichier de pool de CFLAGS à tester qu'il faut créer sur ton système. Pour cela, j'ai inclu mon fichier qui s'appelle gcc33_pentium4.dacovea et qui doit être dans le répertoire d'installation de dacovea-1.0. Renome le gcc33_processor.dacovea en modifiant, à l'intérieur, le flags -march=pentium4 par ton processeur. La marche à suivre est indiquée sur le site.

Je pense qu'il s'agit bel et bien d'un problème (BUG) qu'il va falloir que j'éclaircisse. Je vais probablement faire un script qui générera automatiquement ce fichier s'il n'existe pas. (Par contre, c'est le seul fichier où l'on peut mettre ses CFLAGS préférés pour voir l'impact).

Je modifie les scripts, et je reposte ici...

----------

## YuLin

OK, mille excuses ! En voulant voir ce que ça faisait tout de suite je me suis rendu droit dans le mur. Je n'avais pas édité le fichier dont tu parles pour gcc. Ca m'apprendra à ne pas lire correctement les instructions.

Désolé pour la perte de temps occasionnée.  :Rolling Eyes: 

----------

## GNUTortue

Je veux bien essayer de vous aider mais je n'y connait quasi rien ! Enfin j'ai au moins + ou - compris quel était le but de la chose

----------

## X-Ryl669

Voila, la modification est terminée, maintenant le fichier contenant le pool de CFLAGS est créé automatiquement... 

Pour ceux qui ont téléchargé le script, il va falloir tout effacer (dacovea y compris), et re-télécharger.

Pour les autres, ça devrait aller comme sur des roulettes...

----------

## YuLin

Ouais mais, si on a créé le fichier gcc33_processor.dacovea soi-même, pourquoi tout supprimer et tout retélécharger alors que finalement, la génération de ce fichier par script rend juste la procédure automatique mais ne change rien au résultat ?

Je suis presque à la fin des tests de lame, là, j'espère que mes résultats vont être pris en compte même si j'ai pas la toute dernière version des script...  :Rolling Eyes: 

----------

## X-Ryl669

YuLin, les nouveaux scripts sont compatibles avec les anciens (ils ont juste moins de bug  :Wink:  ). Donc, laisse finir la procédure, ça va marcher...

Je disais ça pour les MP que j'ai reçu... 

Désolé pour la confusion...

----------

## YuLin

Hop encore un post (on va croire que je suis en manque de communication) !

Après des heures de travail acharné de la part de ma machine j'arrive donc à la fin des tests de compilation de lame et voilà ce que j'ai :

```
[...]

run complete time: 2004 Jun 15 15:20:21

 

optimistic options:

                -fno-defer-pop (1.705)

       -fno-omit-frame-pointer (1.058)

          -fno-cprop-registers (1.705)

             -fno-crossjumping (1.058)

            -fcse-follow-jumps (1.22)

                   -fpeephole2 (1.058)

             -fstrict-aliasing (1.22)

           -freorder-functions (1.867)

                 -falign-loops (1.382)

                      -ftracer (1.22)

                     -mieee-fp (1.543)

                -mno-push-args (1.705)

               -fno-math-errno (1.058)

            -fno-trapping-math (1.058)

                -finline-limit (1.382)

 

pessimistic options:

                        -fgcse (-1.043)

             -fstrength-reduce (-1.043)

              -frerun-loop-opt (-1.204)

                   -fforce-mem (-1.204)

                     -fregmove (-1.043)

                 -ffloat-store (-1.366)

        -fprefetch-loop-arrays (-1.366)

                      -fnew-ra (-1.528)

        -minline-all-stringops (-1.366)

                  -mfpmath=387 (-1.851)

                  -mfpmath=sse (-1.204)

              -mfpmath=sse,387 (-1.851)

[HCG] Test finished transmitting the result...                                                                                                      

[HCG] Testing result is enabled so test is running                                                                                                  

[HCG] Testing with -O3 flag                                                                                                                         

[HCG] Compilation took 30s                                                                                                                          

[HCG] -O3 returned 2.721 with binary size 318659 bytes                                                                                              

[HCG] Testing with fitted flags                                                                                                                     

cc1: error: unrecognized option `-finline-limit'

make[2]: *** [common.lo] Error 1

make[1]: *** [all-recursive] Error 1

make: *** [all] Error 2

ls: lame-3.96/frontend/lame: No such file or directory

[HCG] Compilation took 0s                                                                                                                           

Traceback (most recent call last):

  File "/root/cflags/cflagselect.py", line 154, in ?

    InOut.TransmitResult(listname[softname], dr, result, Conf, teston != -1)

  File "/root/cflags/InOut.py", line 586, in TransmitResult

    OutStrWithOk("Dacovea flags returned " + dactime[0] + " with binary size " + dacsize[0] + " bytes")

IndexError: list index out of range
```

C'est grave docteur ?  :Wink: 

----------

## X-Ryl669

Alors là, c'est vraiment un gros bug... 

En fait l'option -finline-limit requière un argument (-finline-limit=600 par exemple). Dans Dacovea, par contre, la valeur de cette argument n'est, pour l'instant pas sauvegardée. Grosse erreur de ma part, car cette option n'a jamais été sélectionnée avant, et donc pas d'erreur lors de mes tests. 

Je vais devoir modifier dacovea, mais pour l'instant, tu peux éditer le fichier /tmp/ts/lame.out et remplace la ligne -finline-limit par -finline-limit=600 et relance le script...

Voila, tu es au bout de tes peines...

----------

## YuLin

OK. Je viens donc d'éditer /tmp/ts/lame.out. Alors du coup j'ai relancé le script et ça va plus loin  :Smile: 

Seul hic, j'ai une nouvelle erreur  :Rolling Eyes: 

Je vais finir par croire que je suis antipathique à tous ces beaux scripts python  :Sad: 

Voici donc l'erreur que je rencontre :

```
[HCG] Testing with -O3 flag                                                                                                                         

[HCG] Compilation took 32s                                                                                                                          

[HCG] -O3 returned 2.762 with binary size 318659 bytes                                                                                              

[HCG] Testing with fitted flags                                                                                                                     

[HCG] Compilation took 32s                                                                                                                          

[HCG] Dacovea flags returned 2.500 with binary size 334895 bytes                                                                                    

[HCG] Testing with original project flags                                                                                                           

takehiro.c:1202: warning: `all_scalefactors_not_negative' defined but not used

[HCG] Compilation took 37s                                                                                                                          

[HCG] Initial flags returned 2.739 with binary size 383910 bytes                                                                                    

Traceback (most recent call last):

  File "/root/cflags/cflagselect.py", line 154, in ?

    InOut.TransmitResult(listname[softname], dr, result, Conf, teston != -1)

  File "/root/cflags/InOut.py", line 640, in TransmitResult

    Text += EmbedValue(Boundary, "ProcType", ProcName[0])

IndexError: string index out of range
```

J'espère au moins que ça aide le développement du projet  :Smile: 

Allez, faut y croire, on est bientôt au bout  :Smile: 

----------

## X-Ryl669

Bon, cette fois ci, est-ce que tu peux poster ton /etc/hardware.conf ? (si poste les lignes : type PROC=machin

       BUSSPEED=chose

etc... 

Le script se viande parce qu'il ne trouve pas le type de processeur dans son tableau de nom, et donc, il ne sait pas dans quelle catégorie le classer. (Ce serait pas un K6 par hazard ?)

(Ne t'en fais pas, je m'attendais à ça, puisque la détection du matériel est certainement ce qu'il y a de plus difficile à faire, surtout sous Linux)

----------

## YuLin

Voici donc mon /etc/hardware.conf

```
PROCVAL=AMD Athlon(tm) XP 2500+

SPEED=1829.793

HT=no

NBPROC=1

MEMORY=512

GCARD=00.0 VGA compatible controller

GCARDMEM=64M

BUSSPEED=166Mhz+

MEMTYPE=DDRAM4200
```

Désolé si je fais perdre du temps =/

----------

## X-Ryl669

Efface InOut.py et InOut.pyc et relance le script (qui va retélécharger les nouvelles versions)... Et reessaye...

Désolé, je ne comprend pas pourquoi le script n'a pas détecté ton Athlon...

----------

## X-Ryl669

J'ai compris, en fait le script cherchait la chaîne "Athlon(R)" et non "Athlon(tm)". Comme je n'ai pas d'athlon, je ne me suis pas rendu compte de cette erreur... Ca devrait être fixé dans les nouveaux scripts...

Donc, effacement du fichier InOut.py et relancement du script en perspective...

----------

## YuLin

Que ce soit en supprimant InOut.py et InOut.pyc ou bien en essayant avec TOUS les nouveaux scripts, cflagselect.py y compris, j'obtiens ça :

```
[HCG] Downloading testable software list...                                                                                                         

(1) testme v0.1

(4) lame v3.96

(2) alma v1.0

(3) huff v1.0

[HCG] Please select a software to test : 4

[HCG] Testing : lame v3.96                                                                                                                  

[HCG] Download of lame in /tmp/ts/lame-3.96.tar.gz succeeded                                                                                      

[HCG] Download of TS/testlame in /tmp/ts/testlame succeeded

[HCG] Download of TF/test.wav in /tmp/ts/test.wav succeeded

[HCG] Download of GS/gslame in /tmp/ts/gslame succeeded

[HCG] GZipped tar found, reading it

[HCG] Archive found now and modified

[HCG] A problem occured while creating the command line
```

----------

## X-Ryl669

La joie du débugging à distance... Donc, cette fois ci, c'est dacovea qui n'a pas été nettoyé. Je te conseille d'aller dans le répertoire nommé dacovea-1.0/acovea-4.0.0 et de faire un make uninstall.

Ensuite tu peux supprimer ce répertoire dacovea-1.0

Si tu lance le script depuis le début, la bonne version de dacovea s'installe. Dans ton cas, le script s'emmèle et ne télécharge pas la bonne version, car il trouve l'ancienne dans le path. Et en l'occurence, le fichier de pool de cflags a changé, donc il ne peux construire la ligne de commande.

Une autre solution constiste à recréer ton fichier de cflags (ou à déplacer le tien), à mettre dans "/tmp/ts/gcc33_processor.dacovea" dans ton cas. Désolé, mais j'ai dû modifier ces scripts pour rendre une interface commune à tous.

----------

## YuLin

Youpéka ! Ca a fonctionné  :Smile: 

Magnifique, quelle joie de voir enfin :

```
[HCG] Report sent successfully to host

[HCG] Report sent successfully to host

[HCG] Report sent successfully to host
```

Je me doute bien que mon test du projet ne constitue certainement pas la majeure partie du débuggage mais je suis heureux d'avoir pu y contribuer  :Wink: 

NOTE : je vais donc lancer les tests sur mon P-III, maintenant  :Smile: 

----------

## X-Ryl669

Tu es maintenant dans la base de données, donc tout un chacun peut voir tes résultats (et toi aussi)...

Voila, merci pour ton soutien.

----------

## Pachacamac

Je vais me mettre à la tache pour vérifier que tout fonctionne bien. J'ai également un Athlon XP mais 1600+ seulement.

Je vous tiens informé.

EDIT : Oups je vais encore moins loin qu'avant. Je t'envoie un PM.Last edited by Pachacamac on Tue Jun 15, 2004 4:36 pm; edited 1 time in total

----------

## YuLin

 *X-Ryl669 wrote:*   

> Tu es maintenant dans la base de données, donc tout un chacun peut voir tes résultats (et toi aussi)...
> 
> Voila, merci pour ton soutien.

 

Je t'en prie. Je suis content de faire partie des premiers bêta-testeurs  :Wink: 

----------

## kernelsensei

```

config.status: creating mac/Makefile

config.status: creating config.h

config.status: executing depfiles commands

Found in ./mpglib/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./libmp3lame/i386/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./libmp3lame/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./frontend/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe  -I/usr/include/gtk-1.2 -I/usr/include/gli b-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include

Found in ./Dll/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./debian/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./doc/html/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./doc/man/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./doc/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./include/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./misc/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./dshow/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./ACM/ADbg/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./ACM/ddk/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./ACM/tinyxml/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./ACM/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./mac/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

Found in ./Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops                 - maccumulate-outgoing-args -Wall -pipe

[HCG] Archive found now and modified                                   [  OK  ]

[HCG]  A problem occured while creating the command line               [NOT OK]

```

j'obtient cette erreur pour lame

----------

## Martin LORANG

Bon, chez moi c'est beaucoup plus basique :

```
root@opteron ~/cflags_en_folie >ls -al

total 52

drwxr-xr-x   2 root root  4096 jun 15 20:00 ./

drwx------  15 root root  4096 jun 15 19:51 ../

-rwxr-xr-x   1 root root 35842 jun 15 17:39 InOut.py*

-rwxr-xr-x   1 root root   279 jun 15 17:39 Mirrors.py*

-rwxr-xr-x   1 root root   403 jun 15 11:41 Modify*

root@opteron ~/cflags_en_folie >cflagselect.py

Checking for package integrity...

Traceback (most recent call last):

  File "/root/bin/cflagselect.py", line 34, in ?

    import InOut

ImportError: No module named InOut

```

Martin

----------

## YuLin

 *Martin LORANG wrote:*   

> Bon, chez moi c'est beaucoup plus basique :
> 
> ```
> root@opteron ~/cflags_en_folie >ls -al
> 
> ...

 

Je pense que tu ferais mieux de laisser le script cflagselect.py dans le même répertoire que les autres scripts plutôt que de considérer l'utiliser en le mettant simplement dans ton path. Essaye donc, pour voir.  :Rolling Eyes: 

----------

## Martin LORANG

C'est exactement ça : il faut que cflagsselect.py soit dans le répertoire à partir duquel on lance la commande.

----------

## YuLin

 *Martin LORANG wrote:*   

> C'est exactement ça : il faut que cflagsselect.py soit dans le répertoire à partir duquel on lance la commande.

 

Depuis tout à l'heure je regarde le code de ces scripts et je me rends compte que le python est plutôt semblable au Java. Ayant une modeste expérience en Java, j'ai pu constater que les appels de classes sont similaires. C'est pareil, quand on veut appeler une classe externe avec import il faut s'assurer qu'elle se trouve dans un répertoire connu de la VM ou bien dans le répertoire courant. Maintenant, je ne suis pas expert  :Rolling Eyes: 

----------

## Pachacamac

 *kernel_sensei wrote:*   

> 
> 
> ```
> 
> config.status: creating mac/Makefile
> ...

 

J'ai exactement le meme probleme que toi. 

X-Ryl669 cherche la cause et il postera un remède ici.

----------

## Martin LORANG

Bon, maintenant c'est une erreur de compil :

Probablement quelque chose qui n'est plus accepté par gcc-3.4.0 et je ne veux plus voir gcc-3.3* sur mon système   :Razz:  gcc-3.4 étant le 1er qui utilise les possibilités de mon système...

En lançant :

```
CFLAGS="-g -pipe -O2 -fpermissive" CXXFLAGS=$CFLAGS ./cflagselect.py
```

l'erreur se transforme en warning...

----------

## YuLin

 *Martin LORANG wrote:*   

> Bon, maintenant c'est une erreur de compil :
> 
> Probablement quelque chose qui n'est plus accepté par gcc-3.4.0 et je ne veux plus voir gcc-3.3* sur mon système   gcc-3.4 étant le 1er qui utilise les possibilités de mon système...
> 
> En lançant :
> ...

 

Je ne comprends pas trop ta démarche en fait... Je ne vois pas pourquoi tu lancerais cflagselect.py avec des CFLAGS spécifiques, le but étant de déterminer les CFLAGS les plus pertinents  :Rolling Eyes: 

A moins que ce ne soit uniquement pour déterminer la cause du problème (oui, je pense que ce doit être ça)...

n'étant pas utilisateur de gcc-3.4.0 je ne peux malheureusement pas t'en dire plus...  :Confused: 

----------

## Martin LORANG

J'ai modifié dacovea-1.0/acovea-4.0.0/config/gcc34_pentium4.dacovea comme suit

```
<?xml version="1.0"?>

<acovea_config>

    <!-- Pentium configuration, for GCC 3.4 and later -->

    <description value="GCC 3.4 Opteron 244 (amd64)" />

    <command value="-O1|-march=opteron|-mtume=opteron|-ffast-math" />

```

Et maintenant je suis comme pas mal de monde avec :

```
config.status: creating config.h

config.status: executing depfiles commands

Found in ./mpglib/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops -Wall -pipe

Found in ./libmp3lame/i386/Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops -Wall -pipe

:

:

Found in ./Makefile

CFLAGS = -O3  -ffast-math                       -funroll-loops -Wall -pipe

[HCG] Archive found now and modified                                        [  OK  ]

[HCG]  A problem occured while creating the command line                    [NOT OK]
```

voilà voilà

----------

## Martin LORANG

 *YuLin wrote:*   

>  *Martin LORANG wrote:*   Bon, maintenant c'est une erreur de compil :
> 
> Probablement quelque chose qui n'est plus accepté par gcc-3.4.0 et je ne veux plus voir gcc-3.3* sur mon système   gcc-3.4 étant le 1er qui utilise les possibilités de mon système...
> 
> En lançant :
> ...

 

En fait c'est simplement pour compiler acovea and friends sans erreur. Après je lance simplement ./cflagselect.py

----------

## YuLin

A mon avis ce n'est pas forcément la même chose, mais si tu regardes plus haut, j'ai eu les même symptômes, alors il se pourrait que ce soit éventuellement le même problème.

As-tu donc essayé de copier ton fichier gcc33_processor.dacovea vers /tmp/ts/ et / ou de faire un make uninstall dans le répertoire dacovea-1.0/acovea-4.0.0/ et de relancer cflagselect.py pour qu'il réinstalle dacovea ?

Si non, essaye donc, ça ne te coûte rien ; si oui, alors je ne vois pas  :Rolling Eyes: 

----------

## Martin LORANG

 *YuLin wrote:*   

> A mon avis ce n'est pas forcément la même chose, mais si tu regardes plus haut, j'ai eu les même symptômes, alors il se pourrait que ce soit éventuellement le même problème.
> 
> As-tu donc essayé de copier ton fichier gcc33_processor.dacovea vers /tmp/ts/ et / ou de faire un make uninstall dans le répertoire dacovea-1.0/acovea-4.0.0/ et de relancer cflagselect.py pour qu'il réinstalle dacovea ?
> 
> Si non, essaye donc, ça ne te coûte rien ; si oui, alors je ne vois pas 

 

ça ne marche pas ici   :Sad: 

----------

## kernelsensei

 *Martin LORANG wrote:*   

>  *YuLin wrote:*   A mon avis ce n'est pas forcément la même chose, mais si tu regardes plus haut, j'ai eu les même symptômes, alors il se pourrait que ce soit éventuellement le même problème.
> 
> As-tu donc essayé de copier ton fichier gcc33_processor.dacovea vers /tmp/ts/ et / ou de faire un make uninstall dans le répertoire dacovea-1.0/acovea-4.0.0/ et de relancer cflagselect.py pour qu'il réinstalle dacovea ?
> 
> Si non, essaye donc, ça ne te coûte rien ; si oui, alors je ne vois pas  
> ...

 

Ben a priori ton erreur ressemble quand meme etrangement a la mienne

A mon avis la meilleure chose a faire c'est prendre son mal en patience et attendre des news de la part de X-Ryl669

----------

## Martin LORANG

Eh ouais, yapuka attendre...

----------

## kernelsensei

 *Martin LORANG wrote:*   

> Eh ouais, yapuka attendre...

 

aha, encore un mot en ya- c'est dingue hein ?

sinon ya aussi l'option demerden Sie sich !  :Wink: 

----------

## X-Ryl669

Bon, pour tous ceux qui ont le problème de 

[HCG]  A problem occured while creating the command line                    [NOT OK]

effacer le fichier InOut.py et laisser le script cflagselect.py le retélécharger.

L'erreur venait d'un cp unfichier sur_un_repertoire_pas_existant

Maintenant, ça devrait tourner assez bien!

Sinon, pour Martin, si tu précises les CFLAGS comme tu le fais, effectivement tu modifies les CFLAG pour la compilation de Dacovea, mais tu modifies aussi les CFLAGS d'origine du logiciel que tu testes (en l'occurence lame). Et comme j'utilise les CFLAGS d'origine pour calculer le gain au final, tes résultats ne seront pas comparables à ceux des autres. Ceci dit, pourquoi pas...

Si tu veux revernir dans la même configuration que les autres, supprime le répertoire /tmp/ts (ce qui supprimera lame par la même occasion), mais laisse dacovea installé (en gros ne fait rien de plus qu'arrêter le script s'il tourne, rm -rf /tmp/ts). Relance le script tel quel, dans le répertoire où il y a les autres scripts.

En effet les autres scripts DOIVENT IMPERATIVEMENT ETRE DANS LE MEME REPERTOIRE QUE CFLAGSELECT.PY 

Sinon, ça ne marchera pas, ou alors, vous seriez obligé d'installer ces scripts annexes dans le path de python (ce qui est une très mauvaise idée).

----------

## Martin LORANG

Effectivement ça a l'air de fonctionner maintenant.

----------

## kernelsensei

Maintenant c'est chez moi que ca foire :

```

make[3]: Entering directory `/root/dacovea-1.0/acovea-4.0.0'

make[3]: Rien à faire pour « install-exec-am ».

if test -d ./config; then \

  mkdir -p -- . /usr/local/share/acovea/config; \

  for cfgfile in ./config/*; do \

    if test -f $cfgfile; then \

      /bin/install -c -m 644 $cfgfile /usr/local/share/acovea/config; \

    fi \

  done \

fi

if test -d ./benchmarks; then \

  mkdir -p -- . /usr/local/share/acovea/benchmarks; \

  for benchfile in ./benchmarks/*; do \

    if test -f $benchfile; then \

      /bin/install -c -m 644 $benchfile /usr/local/share/acovea/benchmarks; \

    fi \

  done \

fi

make[3]: Leaving directory `/root/dacovea-1.0/acovea-4.0.0'

make[2]: Leaving directory `/root/dacovea-1.0/acovea-4.0.0'

make[1]: Leaving directory `/root/dacovea-1.0/acovea-4.0.0'

[HCG] Save the configuration file                                      [  OK  ]

[HCG] Cannot install DAcovea...                                        [NOT OK]

```

----------

## Martin LORANG

 *Martin LORANG wrote:*   

> Effectivement ça a l'air de fonctionner maintenant.

 Mais je vois dans les messages de compil de temps en temps l'erreur suivante:

```
error: -malign-double makes no sense in the 64bit mode
```

----------

## X-Ryl669

Petite remarque supplémentaire, le script cflagselect.py essaye de récupérer des manques de fichiers, corruptions, etc... 

Donc si quelque chose foire, voila les fichiers qu'il faut garder :

  - Dans /tmp/ts, les fichiers .out (pour ceux qui ont la chance d'avoir pu compiler) qui contiennent les résultats de la sélection par dacovea. VITAL (à moins que vous voulez tout refaire, mais bon...)

 - Dans /tmp/ts, les fichiers .run qui contiennent les sauvegardes inter-générations pour les calculs de dacovea. Sur lame, on peut tout lancer d'un coup (compilation en 40s sur un P4) mais pour les futurs projects tels que Mozilla, ou OpenOffice (compilation d'un à plusieurs jours), ce seront ces fichiers qui seront distribués via le prochain script. IMPORTANT

 - Dans /tmp/ts, le fichier gcc3{2,3,4}_processor.dacovea, contient la liste des CFLAGS à tester (si vous ne le modifier pas, vous pourrez l'effacer) OPTIONNEL

 - Dans /etc,  le fichier hardware.conf contient la detection de votre matériel. Je vous conseille de modifier/vérifier son contenu si la detection n'est pas géniale (genre BUSSPEED qui est différent de votre FSB, ou GCARD différent de votre carte graphique). Cependant, veuillez garder le même format (NOM=VALEUR) (jamais d'unité, pas de Mhz, MB, MO) IMPORTANT

 - Dans /tmp, le fichier .tslist qui contient la liste des logiciels "testables". Je vous conseille pour l'instant de le garder, je rejouterai la fonction sync bientôt pour le synchroniser. INUTILE

Pour désinstaller dacovea, il faut se rendre dans le repertoire dacovea-1.0

et faire un make uninstall

Voila pour l'info, je la ferais mettre sur le site bientôt.

----------

## X-Ryl669

A l'attention de Kernel_sensei, 

   C'est vraiment très étrange. Quel est le résultat de la commande "dacovea -v"  (sans ./ devant) ? Es-tu en root ?

Bonne chance...

A l'attention de Martin,

   Si tu vois de temps en temps ce message, c'est parce que dacovea essaye ce flag. Comme tu dois avoir un processeur en 64bit, ce cflag est périmé (inutile d'où l'erreur). Si ça te gène, modifie le fichier /tmp/ts/gcc34_processor.dacovea (pour supprimer la ligne où le flag apparait). Par contre tu seras obligé de tout relancer depuis le début (supprimer /tmp/ts/*.run).

----------

## kernelsensei

c'est bon, trouvé ..

pour passer en root j'utilise 

```
$ su
```

 et a priori en faisant ca il ne me met pas tous les path, en faisant 

```
$ su -
```

 ca marche ..

----------

## Pachacamac

En effet kernel_sensei c'est la différence qu'il y a entre les 2 commandes.

su garde le path de l'utilisateur qui passe en root tandis que su - donne l'identité root avec les paths root.Last edited by Pachacamac on Tue Jun 15, 2004 8:50 pm; edited 1 time in total

----------

## kernelsensei

 *Pachacamac wrote:*   

> En effet kernel_sense c'est la différence qu'il y a entre les 2 commandes.
> 
> su garde le path de l'utilisateur qui passe en root tandis que su - donne l'identité root avec les paths root.

 

oui merci, je sais m'ais j'avais pas tilté sur le coup !

----------

## Pachacamac

Ah mince j'ai écorché ton pseudo kernel_sensei, dsl   :Embarassed: 

Par contre j'ai toujours une erreur chez moi :

[HCG] Archive found now and modified                [  OK  ]

cp: Ne peut évaluer `dacovea-1.0/acovea-4.0.0/config/*.dacovea' par stat(): Aucun fichier ou répertoire de ce type

[HCG]  A problem occured while creating the command line  [NOT OK]

Je vais essayer de supprimer acovea, après je tente la compill et je vais au lit.

----------

## Martin LORANG

 *X-Ryl669 wrote:*   

> A l'attention de Martin,
> 
>    Si tu vois de temps en temps ce message, c'est parce que dacovea essaye ce flag. Comme tu dois avoir un processeur en 64bit, ce cflag est périmé (inutile d'où l'erreur). Si ça te gène, modifie le fichier /tmp/ts/gcc34_processor.dacovea (pour supprimer la ligne où le flag apparait). Par contre tu seras obligé de tout relancer depuis le début (supprimer /tmp/ts/*.run).

 

C'est ce que j'ai fait mais il reste plein d'erreurs style :

```
-==¤¤¤ [ 5 / 7 ] Running test, please wait  ¤¤¤==-layer3.c: In function `do_layer3':

layer3.c:1811: internal compiler error: in remember_web_was_spilled, at ra-build.c:2314

Please submit a full bug report,

with preprocessed source if appropriate.

See <URL:http://bugs.gentoo.org/> for instructions.

Preprocessed source stored into /tmp/ccuEgKqq.out file, please attach this to your bugreport.

make[2]: *** [layer3.lo] Error 1

make[1]: *** [all-recursive] Error 1

make: *** [all] Error 2
```

ou

```
-==¤¤¤ [ 7 / 7 ] Running test, please wait  ¤¤¤==-

SHORT RUN TIME ERROR:
```

ou très bizarre

```
CFLAGS= -O1 -march=opteron -mtune=opteron -ffast-math -fno-guess-branch-probability -fno-if-conversion -fno-if-conversion2 -fno-loop-optimize -foptimize-sibling-calls -fgcse -fforce-mem -fschedule-insns -fschedule-insns2 -fdelete-null-pointer-checks -fsched-interblock -fsched-spec -falign-loops -falign-jumps -falign-functions -fno-inline -fpeel-loops -funswitch-loops -maccumulate-outgoing-args -mno-align-stringops -minline-all-stringops -mfpmath=sse,387 -fno-math-errno -funsafe-math-optimizations

-==¤¤¤ [ 5 / 7 ] Running test, please wait  ¤¤¤==-quantize.c: In function `VBR_prepare':

quantize.c:1575: error: unable to find a register to spill in class `DREG'

quantize.c:1575: error: this is the insn:

(insn 37 41 768 0 (parallel [

            (set (reg:SI 37 r8 [395])

                (div:SI (reg:SI 0 ax [393])

                    (mem/s/j:SI (plus:DI (reg:DI 43 r14 [379])

                            (const_int 31920 [0x7cb0])) [0 <variable>.mode_gr+0 S4 A64])))

            (set (reg:SI 0 ax [394])

                (mod:SI (reg:SI 0 ax [393])

                    (mem/s/j:SI (plus:DI (reg:DI 43 r14 [379])

                            (const_int 31920 [0x7cb0])) [0 <variable>.mode_gr+0 S4 A64])))

            (clobber (reg:CC 17 flags))

        ]) 264 {*divmodsi4_cltd} (insn_list 34 (nil))

    (expr_list:REG_UNUSED (reg:CC 17 flags)

        (expr_list:REG_UNUSED (reg:SI 0 ax [394])

            (nil))))

quantize.c:1575: confused by earlier errors, bailing out

make[3]: *** [quantize.lo] Error 1

make[2]: *** [all-recursive] Error 1

make[1]: *** [all-recursive] Error 1

make: *** [all] Error 2

COMPILE FAILED:
```

----------

## Pachacamac

J'ai supprimé le dossier /usr/local/share/acovea mais cela n'a rien changé au problème.

Il ne me demande meme pas de le retelecharger. Aie j'ai tout cassé   :Sad: 

Mais ce n'est pas pour autant que je vais mal dormir  :Smile: 

Bonne nuit à tous et à toutes.

----------

## YuLin

 *Pachacamac wrote:*   

> J'ai supprimé le dossier /usr/local/share/acovea mais cela n'a rien changé au problème.
> 
> Il ne me demande meme pas de le retelecharger. Aie j'ai tout cassé  
> 
> Mais ce n'est pas pour autant que je vais mal dormir 
> ...

 

Supprimer le dossier c'est bien mais tu devrais aussi supprimer le binaire acovea dans /usr/local/bin/ sinon le script croira tu as encore l'application d'installée, ce qui est vrai.  :Rolling Eyes: 

----------

## YuLin

Bon, quant à moi, j'ai donc tenté de faire les même tests sur lame avec mon Pentium III. Tout, absolument tout a bien fonctionné sans la moindre erreur, sauf que voilà, à la fin, j'ai ça :

```
run complete time: 2004 Jun 15 23:01:19

 

optimistic options:

           -fno-if-conversion2 (1.835)

            -fcse-follow-jumps (1.313)

             -fcse-skip-blocks (1.661)

                     -fregmove (2.184)

  -fdelete-null-pointer-checks (1.138)

           -freorder-functions (1.313)

                      -ftracer (1.313)

                     -mieee-fp (1.138)

                -malign-double (1.487)

 

pessimistic options:

            -fno-if-conversion (-1.65)

                   -fforce-mem (-1.65)

                      -fnew-ra (-1.824)

                -funroll-loops (-1.999)

    -maccumulate-outgoing-args (-1.999)

                  -mfpmath=387 (-1.999)

              -mfpmath=sse,387 (-2.173)

     -momit-leaf-frame-pointer (-1.127)

   -funsafe-math-optimizations (-1.127)

[HCG] Test finished transmitting the result...                                                              

[HCG] Testing result is enabled so test is running                                                                      

[HCG] Testing with -O3 flag                                       

[HCG] Compilation took 71s

[HCG] -O3 returned 6.618 with binary size 314537 bytes                                                                                 

[HCG] Testing with fitted flags                                           

[HCG] Compilation took 79s                                        

[HCG] Dacovea flags returned 5.993 with binary size 314357 bytes                                                                                   

[HCG] Testing with original project flags                                                         

takehiro.c:1202: warning: `all_scalefactors_not_negative' defined but not used

[HCG] Compilation took 89s                                        

[HCG] Initial flags returned 6.294 with binary size 379756 bytes                                                                                   

[HCG] Cannot detect the processor...                                        [NOT OK]

[HCG] Please report the following to the site...                            [NOT OK]

Pentium III (Coppermine)

root@foo bar #
```

C'est quand même étrange ce "Pentium III" qui s'affiche juste avant de me filer le prompt  :Rolling Eyes: 

EDIT : OK, je viens de comprendre en regardant le script InOut.py : cette partie du script ne s'attend pas à trouver le " (Coppermine)" après "Pentium III". Je viens de modifier le script, ça devrait marcher.  :Wink: 

----------

## X-Ryl669

Martin, 

un utilisateur normal ne va pas tenter tous les flags que dacovea utilise. De plus, un utilisateur normal n'associe pas les flags stupides ou contradictoires comme -fieee-fp avec -funsafe-math-optimization. Dacovea, est bête et méchant, il essaye, et si ça foire, ça foire. 

Les messages d'erreur sont en fait ceux de gcc qui arrive soit à ne pas compiler le code (internal compiler error), soit à compiler un code foireux (qui est ensuite détecté par les fameux scripts de test des logiciels) SHORT TIME ERROR, soit se viander dans la compilation du langage intermédiare (c'est la première fois que je vois ça, ça doit être dû à gcc34). C'est pas grave, l'individu testé est éliminé de toute façon.

Pachacamac, 

   Suit les conseils de YuLin, supprime dacovea de /usr/local/bin... 

   Supprime /tmp/ts 

   Supprime tous les fichiers des scripts.

   Retelecharge les scripts, su, chmod +x et bonne chance. 

  (J'avais la même erreur que toi jusqu'à ce que je modifie le tar.bz2 de dacovea. Il faut impérativement que tu le retélécharge, ou que tu laisses les scripts le faire pour toi).

YuLin,

  Je modifie les scripts en consequence du fameux message que tu as posté. Tu peux essayer de modifier InOut.py, pour que ça passe. Je modifie InOut.py avec ton identifiant processeur (en fait, je l'ajoute à la liste des Pentium III (qui devrait être détecté)). Je reposte InOut sur le site dans quelque secondes...

----------

## YuLin

Youpéka ! Ma modification a tenu la route ! Donc ça marche ! Et un deuxième rapport de test ! Un !  :Smile: 

Faudrait vraiment revoir la fonction GetCompatibleProcID, parce qu'en théorie ça à l'air bon, mais va falloir la changer un peu...  :Rolling Eyes: 

----------

## Martin LORANG

Tout à la fin j'obtiens :

```
[HCG] Initial flags returned 2,768 with binary size 494407 bytes                                                                                                                           [  OK  ]

Traceback (most recent call last):

  File "/root/cflags_en_folie/cflagselect.py", line 154, in ?

    InOut.TransmitResult(listname[softname], dr, result, Conf, teston != -1)

  File "/root/cflags_en_folie/InOut.py", line 762, in TransmitResult

    Mean = float(o3[0]) + float(proj[0]) + float(dac[0])

ValueError: invalid literal for float(): 2,968
```

Avec :

```
LANG="C" ./cflagselect.py
```

ça fonctionne : les "," sont remplacés par des "." dans les nombres à virgule avec LANG="C" au lieu de mon LANG="fr_FR@euro" par défaut.

Les résultats ont du arriver !

Sur ce : bonne nuit  !

----------

## X-Ryl669

Martin, 

   Au vu de tes résultats, je te conseille de modifier le fichier gcc34_processor.dacovea en remplaçant la ligne 

<command value="-O1|-..." />

par 

<command value="-O3|-..." />

Je ne sais pas pourquoi c'est -O1 qui est sélectionné par défaut (erreur de ma part je pense)...

Bref, il faudrait que tu relance le script, encore une fois en ayant supprimé préalablement les fichiers lame.out lame*.run du répertoire /tmp/ts

Voila, sinon, bravo les gars, le système fonctionne.

----------

## X-Ryl669

Connaîtriez vous un site où sont recensés tous les noms des modèles de processeur existants (de l'AMD 486 à au cyrix 586 en passant par tous les Intels ?)

Je parle ici du nom que renvoie l'instruction assembleur CPUID (inscrit en ROM dans le processeur lui-même). Linux utilise ce nom pour l'afficher, mais il ne semble pas qu'il existe de règles pour ce nom.

J'ai déjà parcouru : https://forums.gentoo.org/viewtopic.php?t=103757&highlight=cpuinfo

et c'est grâce à ce thread que j'ai pu créer la fonction GetCompatibleProcID. Cette fonction manque de précision, d'où certaines erreurs que vous avez avant que le site n'envoie ces résultats.

----------

## YuLin

N'est-il pas possible dans cette optique d'utiliser plutôt les valeurs vendor_id, family et model ?

Ca serait moins contraignant au niveau de la fonction GetCompatibleProcID, bien qu'il faille à un moment donné pouvoir convertir ces informations données par des chiffres en chaînes comportant les noms réels des processeurs...  :Rolling Eyes: 

Je suis en train de googler un maximum pour trouver des trucs sur la détection de processeurs, je te tiens au courant.

----------

## X-Ryl669

C'est pareil, il faut trouver la correspondance vendor_id, family, cpu_id avec un type de processeur, et là, moi j'ai rien trouvé de vraiment satisfaisant sur google.

----------

## Martin LORANG

 *X-Ryl669 wrote:*   

> Martin, 
> 
>    Au vu de tes résultats, je te conseille de modifier le fichier gcc34_processor.dacovea en remplaçant la ligne 
> 
> <command value="-O1|-..." />
> ...

 

C'est exact il y avait bien un -O1 dans le fichier gcc34_pentium4.dacovea du répertoire config ? (je ne sais plus le nom précis, chuis pas devant ma machine).

Je le modifie (celui de /tmp/ts) en -O3. J'ai changé là dedans march=pentium4 en march=opteron et j'ai rajouté mtune=opteron. Est-ce OK ?

Si oui je relance...

Je n'ose même pas imaginer le temps que ça va prendre avec des paquets monstrueux comme kde ou autre, même sur ma machine somme toute très rapide   :Shocked: 

Martin

----------

## YuLin

Je viens de trouver quelque chose... ça vaut ce que ça vaut, mais cette page me semble pas trop mal :

http://www.paradicesoftware.com/specs/cpuid/index.htm

----------

## X-Ryl669

Oui c'est ça, il faut que tu relance.

C'est vrai que pour les packets type KDE, ça va être très long (si tu veux faire le test en entier d'un coup). Par contre, il est déjà possible d'interrompre dacovea entre chaque génération. Un fichier sauvegarde la génération en cours, et donc tu reprends de la dernière génération que tu as fini. Pour les projets conséquents, il sera possible de transmettre ces fichiers de génération au serveur, qui les redistribuera (d'où le nom de Distributed Acovea). Et donc, au lieu d'attendre (Taille de population (p) * Nombre de populations (n) * Nombre de Generations (g)) compilations, on pourra attendre que (Taille de population (p) * Nombre de populations (n)) (soit un gain de 4 par rapport à maintenant).

De plus, sur des projets comme KDE, l'optimisation aura un sens uniquement sur les librairies de KDE (et pas tous les soft). Donc comme les librairies KDE sont compilés en 4 heures sur ma machine, il faudrait, sur ma machine p * n * g * 4 heures = 5 * 7 * 4 * 4 heures = 560 heures (ou 24 jours complet) pour faire tous les tests. Ou 6 jours pour passer d'une génération à une autre.

Voila, rien n'est simple!!!

[edit] Zero en calcul mental !! Heureusement que Martin a l'oeil perçant ! [/edit]

----------

## X-Ryl669

YuLin, cette table n'est pas suffisante, car elle ne distingue pas les processeurs HyperThreading des autres (par exemple), ou les Athlon XP. Pour ce faire, il faudrait le champ Extended Family dans cpuinfo, mais on ne l'a pas. Sinon, il faudrait emettre l'instruction assembleur (cpuid) pour le lire nous même, mais alors là, en python, c'est pas facile du tout (obligé de faire une librairie en C que python utiliserait). Bref, la solution à partir du nom du processeur semble plus facile...

----------

## Pachacamac

Dans le fichier gcc33_processor.dacovea qui est maintenant crée tout seul j'ai march=pentium4 alors que j'ai un athlon XP.

Pendant la compill j'ai tout le temps : 

-==¤¤¤ [ 6 / 7 ] Running test, please wait  ¤¤¤==-

SHORT RUN TIME ERROR:

CFLAGS= -O3 -march=pentium4 -ffast-math -fno-merge-constants -fno-omit-frame-pointer -fno-cprop-registers -fno-loop-optimize -fcse-skip-blocks -fstrength-reduce -frerun-cse-after-loop -fpeephole2 -fschedule-insns -freorder-blocks -fsched-interblock -freorder-functions -falign-loops -falign-jumps -falign-labels -finline-functions -frename-registers -fprefetch-loop-arrays -freduce-all-givs -ftracer -mieee-fp -mno-push-args -maccumulate-outgoing-args -minline-all-stringops -fno-trapping-math

Je vais changer le fichier pour refaire les tests.

----------

## Martin LORANG

 *X-Ryl669 wrote:*   

> il faudrait, sur ma machine p * n * g * 4 heures = 5 * 7 * 4 * 4 heures = 80 heures (ou 3 jours complet) pour faire tous les tests. Ou 1 jours pour passer d'une génération à une autre

 

Sauf si je me trompe 5*7*4*4 = 560 heures (23.33 jours)  :Shocked: 

Et en plus 3 semaines après il y a une nouvelle version et on recommence...

----------

## X-Ryl669

Pachacamac,

 ça c'est etrange. Tu peux poster /etc/hardware.conf ?

Martin, oui c'est exact "je m'ai gouré", il faudrait 140 heures (6 jours) pour passer d'une génération à une autre. Et donc 24 jours pour un test complet. Par contre, si on réunit 4 configurations identiques, on peut avoir les résultats en 6 jours quand même (par la distribution des fichiers de générations). Lorsque la version change, comme tu dis, on peux tout relancer (mais alors c'est super long), ou réduire le nombre de génération et de population (par exemple 2 générations pour 3 populations de 3 individus), en partant des meilleurs CFLAGS trouvés dans la version précédente. Le temps total de calcul deviendrait 72 heures soit 3 jours. 

La première fois ça risque d'être assez long, c'est sur

----------

## Martin LORANG

bizarre maintenant ça se plante au bout de 10 minutes avec :

```
------------------------------------------------------------

[HCG] Test finished transmitting the result...                            [  OK  ]

[HCG] Testing result is enabled so test is running                        [  OK  ]

[HCG] Testing with -O3 flag                                               [  OK  ]

[HCG] Compilation took 24s                                                [  OK  ]

[HCG] -O3 returned 2.940 with binary size 355499 bytes                    [  OK  ]

[HCG] Testing with fitted flags                                           [  OK  ]

Traceback (most recent call last):

  File "/root/cflags_en_folie/cflagselect.py", line 154, in ?

    InOut.TransmitResult(listname[softname], dr, result, Conf, teston != -1)

  File "/root/cflags_en_folie/InOut.py", line 648, in TransmitResult

    resultfile = open(result, "r")

IOError: [Errno 2] No such file or directory: '/tmp/ts/lame.out'
```

et effectivement pas de lame.out  :Sad: 

----------

## X-Ryl669

En théorie, tu ne peux pas arriver à l'étape de transmission des résultats tant que tu n'as pas de /tmp/ts/lame.out (dacovea doit se relancer pour créer ce fichier). J'ai modifié récemment cette partie dans dacovea, et j'ai pu introduire un bug, il faut que je vérifie (mais cela me semble etrange)... As-tu vu le message de dacovea final, avec 

optimistics options :

   -ceflag (1.750)

   -unautreflag (1.251)

etc... ?

Si oui, alors, il faut absolument que je comprenne pourquoi il n'a pas écrit le fichier lame.out...

Sinon, relance le script, il relancera dacovea. Si tu as toujours les mêmes résultats, (c'est à dire la même erreur), alors c'est sur, c'est mon code qui se plante...

----------

## Martin LORANG

C'est toujours pareil, et j'ai bien fait

```
rm /tmp/ts/lame.0* /tmp/ts/lame.out
```

Et je ne vois pas les fameux messages

optimistics options : 

-ceflag (1.750) 

-unautreflag (1.251) 

etc...

----------

## X-Ryl669

Bah, c'est pas le bon fichier

```

rm /tmp/ts/lame*.run

```

au lieu de lame.0*... Mais je vais relancer un test complet chez moi dès ce soir...

----------

## Martin LORANG

J'ai effacé /tmp/ts/lame0* (il y a une erreur de frappe, aïe, dans mon message précédent)

j'ai donc bien effacé les bons fichiers.

----------

## X-Ryl669

Bon, je vérifie ce soir... Et je reposte ici.

----------

## GNUTortue

Bonjour,

Chez moi quand j'ai une erreur résolu y'en à une autre qu'arrive...

j'avait essayé de testé lame mais à la fin ça me donnait une erreur

en cherchant dans ce post j'ai pu lire que le prob ce résolvait en rajoutant LANG="C" mais ça me donne toujours la même erreur.

voyez plutôt :

```

[HCG] Testing : lame v3.96                                                                                         [  OK  ]

[HCG] Download of lame in /tmp/ts/lame-3.96.tar.gz succeeded                                                       [  OK  ]

[HCG] Download of TS/testlame in /tmp/ts/testlame succeeded                                                        [  OK  ]

[HCG] Download of TF/test.wav in /tmp/ts/test.wav succeeded                                                        [  OK  ]

[HCG] Download of GS/gslame in /tmp/ts/gslame succeeded                                                            [  OK  ]

[HCG] GZipped tar found, reading it                                                                                [  OK  ]

[HCG] Archive found now and modified                                                                               [  OK  ]

[HCG] Dacovea command line below \/\/\/                                                                            [  OK  ]

dacovea -config /tmp/ts/gcc33_processor.dacovea -srcdir /tmp/ts/lame-3.96/ -bts /tmp/ts/testlame -run /tmp/ts/lame000.run -out /tmp/ts/lame.out -g 4 -n 5 -p 7 -sr 0.15 -ir 0.143

[HCG] Report this command line if any problem(no tests) occured                                                    [ WARN ]

[HCG] Starting the test...                                                                                         [  OK  ]

[HCG] Test finished transmitting the result...                                                                     [  OK  ]

[HCG] Testing result is enabled so test is running                                                                 [  OK  ]

[HCG] Testing with -O3 flag                                                                                        [  OK  ]

[HCG] Compilation took 38s                                                                                         [  OK  ]

[HCG] -O3 returned 3,916 with binary size 318659 bytes                                                             [  OK  ]

[HCG] Testing with fitted flags                                                                                    [  OK  ]

[HCG] Compilation took 39s                                                                                         [  OK  ]

[HCG] Dacovea flags returned 2,992 with binary size 306052 bytes                                                   [  OK  ]

[HCG] Testing with original project flags                                                                          [  OK  ]

takehiro.c:1202: warning: `all_scalefactors_not_negative' defined but not used

[HCG] Compilation took 43s                                                                                         [  OK  ]

[HCG] Initial flags returned 3,306 with binary size 383910 bytes                                                   [  OK  ]

Traceback (most recent call last):

  File "/root/bin/cflagselect.py", line 154, in ?

    InOut.TransmitResult(listname[softname], dr, result, Conf, teston != -1)

  File "/root/bin/InOut.py", line 762, in TransmitResult

    Mean = float(o3[0]) + float(proj[0]) + float(dac[0])

ValueError: invalid literal for float(): 3,916
```

----------

## Martin LORANG

Il faut faire

```
LANG="C" ./cflagselect.py
```

ou

```
export LANG="C"

./cflagselect.py
```

Si ça ne marche toujours pas, il doit y avoir encore d'autres variables d'environnement qui contiennent fr quelquechose.

Fais un

```
set
```

et examine la liste et fais un

```
unset variable_incriminée
```

avant de relancer ./cflagselect.py

----------

## X-Ryl669

Donc, une nouvelle version pour la nuit...

Voila, là c'est une version majeure, donc il faut tout supprimer (désolé), à l'exception de /etc/hardware.conf.

Les changements sont :

  - Ajout de l'option -clean au script cflagselect.py pour tout nettoyer (désinstallation de dacovea et de tous les scripts à l'exception de cflagselect.py)

  - Ajout de l'option -update au script cflagselect.py pour retélécharger les scripts

  - Ajout de l'option -sync au script cflagselect.py pour mettre à jour la liste de logiciels

  - Ajout de l'option -help ou --help au script cflagselect.py pour afficher les options

  - Correction d'un bug majeur dans Dacovea, mis en évidence par Martin.

  - Correction de l'erreur dûe au float en . ou en , (et ce, indépendament de la variable LANG)

  - Ajout de quelques processeurs dans leur détection, et modification automatique du fichier gcc33_processor.dacovea.

  - Dacovea compile sur gcc34 sans le flag -fpermissive

  - les AMD64 devraient être détectés

  - d'autre modifications mineures

Voila, bonne chance

----------

## Pachacamac

J'ai lancé la compill en milieu d'après midi et ce n'est toujours pas fini   :Rolling Eyes:  (il est 00:50)

Mon processeur est un 1600+, il est occupé entre 40% et 60% en plus de la compill mais cela me parait tout de meme tès long.

Combien de temps mettez vous pour finir tous les tests ?

----------

## YuLin

En ce qui me concerne les tests n'ont pas pris plus de 3h avec mon Barton 2500+ et mes 512 MB de RAM.

----------

## X-Ryl669

Normalement, tu as une barre de progression (Genre Generation X/Y, Testing population Z/T, Running Test P/M). 

Pour savoir où tu en es, dis toi qu'il faut que tu ai fait Y*T*M compilation, et que tu en es à X*Z*P / Y*T*M. Voila...

J'avais pensé à faire une estimation du temps restant, mais j'ai eu peur que cela effraie   :Wink: 

Serieusement, le temps des compilations varie beaucoup en fonction des paramêtres et donc il est difficile de prévoir...

----------

## Pachacamac

Ah ca y est les tests sont finis !!!   :Razz: 

```
[HCG] Test finished transmitting the result... [  OK  ]

[HCG] Testing result is enabled so test is running [  OK  ]

[HCG] Testing with -O3 flag                               [  OK  ]

[HCG] Compilation took 158s                            [  OK  ]

[HCG] -O3 returned 10.749 with binary size 319245 bytes [  OK  ]

[HCG] Testing with fitted flags                           [  OK  ]

[HCG] Compilation took 175s                            [  OK  ]

[HCG] Dacovea flags returned 9.559 with binary size 318253 bytes [  OK  ]

[HCG] Testing with original project flags             [  OK  ]

takehiro.c:1202: warning: `all_scalefactors_not_negative' defined but not used

[HCG] Compilation took 186s                            [  OK  ]

[HCG] Initial flags returned 10.722 with binary size 383888 bytes [  OK  ]

Traceback (most recent call last):

  File "./cflagselect.py", line 154, in ?

  File "./InOut.py", line 730, in TransmitResult

  File "/usr/lib/python2.2/random.py", line 349, in randint

    return self.randrange(a, b+1)

  File "/usr/lib/python2.2/random.py", line 313, in randrange

    istop = int(stop)

OverflowError: long int too large to convert to int

```

Il y a des petites erreurs à la fin. Est ce "normal" ?

----------

## Martin LORANG

Bon, j'ai tout viré ce matin :

```
rm -rf /tmp/ts

make uninstall     (de acovea)

rm -rf *   (dans le répertoire de lancement de cflagselect.py)
```

retéléchargé le script cflagselect.py et recommencé à zéro.

Résultat :

installation et compilation OK sans aucune bidouille  :Very Happy: 

Personnalisation de gcc34_processor.dacovea

Démarrage du test, et au bout de 14 minutes :

```
------------------------------------------------------------

[HCG] Test finished transmitting the result...                                           [  OK  ]

[HCG] Testing result is enabled so test is running                                       [  OK  ]

[HCG] Testing with -O3 flag                                                              [  OK  ]

[HCG] Compilation took 25s                                                               [  OK  ]

[HCG] -O3 returned 2,966 with binary size 355499 bytes                                   [  OK  ]

[HCG] Testing with fitted flags                                                          [  OK  ]

Traceback (most recent call last):

  File "/root/cflags_en_folie/cflagselect.py", line 223, in ?

    InOut.TransmitResult(listname[softname], dr, result, Conf, teston != -1)

  File "/root/cflags_en_folie/InOut.py", line 661, in TransmitResult

    resultfile = open(result, "r")

IOError: [Errno 2] No such file or directory: '/tmp/ts/lame.out'

real    13m48.545s

user    9m54.207s

sys     2m40.519s

root@opteron ~/cflags_en_folie >ls -al /tmp/ts

total 4052

drwxr-xr-x   3 root   root    4096 jun 17 08:50 ./

drwxrwxrwt   3 root   root    4096 jun 17 08:50 ../

-rw-r--r--   1 root   root    2973 jun 17 08:37 gcc32_pentium4.dacovea

-rw-r--r--   1 root   root    4607 jun 17 08:37 gcc33_pentium4.dacovea

-rw-r--r--   1 root   root    5060 jun 17 08:37 gcc34_pentium4.dacovea

-rw-r--r--   1 root   root    5060 jun 17 08:37 gcc34_processor.dacovea

-rwxr-xr-x   1 root   root     167 jun  6 18:07 gslame*

-rw-r--r--   1 root   root       0 jun 17 08:37 lame000.run

drwxrwxrwx  13 martin 1000    4096 jun 17 08:37 lame-3.96/

-rw-r--r--   1 root   root 1254175 avr 11 18:00 lame-3.96.tar.gz

-rwxr-xr-x   1 root   root    1244 mai 29 15:59 testlame*

-rw-r--r--   1 root   root 2833964 mai 23 19:53 test.wav
```

comme hier.  :Sad: 

----------

## X-Ryl669

A l'attention de Pachacamac,

   Cette erreur est vicieuse, car elle dépend de la version de python. L'erreur venait de mon script, mais n'était pas détectée par python 2.3, alors qu'elle l'est dans la version 2.2. 

La fonction randint(a,b) (qui renvoie un nombre entre ses arguments, renvoie en fait un nombre entre a et b+1. Ayant mis 2^32 pour b, j'ai un overflow (2^32 + 1 ne rentre pas dans 32 bits)... Problème de documentation en l'occurence. Mais c'est corrigé. 

Donc cflagselect.py -update

A l'attention de Martin, 

   Je ne sais pas pourquoi tu n'as pas de lame.out. Tu devrais l'avoir si tu as installé la dernière version de dacovea (de 01:00 am ce matin) Les raisons possibles sont : la version de dacovea dans le path ne tombe pas sur la dernière version installée. Je te PM la marche à suivre pour verifier.

----------

## GNUTortue

C'est normal que si je met autre chose que lame ça me donne :

 *Quote:*   

> [HCG] Testing : testme v0.1                                                                                        [  OK  ]
> 
> [HCG] Download of testme in /tmp/ts/coco.com succeeded                                                             [  OK  ]
> 
> [HCG] Download of None in /tmp/ts/None succeeded                                                                   [  OK  ]
> ...

 

// Edit

DSL question idiote c'est noté sur le site que seul lame fonctionne ...  :Embarassed: 

----------

## X-Ryl669

Nouveauté concernant le site, et les scripts.

La nouvelle version de dacovea précise le temps restant par run, enlève les caractères japonais que certains auraient pû observer.

Les scripts proposent une gestion des interruptions améliorée (plus de KeyboardInterrupt pythonnien). Il est maintenant possible de vérifier avec ces propres Cflags si les performances de Dacovea sont meilleures. Pour cela, une nouvelle option est gérée pour le script cflagselect.py. Il s'agit de l'option -cflag /CHEMIN/NOMDUFICHIER. 

Cette option nécessite la création d'un fichier contenant la liste de vos cflags (un simple copier coller du contenu de la variable CFLAG de /etc/make.conf dans un fichier devrait suffire). C'est le même format que pour le fichier lame.out, à savoir, soit tous les flags à la suite séparés par des espaces, soit un flag par ligne.

Enfin, les possesseur de Pentium / Pro / II / III devraient pouvoir maintenant envoyer leurs résultats sans interventions humaines (détection correcte de leur processeur).

Le site web est remanié, plus complet. Il intègrera peut être des publicités google, afin de financer le stockage sur un serveur mutualisé, et un vrai nom de domaine. 

A ce propos, si certains d'entre vous connaissent le service AdSense de google, est-ce rentable, combien gagne-t-on (assez pour financer un service Webhosting?) ? 

Si vous voyez des pub google, cliquez vous dessus ?

Goggle, PayPal ?  

Voila.

----------

## Martin LORANG

 *X-Ryl669 wrote:*   

> Les scripts proposent une gestion des interruptions améliorée (plus de KeyboardInterrupt pythonnien).

 

J'aurais préféré "pythonnesque" ça aurait fait plus pittoresque   :Laughing:   :Laughing:   :Laughing: 

----------

## Martin LORANG

Trève de rigolade : je vais essayer.

----------

## Pachacamac

Je ne sais pas du tout combien rapportent les pubs de google. ce n'est pas précisé dans le contrat ?

Habituellement je ne suis jamais intéressé par les sites qui font leur pubs mais je clique régulièrement dessus pour aider le site que je visite. Cela ne coute rien, seulement un peu de temps, alors pourquoi s'en priver ?

Je vais revoir le site pour les modifs. 

Un changement qui pourrait etre fait concerne ton script. Par exemple indiquer la dernière mise à jour serai un plus.

----------

## X-Ryl669

C'est pas bête, je n'y avais pas pensé...

Merci, je vais voir ça.

----------

## Skarsnik

J'ai pas lut tout le thread, mais c'est cool d'avoir les meilleurs perfs, ensuite faut savoir si ça empèche pas d'autre truc de marcher, je pense notament à X en -O3 qui fait faire des trucs chelou.

De toute façon je pense pas que gentoo descendra en dessous des perfs que j'ai vu sur certaine LFS.

Ensuite faut considérer le temps de compile aussi, 

Bon allez les jacky amusez-vous bien et bonne compile  :Smile: 

----------

## X-Ryl669

Bon, je pense que le premier beta test va s'arrêter là. Je me suis rendu compte qu'il y avait un gros problème au niveau de la gestion des cflags pour l'affichage. 

Pour corriger ce bug, je dois modifier la gestion de la base de données, ainsi que les scripts clients. Je pense que ça va me prendre une bonne semaine. 

Durant cette semaine, l'ajout de résultat ne fonctionnera plus. Les résultats en cours seront effacés (désolé...  :Crying or Very sad:  ), car il manque des informations pour pouvoir permettre le tri correct (essayer de voir les résultats pour l'AMD64 à 2Ghz, sur le site, vous comprendrez).

Ce n'est donc plus la peine de faire tourner vos machines... (pour l'instant).

Je reposterai ici, dès que les modifications seront validées, pour enfin lancer de nouveaux tests (qui cette fois seront définitifs). Les corrections des bugs seront conservées, de même vos suggestions seront implémentées. Les nouveaux scripts permettront d'interroger la base de donnée afin de connaître, étant donné votre config, si des résultats existent, et dans ce cas, quels sont les meilleurs CFLAGS. Ce sera basé sur un taux de confiance (100% si vous avez déjà fourni des résultats avec votre machine, 90% si quelqu'un autre possédant le même processeur mais pas à la même vitesse, etc...). Le script vous demandera alors, soit de refaire les calculs, soit d'utiliser les résultats existants. (Avec un "Fortement recommandé" si le taux de confiance est faible, "Peu recommandé" s'il est fort, etc...).

Voila, la release approche...

Merci à tous pour votre soutien, je vous recontacterai dès que j'aurais de nouveaux tests à faire.

----------

## Martin LORANG

 *X-Ryl669 wrote:*   

> Je pense que ça va me prendre une bonne semaine.

 

Du neuf ?   :Wink: 

----------

## kernelsensei

 *Martin LORANG wrote:*   

>  *X-Ryl669 wrote:*   Je pense que ça va me prendre une bonne semaine. 
> 
> Du neuf ?  

 

ah tiens, tu vis encore toi ?  :Very Happy: 

----------

## X-Ryl669

Bon,

   Où en est-ce ? 

Pour tout vous dire, j'ai arreté de développer sur HCG depuis juillet. 

Je ne suis pas désinterressé du projet, mais je suis plus pris actuellement par le portage du drivers de ma Webcam (Zc0301, Zc0302, Zc0301+) sous Linux. Je pensai pouvoir faire les deux en parallèle, mais visiblement je n'y arrive pas.

  Je n'ai pas non plus de nouveauté de la part de Cocoon, visiblement, il attend que j'avance pour s'y remettre aussi.

Donc, non, je n'arreterai pas de développer mais je suis pris pour le moment. Sans faire de vaines promesses, je pense finir mes autres développements bientôt.

Voilà, 

A+ 

X-Ryl669

----------

## d00by

bonjour a tous

je viens de lire les 6 pages (histoire de ne pas en perdre une miette

mais je vois que la derniere page date de 2004, ou en est ce projet

qui commencé fort bien?

exsiste t'il toujours, ya t'il un équivalent si celui là a était abandonné?

a bientot

d00by

----------

## gaga

pas de réponse ?

je trouve le sujet interessant.....

----------

## kwenspc

ça c'est ce qui s'appelle du déterrage de topic...  :Neutral: 

----------

## ryo-san

 :Very Happy: 

Bon bah puisqu'il est la, depuis les cflags par ebuild sont possibles avec bashrc-ng

et je crois qu'il y a encore une autre maniere mais je la retrouve plus ...

----------

## Volodim

gaga> Mouais après 2 ans d'inactivité, t'aurais pu te douter que le projet est un peu muerte ...

----------

