vitesse d'exécution du code C vs temps d'accès aux données

Bonjour,
j'ai un programme en C dont je crois qu'il est freiné par le temps d'accès à quelques données qu'il a en mémoire, et auxquelles il doit comparer incessamment de nouvelles tentatives qu'il fait.
Ces données peuvent être réduites à des groupes de trois bits (valeur de 1 à 8) dont il me faut trois pour décrire un "pas" (soit 9 bits).
Si chaque tiers de pas est stocké dans un mot-mémoire, il me faut le temps de trois accès mémoire pour récupérer la description d'un "pas" complet avant d'y comparer la nouvelle tentative.
J'hésite à concaténer les trois tiers de pas en 9 bits consécutifs pour un "pas", et je pourrai alors stocker 3 "pas", soit 27 bits, dans les 32 bits d'un mot de PC, mais il me faudra alors exécuter des décalages et des opérations sur bits pour récuperer chacun des tiers de chacun de mes "pas".
Combien d'opérations simples de ce genre puis-je me permettre de faire, tout en gagnant du temps par rapport aux 9 accès mémoire dont j'ai besoin quand tout est stocké séparément ? (ma machine est un PC à pentium sous W2000)
Merci,
David

Citation:

---

Envoyé par dva2tlse

Bonjour,
j'ai un programme en C dont je crois qu'il est freiné par le temps d'accès à quelques données qu'il a en mémoire

---

Des outils permettent de connaitre en détails la repartition du temps d'execution d'un programme. Cela pourait permettre de vérifier que ce sont bien les accès en mémoire qui sont lent, avant de modifier du code qui n'est peut être pas la cause du problème de rapidité.
Deux outils unix:

Code:

---

gprof myprog

---

ou
callgrind (maintenant inclu avec valgrind)

Code:

---

valgrind --tool=callgrind --dump-instr=yes ./myprog

---

Il fourni un fichier callgrind.out a visualiser avec par exemple kcachegrind:

Code:

---

kcachegrind callgrind.out

---

Ca ne répond pas directement à votre problème mais ça peut etre utile.

edit: Je n'avais pas vu que c'est sous W2000 mais il y a surment des outils equivalent.

totaliou merci; est-ce que les outils en question seront automatiquement disponibles sur les SUN-chaipakoi là où je bosse ?

Citation:

---

Envoyé par dva2tlse

est-ce que les outils en question seront automatiquement disponibles sur les SUN-chaipakoi où je bosse ?

---

Aucune idée.
En cherchant "Performance Profiling Tools" (nom pour ces outils)
je suis tombé sur:
http://docs.sun.com/app/docs/doc/802...9egm606?a=view

Gprof et valgrind sont des outils très souvent inclus dans les conf. quand ils sont disponible sur le systeme, donc il y a des chances pour qu'ils y soient.

...mais est-ce que t'as une idée du nombre d'instructions (ou même un vague ordre de grandeur, 1, 10, 100 ?) qui peuvent être faites pendant la durée d'un accès mémoire ?

Citation:

---

Envoyé par dva2tlse

...mais est-ce que t'as une idée du nombre d'instructions (ou même un vague ordre de grandeur, 1, 10, 100 ?) qui peuvent être faites pendant la durée d'un accès mémoire ?

---

Non, et avec les caches données et instructions des processeurs modernes, ça peut varier énormément...

Bonjour Emmanuel, mais est-ce qu'il y a sous W2K un moyen de connaître le temps qui s'écoule dans chacune de mes fonctions pour passer certaines variables en register ou essayer d'en diminuer le nombre ?
J'ai un vieux Visual C++ 5.0 et developer studio 97 dont je ne sais me servir qu'en éditeur.
merci

Citation:

---

Envoyé par dva2tlse

est-ce qu'il y a sous W2K un moyen de connaître le temps qui s'écoule dans chacune de mes fonctions pour passer certaines variables en register ou essayer d'en diminuer le nombre ?
J'ai un vieux Visual C++ 5.0 et developer studio 97 dont je ne sais me servir qu'en éditeur.

---

register ne servira à rien. Tu dois d'abord diagnostiquer ton programme avec un profiler. Il doit en exister sous Windows (gprof etc.) ou dans VC++5 (pas sûr... c'est vieux).

Une fois que tu as identifié les fonctions où le CPU passe le plus de temps, tu dois travailler l'algorithme pour qu'il soit le plus efficace possible. Il faut pour ça commencer par mesurer sa complexité. En gros, O log(n), c'est bien et O exp(n), c'est mal. Entre les deux, ça peut aller... Ca dépend de la sollicitation...

Une fois l'algo retravaillé, tu refait un profiling. Normalement, il ne devrait plus y avoir d'effet de pic sur telle ou telle fonction. Si c'est le cas, retravailler les fonctions 'dominantes'... Il faut aller vers un équilibre.

Si toutes ces manips ne suffisent pas à 'entrer dans les clous', tu peux attaquer la micro optimisation. Mais n'essaye pas de faire mieux que compilateur sur une architecture multi-core avec pipe-lines et caches dans tous les coins...

j'ai réussi à faire fonctionner et utiliser le profiler qu'il y a avec VC++5.0, et il m'a montré comme je m'y attendais que la fonction qui fait beaucoup d'accès à la mémoire est une des plus limitantes; mais il m'en a aussi montré d'autres qui n'étaient limitantes qu'à cause d'une programmation malheureuse.
Donc ça avance; merci à totaliou de m'avoir ouvert les yeux sur l'existence de cet outil et à Emmanuel d'avoir confirmé la pertinence de l'utiliser.
David