Accès le plus rapide: Pointeur ou tableau?

**homeostasie** · 31/08/2006, 16h02

A chaque commuation de tâche, j'ai créé un hook afin de sauvegarder quelques informations concernant les x dernières taches dans un buffer circulaire.

En terme de rapidité d'éxécution (pour rester le moins de temps possible dans ce hook), vaut il mieux faire cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
void PRF_SaveRegSwitchHook(WIND_TCB *oldTcbPtr, WIND_TCB *newTcbPtr)
{
  	REG_SET regSet;			/*Task registers*/
	TASK_DESC taskDesc;		/*information structure */
	newTaskInfo newtaskInfo;
	tracePostMortem *TaskInfoTemp = NULL;
 
   	/*Critical section: temporay storage pointer to optimize the speed.*/
   	TaskInfoTemp = &TaskInfoBuf[indexBuf];
 
   	TaskInfoTemp->taskId = taskNameToId(oldTcbPtr->name);
   	if (taskRegsGet (TaskInfoBuf[indexBuf].taskId, &regSet) != ERROR){
   		TaskInfoTemp->registers = regSet;
   		TaskInfoTemp->TaskSP = (int)GetSP();
		TaskInfoTemp->TaskFP = (int)GetFP(); 
   	}
 
	TaskInfoTemp->stackBase = (UInt32) oldTcbPtr->pStackBase;
	TaskInfoTemp->stackLimit = (UInt32) oldTcbPtr->pStackLimit;
	TaskInfoTemp->stackEnd = (UInt32) oldTcbPtr->pStackEnd;
}

à ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
void PRF_SaveRegSwitchHook(WIND_TCB *oldTcbPtr, WIND_TCB *newTcbPtr)
{
  	REG_SET regSet;			/*Task registers*/
	TASK_DESC taskDesc;		/*information structure */
	newTaskInfo newtaskInfo;
 
   	TaskInfoBuf[indexBuf].taskId = taskNameToId(oldTcbPtr->name);
   	if (taskRegsGet (TaskInfoBuf[indexBuf].taskId, &regSet) != ERROR){
   		TaskInfoBuf[indexBuf].registers = regSet;
   		TaskInfoBuf[indexBuf].TaskSP = (int)GetSP();
		TaskInfoBuf[indexBuf].TaskFP = (int)GetFP(); 
   	}
 
	TaskInfoBuf[indexBuf].stackBase = (UInt32) oldTcbPtr->pStackBase;
	TaskInfoBuf[indexBuf].stackLimit = (UInt32) oldTcbPtr->pStackLimit;
	TaskInfoBuf[indexBuf].stackEnd = (UInt32) oldTcbPtr->pStackEnd;
}

Si c'est bien le cas, pourrait on m'expliquer le pourquoi?

Remarque: indexBuf est une variable globale au module déclaré comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
static UInt16 indexBuf = 0;

Merci

**rigobert** · 31/08/2006, 16h15

A première vue je pencherais pour la 1ère version :
indexBuf étant global, il doit à priori être réévalué à chaque accès à la structure dans la seconde version, ce qui n'est pas le cas dans la 1ère.

**fearyourself** · 31/08/2006, 16h21

Envoyé par homeostasie

A chaque commuation de tâche, j'ai créé un hook afin de sauvegarder quelques informations concernant les x dernières taches dans un buffer circulaire.

En terme de rapidité d'éxécution (pour rester le moins de temps possible dans ce hook), vaut il mieux faire cela:

Pareil dans 90% des cas, le compilateur sortira le même code.

A première vue je pencherais pour la 1ère version :
indexBuf étant global, il doit à priori être réévalué à chaque accès à la structure dans la seconde version, ce qui n'est pas le cas dans la 1ère.

Faux, un compilateur bien réglé le fera seulement pour le premier accès au tableau et après fera des déplacements relatifs.

De toute facon, la seule réponse valable sera sûrement :

A tester. Lance 10000 fois les deux versions, regarde le temps sur différentes architectures et fait une synthése.

Jc

**homeostasie** · 31/08/2006, 16h25

