Curiosité sur temps d'executions

Bonjours,

je suis très surpris de voir que lorsque j'execute mon programme en C fraichement compilé (sur une mandriva, avec gcc, sans options particulières), il met environs 10 secondes pour s'executer.

Et que si je le relance desuite, qu'il mette seulement 1 seconde!

Je ne suis pas un codeur fou en C, mais je pense avoir suffisement de bon sens pour qu'il n'y ai pas d'abberations dans le code.

Mais ça me laisse l'impression que j'ai zappé un truc. Mon programme utilise une API assez particulière de bioinformatique (ACNUC), une sorte de SGBD qui recherche dans des banques de fichiers en local. J'en traite les résultats très succintement puis ecrit tout en sortie standard formatée.

Avez vous déjà rencontré ce "phénomène"!!??!!
Avez vous une idée ???? ... ???

Je vous remercie bien fort d'avance

Yan

PS : tous devant TF1 ce soir :)

Hum...Comme ca, dans le vide, si ton programme utilise un SGBD qui tourne indépendamment et en continu, je pense que le responsable de cette "accélération" est ton OS.

Lorsque tu executes ton programme, il va faire appel a la SGBD, qui va demander a l OS de récuperer des données. Celles ci ne se trouvant pas en mémoire, l OS les charge depuis le disque vers la mémoire (processus lent). Puis le SGBD envoie les données vers ton programme qui les traite et quitte.

Si tu le relances de suite, comme la SGBD n'a pas arrété de tourner, et que peu d'applications ont eu besoin de mémoire entre temps, il est fort probable que la plupart des données soient encore en mémoire. La lecture disque n'est donc pas nécessaire, les données sont directement récupérées dans la mémoire qui est beaucoup plus rapide et ton programme récupere ses données beaucoup plus rapidement.

Cependant, comme je l'ai dit, cette hypothese n'est valable que si le SGBD n'est pas ton programme lui meme mais un autre programme indépendant. En effet lorsque tu quittes un programme, les pages mémoires associées sont libérées.

Oui voilà le truc c'est que c'est pas vraiment un SGBD mais une API en C de fonctions qui permettent de récuperer depuis une banque de fichiers des infos.

J'ai cette intuition que tout est en place dans la mémoire vive à l'execution suivante. Un collègue m'a dit que le cache du disque dure devait y être aussi pour quelque chose.

Mon programme génère quand même un fichier de 1,7M pendant ces 1s.

Du coup je me demandais si il n'y avait une possible optimisation là dessous? C'est assez mystérieux et puissant tout ça. Comme reserver "moi même" une zone de la mémoire contigue ou je sais quoi d'autre.

Bref!

Merci pour la piste :)

Yan

Ca le fait pour tout sgbd... ou plus generalement pour tout programme faisant des acces disque.. forcément, l'acces disque c'est ce qui est le plus craignos pour les perfs

En fait il ne s'agit pas d'un sgbd type serveur, un processus qui tourne en tache de fond et qu'on solicite au besoin.

Ce sont vraiment que des fonctions performantes qui permettent d'acceder à des fichiers structurés en l'occurence sur mon disque dure.

Donc en fait cette API qui simule un SGBD "nait et meurt" avec mon executable.

Ce que je ne comprends pas c'est que lorsque je relance mon executable, normalement il refait les mêmes choses. Mon ordi ne sait pas, a priori, que j'ai déjà executé les même commandes auparavent et pourtant je passe de 10 secondes à 1 seconde bordel !!!!!??!!??!!
Mon ordi "comprendrait" qu'à la 2ème execution il est en train de refaire les mêmes taches et que du coup il s'économiserait un acces au disque pour directement utiliser le cache????

En plus ça a beau me torturer l'esprit mais ça m'interesse drôlement de pouvoir contrôler ce truc puisque j'aurais besoin d'executer ce programme séquentiellement (juste en changeant "un champ" dans mes "requetes").

J'en fait appel aux gouroux du hardware et du C qui auront la grâce de m'éclairer ! :)

Merci aussi vous deux et désolé, c'est n'est pas aussi simple :(

Yan

Salut,

Ben c'est normal la mémoire cache se souvient de la première instance. On retrouve ce problème avec les applications java, lentes à démarrer, mais une fois installées, assez rapides.

A mon avis c'est plus un problème de hard-ware que de programmation...

Donc l'ordi, avant d'acceder au dure comme doit lui demander le processeur ou je ne sais quel autre chipset, il regarde toujours dans la mémoire vive en cache au cas ou par hasard ça n'y serait pas déjà, et dans ce cas il économiserait le temps d'acces disque.
Ca me parait couteux quand même car en info, à priori, on prévois pas que 2 opérations identiques soient faites en succesivement?!

Je vais voir du côté des cracks du hardware et vous tiens au courant!

Merci,

Yan

Citation:

---

Donc l'ordi, avant d'acceder au dure comme doit lui demander le processeur ou je ne sais quel autre chipset, il regarde toujours dans la mémoire vive en cache au cas ou par hasard ça n'y serait pas déjà, et dans ce cas il économiserait le temps d'acces disque.
Ca me parait couteux quand même car en info, à priori, on prévois pas que 2 opérations identiques soient faites en succesivement?!

---

Lire la memoire ne coute quasiment rien (quelques nano secondes)...Lire le disque coute 1 million de fois plus (quelques milli secondes) car il faut deplacer des pieces mecaniques qui vont donc pas aussi vite que les electrons de ta memoire. Donc ya pas photo, il faut toujours verifier la RAM avant d'aller chercher quoiquecesoit sur le disque. ;)
Et contrairement a ce que tu pourrais croire, ces acces memoire marchent plus de 90% du temps : Ton OS "prevoit" ce que tu vas faire. Pour prendre un exemple tres simplifié, il suppose que si tu demandes le bloc A, il est fort possible que le bloc A+1 (la suite de ton programme) t'interesse et il le garde en mémoire.

Sinon concernant ton programme, puisque le SGBD meurt avec ton programme, c'est effectivement probablement ton cache disque qui joue plutot que la RAM. Si les infos sont deja dans le cache, il n'y a pas besoin de bouger les tetes de lecture, et tu economises un temps precieux (comme je l'ai dit plus haut, c'est toute la mecanique qui est lente dans les acces disque). On descend a des temps de l'ordre de la micro seconde (le temps que ton disque soit averti et qu'il renvoie les infos sur son bus qui est plus lent que celui sur lequel fonctionne la RAM)