indexBuf étant global, il doit à priori être réévalué à chaque accès à la structure dans la seconde version, ce qui n'est pas le cas dans la 1ère.

Je me suis dit qu'il y avait peut être un truc de ce genre qui se cachait derrière. En fait, en quoi consiste une réévaluation? Quels sont les étapes?

Rq: J'ai supprimé des lignes dans ma fonction, d'où la déclaration de variables non utilisées. De même,il manque l'incrémention de indexBuf en fin de fonction selon un modulo.

**rigobert** · 31/08/2006, 16h37

Envoyé par fearyourself

Faux, un compilateur bien réglé le fera seulement pour le premier accès au tableau et après fera des déplacements relatifs.

Je ne vois pas trop comment.

IndexBuf étant global (je me répète), sa valeur peut théoriquement changer à tout moment :
donc je ne vois pas trop comment le compilateur pourrait faire l'économie de recharger à chaque accès à la structure sa valeur dans un registre (+ éventuellement un scale).

**homeostasie** · 31/08/2006, 16h46

IndexBuf étant global (je me répète), sa valeur peut théoriquement changer à tout moment :
donc je ne vois pas trop comment le compilateur pourrait faire l'économie de recharger à chaque accès à la structure sa valeur dans un registre (+ éventuellement un scale).

Ceci me parait logique suite à ton explication.
Faire ceci, serait donc une autre solution équivalente à la première (excepté que je déclare une variable locale en plus):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void PRF_SaveRegSwitchHook(WIND_TCB *oldTcbPtr, WIND_TCB *newTcbPtr)
{
  	REG_SET regSet;			/*Task registers*/
	TASK_DESC taskDesc;		/*information structure */
	newTaskInfo newtaskInfo;
        int index = indexBuf;

   	TaskInfoBuf[inde].taskId = taskNameToId(oldTcbPtr->name);
   	if (taskRegsGet (TaskInfoBuf[index].taskId, &regSet) != ERROR){
   		TaskInfoBuf[index].registers = regSet;
   		TaskInfoBuf[index].TaskSP = (int)GetSP();
		TaskInfoBuf[index].TaskFP = (int)GetFP(); 
   	}
	
	TaskInfoBuf[index].stackBase = (UInt32) oldTcbPtr->pStackBase;
	TaskInfoBuf[index].stackLimit = (UInt32) oldTcbPtr->pStackLimit;
	TaskInfoBuf[index].stackEnd = (UInt32) oldTcbPtr->pStackEnd;

        indexBuf = (indexBuf+1) % SavedContextNum;
}

**rigobert** · 31/08/2006, 16h59

Envoyé par homeostasie

Faire ceci, serait donc une autre solution équivalente à la première (excepté que je déclare une variable locale en plus):

En effet.

Dans cette nouvelle version le code est beaucoup plus "optimizer friendly"

!

Et la variable locale supplémentaire ne changera pas grand chose par rapport à la toute 1ère version : ce qui compte c'est qu'il n'y ait plus qu'un seul accès à indexBuf.

**gege2061** · 31/08/2006, 17h09

Envoyé par rigobert

En effet.

Dans cette nouvelle version le code est beaucoup plus "optimizer friendly"

!

Et la variable locale supplémentaire ne changera pas grand chose par rapport à la toute 1ère version : ce qui compte c'est qu'il n'y ait plus qu'un seul accès à indexBuf.

ça oblige tout de même le processeur à effectuer le calcul :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

&TaskInfoBuf[0] + index

Donc à rechercher la valeur de index à chaque fois. Tu peux essayer de lui demander de stocker index dans un registre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

register int index;

Mais il n'ai pas obligé de le faire

Tu as essayé de faire des tests (simple chronométrage de la fonction ou en utilisant un outils plus évolué) ?

**fearyourself** · 31/08/2006, 17h16

Envoyé par rigobert

Je ne vois pas trop comment.

IndexBuf étant global (je me répète), sa valeur peut théoriquement changer à tout moment :
donc je ne vois pas trop comment le compilateur pourrait faire l'économie de recharger à chaque accès à la structure sa valeur dans un registre (+ éventuellement un scale).

Parce que dans l'exemple cité, il n'est pas mention de multi-thread. Un compilateur bien réglé considérera donc qu'on ne modifie pas cette variable globale sauf s'il y a des appels de fonctions ou des accès à des pointeurs...

En supposant que le compilateur n'a pas fait de inline et que donc les appels seront encore là à la génération de code, on aura effectivement quelque chargement de plus mais si la valeur n'a pas changé elle sera vraisemblablement dans le cache donc on ne sentira pas vraiment de ralentissement (à mon avis)

Voici tout de même les fois où la valeur sera normalement rechargée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
void PRF_SaveRegSwitchHook(WIND_TCB *oldTcbPtr, WIND_TCB *newTcbPtr)
{
  	REG_SET regSet;			/*Task registers*/
	TASK_DESC taskDesc;		/*information structure */
	newTaskInfo newtaskInfo;

   	TaskInfoBuf[indexBuf].taskId = taskNameToId(oldTcbPtr->name);
   	if (taskRegsGet (TaskInfoBuf[indexBuf].taskId, &regSet) != ERROR){
   		TaskInfoBuf[indexBuf].registers = regSet;
   		TaskInfoBuf[indexBuf].TaskSP = (int)GetSP();
		TaskInfoBuf[indexBuf].TaskFP = (int)GetFP(); 
   	}
	
	TaskInfoBuf[indexBuf].stackBase = (UInt32) oldTcbPtr->pStackBase;
	TaskInfoBuf[indexBuf].stackLimit = (UInt32) oldTcbPtr->pStackLimit;
	TaskInfoBuf[indexBuf].stackEnd = (UInt32) oldTcbPtr->pStackEnd;
}

A savoir qu'il fusionnera sûrement les deux derniers chargements.

Donc certes c'est plus qu'une fois dans le cas où les fonctions ne sont pas mises en inline mais l'impact sera moindre à mon avis.

L'utilisation de la variable locale est bien sûr conseillé.

Jc

**homeostasie** · 31/08/2006, 17h59

Tu as essayé de faire des tests (simple chronométrage de la fonction ou en utilisant un outils plus évolué) ?

Je vais tâcher de faire cela prochainement et j'en ferais part quand j'aurais le résultat.

ça oblige tout de même le processeur à effectuer le calcul :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

&TaskInfoBuf[0] + index

Cela signifie donc que c'est équivalent à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TaskInfoBuf[index]

pour chaque utilisation de la structure. Si c'est réellement ansi, il vaut donc mieux utiliser un pointeur pointant sur l'adresse de TaskInfoBuf[indexBuf] comme fait dans la première solution...

Donc à rechercher la valeur de index à chaque fois. Tu peux essayer de lui demander de stocker index dans un registre :

mais si index est déjà en cash, pas besoin de stocker dans un registre, non?

Un compilateur bien réglé considérera donc qu'on ne modifie pas cette variable globale sauf s'il y a des appels de fonctions ou des accès à des pointeurs...

C'est donc à moi d'apprendre à bien régler le compilateur...Je suppose qu'il y a des cours généraux sur cela, car je me dis que chaque compilateur à ses particularités.

**gege2061** · 31/08/2006, 18h11

Envoyé par homeostasie

ça oblige tout de même le processeur à effectuer le calcul :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

&TaskInfoBuf[0] + index

Cela signifie donc que c'est équivalent à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TaskInfoBuf[index]

pour chaque utilisation de la structure. Si c'est réellement ansi, il vaut donc mieux utiliser un pointeur pointant sur l'adresse de TaskInfoBuf[indexBuf] comme fait dans la première solution...

Que signifie *(tab+3) ?. Donc oui, je préfère la première solution.

Envoyé par homeostasie

Donc à rechercher la valeur de index à chaque fois. Tu peux essayer de lui demander de stocker index dans un registre :

mais si index est déjà en cash, pas besoin de stocker dans un registre, non?