Quant a une eventuelle optimisation, je ne pense pas que ce soit possible. 1: Tu ne peux pas controler le cache de ton disque dur (et encore moins avant de lancer ton programme). 2: Ton OS est normalement pensé pour optimiser ces performances autant que possible. 3: La seule optimisation possible ce serait de mettre tous les fichiers de la SGBD sur des blocs contigus afin de limiter le deplacement mecanique. Mais :
1- il est possible que ton OS est deja fait ce boulot
2- ca demande une connaissance des algorithmes de recherche de disque, et une gestion du hardware directement dans ton programme C, ce qui est bien trop couteux en terme de temps de developpement pour ce que tu vas y gagner.

Tiens une recherche rapide sur google m'a donné ce lien, avec une question proche de la tienne, et une reponse pertinente qui t'explique comment tout ceci fonctionne : http://www-gatago.com/fr/comp/develo.../20109633.html

Wouhahou!

Merci pour la réponse! Le lien est effectivement très interessant, un peu costaud pour moi, mais quand même pas mal.
En fait ça m'inspire bien de faire par paquets des """requetes""", donc des acces disque mutualisés, puis les traités et enfin écrire par paquets dans un fichier de sortie les résultats (je crois que c'est l'utilisation séquentielle dont parle le lien?)
Il va juste falloir que je sois raisonnable dans la taille que ces paquets vont occuper dans la RAM.
Ce que tu dis sur prendre les blocs suivant chargés dans la RAM explique en fait pourquoi c'est mieux de mettre ses variables en une zone contigue de la RAM?!

Super les gars vous êtes parfait, vous irez au paradis :ccool:

Yan

Tu dis que ca passe de 10 secondes a 1 seconde mais tu n as pas dis combien de fois tu as pu observer cela.

Tu as utilise un profiler ?

Citation:

---

Envoyé par wonderyan

PS : tous devant TF1 ce soir :)

---

Ah ouais !!! Il y a des cours de langage C sur cette chaine ??

TF1 non en plus j'ai regretté de leur faire de la pub! C'était juste un acces de baufitude pour l'OL qui jouait son "grand" match...

Pour le profiler je ne vois pas trop ce que c'est je vais checker ça la semaine prochaine.
Mais oui c'est systématique le 10 sec -> 1 sec. Si vous êtes curieux voici en gros l'algo en langage naturel. Le but est de fournir un service de mise a jour d'une base de donnée bioinfo en back office sur un serveur au taquet (pbil) :

Code:

---

1 2 3 4 5 6 7 8 9 10

pour tout ce qui a un champ X égal à "A" pour tout ce qui a un champ Y égal à "B" pour chaucun des 64 éléments Z possibles de chaque éléments Y parcourir la longue chaine de caractères (disons 2000, c'est de l'adn) rechercher une séquence de 4 caractères plus recuper d'autres infos relatives a ces éléments écrire ce qu'il me faut au format tabulé sur une ligne   => avec au final un nombre de 7 qui varie de 18000 à 30000 (mais à 30000 l'écart est un peu moins réduit)

---

et donc j'envisage de prendre par paquet les X, les Y et les Z dans un tableau, les traiter ensuite puis les écrire aussi par paquets apres.
Mais en fait je me demande si le cache du disque dure ne le fait pas lui même (pendant le premier lancement de 10 sec je vois le témoin s'allumer tres brièvement et régulièrement...)

Merci les gars

Yan

et tu peux pas les attaquer drectement, les fichiers ??

Ca me prendrait trop de temps de codage de réaliser un parseur en C !!!!!!!!!!!!!!!!!!!!!!
C'est terriblement galère, et je trouve la bibliothèque standard pas top pour ce qu'elle offre.
Chaque langage son domaine.
Je veux bien en perl mais alors c'est plus 10 secs que ça risque de mettre!
Non mais je me contente très bien de ce temps d'execution faut pas pousser mémé.
C'est juste si y'a moyen de faire 10 fois plus vite avec une belle astuce je prend.

Bon week end à tous,

Yan

Bonne remarque. Du code dédié sera probablement plus rapide qu'une API générique.
Ecrire un parser en C est très rapide ... Juste par curiosité tu pourrais montrer un mini-exemple de banque locale de fichiers? Si après vérification il s'avère que le prog est effectivement plus rapide qu'en passant par l' API, ça vaut le coup.