Tout dépend où se trouve le cache (si c'est en mémoire c'est plus lent que les registres).

Envoyé par homeostasie

Un compilateur bien réglé considérera donc qu'on ne modifie pas cette variable globale sauf s'il y a des appels de fonctions ou des accès à des pointeurs...

C'est donc à moi d'apprendre à bien régler le compilateur...Je suppose qu'il y a des cours généraux sur cela, car je me dis que chaque compilateur à ses particularités.

Il faut lire la doc de ton compilateurs, tu utilise quel compilateur ?

**Emmanuel Delahaye** · 31/08/2006, 18h17

Envoyé par homeostasie

mais si index est déjà en cash, pas besoin de stocker dans un registre, non?

cash ?

Eh, les gars, rélisez vous, j'ai mis quelques secondes à comprendre 'cache'...

**homeostasie** · 31/08/2006, 18h24

Que signifie *(tab+3) ?. Donc oui, je préfère la première solution.

Oui tout à fait, je n'ai pas pensé à raisonner avec la réciproque, hum hum...

Tout dépend où se trouve le cache (si c'est en mémoire c'est plus lent que les registres).

Pour moi, le cache se situe toujours au plus proche du processeur, notamment le cache primaire (L1) dédié aux datas et aux instructions. Sinon ce n'est plus du cache mais de la mémoire ram ou rom...
Par contre, ce que tu veux dire, si il n'y a pas de cache existante, alors l'utilisation des registres internes au µP ou µC seraient le plus rapide.
Au fond, je me demande si l'utilisation de registres n'est tout de même pas plus rapide que du cache...

Il faut lire la doc de ton compilateurs, tu utilise quel compilateur ?

En fait, je ne sais pas, je ne m'étais jamais soucié de cela auparavant mais j'ai la nette impression que ca va m'être essentiel.

**homeostasie** · 31/08/2006, 18h26

cash ?

Eh, les gars, rélisez vous, j'ai mis quelques secondes à comprendre 'cache'...

Oui désolé, je me suis un peu emballé pour écrire cache...

**rigobert** · 31/08/2006, 19h29

Envoyé par gege2061

ça oblige tout de même le processeur à effectuer le calcul :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

&TaskInfoBuf[0] + index

Donc à rechercher la valeur de index à chaque fois.

Non.

Sur tous les compilateurs dignes de ce nom, index sera évalué une fois et une seule et mis dans un registre qui servira à faire toutes les indexations suivantes.

Envoyé par gege2061

Tu peux essayer de lui demander de stocker index dans un registre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

register int index;

Re-non : la directive "register" est d'une utilité plus qu'aléatoire. Pas mal de compilateurs modernes l'ignorent purement et simplement. Intel déconseille même son utilisation dans son guide de l'optimisation IA32.

**rigobert** · 31/08/2006, 19h35

Envoyé par fearyourself

Parce que dans l'exemple cité, il n'est pas mention de multi-thread. Un compilateur bien réglé considérera donc qu'on ne modifie pas cette variable globale sauf s'il y a des appels de fonctions ou des accès à des pointeurs...

Il n'est pas fait mention non plus de mono-threading.

A défaut de savoir, mieux vaut toujours envisager la pire hypothèse.

En plus, si c'est d'un hook système dont il s'agit, l'hypothèse d'un environnement multi-threadé est assez plausible ... sauf si on est sous TOS

!

**rigobert** · 31/08/2006, 19h47

Envoyé par homeostasie

mais si index est déjà en cash, pas besoin de stocker dans un registre, non?

C'est quand même mieux dans un registre. La présence d'une variable en cache L1 n'est jamais garantie à 100%.

Envoyé par homeostasie

Un compilateur bien réglé considérera donc qu'on ne modifie pas cette variable globale sauf s'il y a des appels de fonctions ou des accès à des pointeurs...

C'est donc à moi d'apprendre à bien régler le compilateur...Je suppose qu'il y a des cours généraux sur cela, car je me dis que chaque compilateur à ses particularités.

Pourquoi faire simple quand on peut faire compliqué ??

Il existe une solution portable pour obtenir un code optimal (en privilégiant les variables locales), alors pourquoi diable se faire ch..r avec des réglages spécifiques de compilateur

??

**homeostasie** · 31/08/2006, 20h05

Il n'est pas fait mention non plus de mono-threading.

A défaut de savoir, mieux vaut toujours envisager la pire hypothèse.

En plus, si c'est d'un hook système dont il s'agit, l'hypothèse d'un environnement multi-threadé est assez plausible ... sauf si on est sous TOS !

Alors en fait je suis sous l'OS temps réel VxWorks, je n'utilise pas de processus légers (threads) et l'application est constitué essentiellement de processus préemptés selon la priorité.

Ce hook est déclenché à chaque commutation de taches.

C'est quand même mieux dans un registre. La présence d'une variable en cache L1 n'est jamais garantie à 100%.

D'ailleurs je me demandais s'il était possible de gérer cela, de savoir ce qu'il y a dans le cache, voir de le manipuler...
Je sais que l'utilité première du cache est d'accroitre les performances de traitement en anticipant les instructions et les données, lorsque celles ci sont susceptibles d'être utilisées plusieurs fois. C'est donc le système qui gère cela!

Je ne me suis jamais servi de registre particulier pour optimiser la vitesse d'accès à une variable, est ce facile à mettre en oeuvre?
Je me doute que c'est là qu'intervient l'asm en embarqué.
Si je décidais de placer une variable dans un registre dédié à cela en utilisant une commande asm, j'ai du mal à saisir comment l'instruction saura qu'il faut aller chercher cette variable dans tel registre? Puis aussi à être sur que ma donnée ne sera pas écrasée par une autre?

**rigobert** · 01/09/2006, 11h32

Envoyé par homeostasie

D'ailleurs je me demandais s'il était possible de gérer cela, de savoir ce qu'il y a dans le cache, voir de le manipuler...

Non. Même en assembleur on ne peut pas vraiment savoir ce qui est en cache, à quel niveau... Il existe quelques intructions pour donner des indications au processeur sur la façon dont on souhaiterait que les données soient mises (ou pas mises) en cache, mais ça ne va pas plus loin. De plus les stratégies de mise en cache (ou pas) des données varient d'un processeur à l'autre, voire même parfois entre 2 générations d'une même famille.

Envoyé par homeostasie

Je sais que l'utilité première du cache est d'accroitre les performances de traitement en anticipant les instructions et les données, lorsque celles ci sont susceptibles d'être utilisées plusieurs fois. C'est donc le système qui gère cela!

Le CPU pour être exact.
Le fonctionnement sera le même par exemple sous Windows et sous Linux i86.

Envoyé par homeostasie

Si je décidais de placer une variable dans un registre dédié à cela en utilisant une commande asm, j'ai du mal à saisir comment l'instruction saura qu'il faut aller chercher cette variable dans tel registre? Puis aussi à être sur que ma donnée ne sera pas écrasée par une autre?

Je te le déconseille : de nos jours il faut vraiment être expert en assembleur pour espérer battre les compilateurs C/C++ modernes en termes d'optimisation. Il n'y a que dans des cas très spécifiques que le jeu en vaut la chandelle.

**homeostasie** · 01/09/2006, 12h00

Non. Même en assembleur on ne peut pas vraiment savoir ce qui est en cache, à quel niveau... Il existe quelques intructions pour donner des indications au processeur sur la façon dont on souhaiterait que les données soient mises (ou pas mises) en cache, mais ça ne va pas plus loin. De plus les stratégies de mise en cache (ou pas) des données varient d'un processeur à l'autre, voire même parfois entre 2 générations d'une même famille.

OK

Le CPU pour être exact.

OK

Je te le déconseille : de nos jours il faut vraiment être expert en assembleur pour espérer battre les compilateurs C/C++ modernes en termes d'optimisation.

et OK...

Merci

Il n'y a que dans des cas très spécifiques que le jeu en vaut la chandelle.

Pourrais je avoir un de ces cas à titre d'exemple que je me fasse une idée?