Rapport de stage Allocateur mémoire multicritère minimisant la

Rapport de stage
Allocateur mémoire multicritère minimisant la
consommation d’énergie
Damien Martin-Guillerez - MIT 1
Encadrant : Gilbert Cabillic
Projet ACES
Juin-Juillet 2003
1
Table des matières
Sujet du stage
3
1 Analyse du problème
3
2 Données pertinentes
2.1 Caractéristiques mémoires . . . . . . . . . .
2.2 Critères d’utilisation d’un bloc d’allocation
2.3 Données globales . . . . . . . . . . . . . . .
2.4 Évaluation des données . . . . . . . . . . .
.
.
.
.
4
4
4
4
5
.
.
.
.
.
5
5
5
5
5
6
.
.
.
.
.
.
.
.
.
6
6
6
7
7
7
9
10
10
10
.
.
.
.
.
.
10
10
10
11
11
11
12
6 Améliorations possibles
6.1 Idées pour rendre l’algorithme efficace . . . . . . . . . . . . . . . . . . . . .
6.2 Extension : cas de plusieurs mémoire RAM . . . . . . . . . . . . . . . . . .
6.3 Extension : cas continu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
12
13
13
Références
14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Calculs
3.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Coût d’allumage des bancs . . . . . . . . . . . . . .
3.2.2 Coût d’une configuration pendant un temps donné
3.2.3 Coût de déplacement . . . . . . . . . . . . . . . . . .
4 Solutions
4.1 Recherche de minimum . . . . . . . . .
4.2 Méthode du sac à dos . . . . . . . . . . .
4.2.1 Algorithme d’allocation . . . . .
4.2.2 Algorithme de libération . . . . .
4.2.3 Algorithme d’extinction de banc
4.2.4 Algorithme de réallocation . . .
4.3 Méthode partielle . . . . . . . . . . . . .
4.3.1 Principe . . . . . . . . . . . . . .
4.3.2 Détails . . . . . . . . . . . . . . .
5 Tests et résultats
5.1 Consommations . . .
5.1.1 Des mémoires
5.1.2 De l’appareil .
5.2 Tests . . . . . . . . . .
5.3 Résultats . . . . . . .
5.4 Analyse des résultats
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sujet du stage
Un ordinateur de poche a accès à différentes mémoires. Chacune de ces mémoires
possède des caractéristiques très différentes : volume, temps d’accès aux données,
consommation énergétique nécessaire au maintien en mémoire des données, nombre
d’écritures restreintes dans un temps donné, persistance, désactivation partielle de l’alimentation électrique par zone non utilisée...
L’objectif du stage est de concevoir un allocateur mémoire qui tienne compte des caractéristiques des mémoires et de l’utilisation des données afin de réduire la consommation énergétique. Ainsi, en réalisant le placement des données sur les mémoires les plus
adaptées (d’un point de vue énergétique, mais sans trop de dégradation pour l’utilisateur), il pourra permettre de diminuer la consommation énergétique globale de l’ordinateur de poche1 .
1
Analyse du problème
On cherche donc à concevoir un allocateur qui, en fonction de différents paramètres,
allouera dans des mémoires différentes. On peut donc décomposer l’allocateur de la façon
suivante :
– Un sélecteur de mémoire qui, en fonction des caractéristiques de chaque mémoire et
de chaque bloc d’allocation, va déterminer quel bloc sera mis dans quelle mémoire.
– Un allocateur par mémoire se chargeant de l’allocation réelle sur chaque mémoire
et, si nécessaire, de défragmenter la mémoire.
Programme
Caractéristiques
mémoires
Mémoires
Allocation
réelle
Allocateur
Critères
Demande
d’utilisation d’allocation Sélecteur de
mémoire
Allocateurs
Retour de l’emplacement mémoire
S CHÉMA DE L’ ALLOCATEUR
Pour les allocateurs, on peut reprendre aisément des algorithmes déjà connus. La difficulté principale vient donc de la sélection de la mémoire ; il faut trouver des solutions aux
problèmes suivants :
– Quelles sont les caractéristiques pertinentes pour les mémoires ? Quels sont les critères d’utilisation pertinents pour un bloc ?
– Comment calculer le coût en énergie d’une configuration donnée ? (Autrement dit :
quelle est la valeur à optimiser ?)
– Comment choisir les allocations pour optimiser ce coût ?
1
On dira que l’on fait diminuer la consommation d’énergie si l’on a effectué le même travail (et pas utilisé
le même temps) en consommant moins d’énergie (selon [3])
3
2
2.1
Données pertinentes
Caractéristiques mémoires
Les premières caractéristiques importantes d’une mémoire vont être le volume et les
temps d’accès. A celles-ci s’ajoutent les consommations des accès et celles de maintien de
l’information. De plus, on peut avoir certaines limitations sur les mémoires (par exemple,
comme cité dans le sujet, un nombre d’écritures restreint). Les premières caractéristiques
seront donc :
– (en octets) la taille de la mémoire.
– (en ) le temps moyen d’un accès.
– (en ) la consommation en énergie des accès.
– (en ) la consommation en énergie du maintien de l’information en fonction
de la taille de la donnée.
– une fonction booléenne déterminant si tel ou tel bloc peut-être mis dans cette
mémoire (fonction d’éligibilité).
En réalité, la consommation dépend de l’allumage ou non de la mémoire, ou plus
précisément, du banc de mémoire concerné. On notera alors le nombre de bancs de la
les tailles des bancs et %& ' les coût (en ) d’allumage des
mémoire, "!$#
"!$#
bancs.
On notera à présent (*)+,-/.-01.23. .%0 '
.2 les caractéristiques
"! #
"! #
d’une mémoire et (5467 désignera son nombre de bancs, (546 son temps moyen d’accès,
etc...
(N.B. : la taille sera donnée à présent par 8
(54 .)
2.2
"9;: ! #
Critères d’utilisation d’un bloc d’allocation
Il faut maintenant choisir les critères d’utilisation d’un bloc que le programme passera
au sélecteur. Il va tout d’abord y avoir la taille du bloc et les nombres d’accès. De plus, on
doit connaître également le temps durant lequel le bloc va être alloué. Enfin, tout comme
une mémoire, on veut obtenir des critères empêchant la sélection d’une mémoire (par
exemple pour respecter des délais d’exécution dans un système temps réel). Les critères
d’utilisation seront donc :
– la taille du bloc (en octets).
– le nombre d’accès au bloc.
– < le temps d’exécution durant lequel le bloc sera alloué.
– = la fonction booléenne d’éligibilité d’une mémoire.
De même, on notera à présent >?)+ [email protected]<&.=A les caractéristiques d’un bloc (on désignera
encore >B4 pour sa taille, etc...).
2.3
Données globales
A ces données, il faut ajouter une donnée plus globale : DC la consommation totale de
l’appareil (en ). En effet, pendant que des entrées/sorties seront effectuées, l’appareil
sera allumé et donc sa consommation entrera en compte.
On notera en plus, la fonction E d’éligibilité donnée par EF>B.(GH)I>/4 =J,(GLKM(54N@F>O .
On dira qu’une mémoire ( est éligible pour un bloc > si EPF>B.(G est vrai.
4
2.4
Évaluation des données
Comment déterminer toutes ces données ?
– Les fonctions d’éligibilité seront décidées en fonction de ce que l’on veut permettre
ou non.
– Pour les caractéristiques mémoire, il suffit de regarder les références des constructeurs. Il est ainsi possible de toutes les estimer par leurs valeurs moyennes.
– La taille d’un bloc est toujours décidé à l’allocation.
– La durée d’un bloc peut être estimée par le programmeur soit par test soit par calcul. Il en va de même pour le nombre d’accès.
Dans certains cas, il sera plus utile de déterminer des valeurs maximales que
moyennes (pour des applications critiques, pour minimiser la consommation au plus).
3
3.1
Calculs
Notations
Une configuration est l’ensemble des blocs alloués et des mémoires avec une association entre chaque bloc et la mémoire où il a été alloué. On notera donc une configuration
0DQR)S%TU.-VW où T*)SF> est l’ensemble des blocs alloués et V une fonction telle que
VXF>O donne la mémoire où est alloué le bloc > .
On notera (54NYB% C @)+,(54Z \[ C 7(546 (où ( est une mémoire).
3.2
Coûts
Note : les coûts sont tous en Joule.
3.2.1 Coût d’allumage des bancs
Un banc sera allumé tant qu’au moins un bloc sera allumé sur ce banc. On supposera
par la suite que les bancs ne peuvent s’éteindre si le banc suivant est encore allumé (cas
des mémoires du commerce).
On obtient ainsi qu’un banc ] d’une mémoire ( est allumé si
ji
85^Q_a`Dbdcfe
>gh4
8
(54 . Son temps d’allumage sera donné par :
9
k
lkDm
on
!$p
,(5.-0$QJ.])q(M]'Lr&s
_u^2_v`b3cwe
t
cwxy_a`Db vC z{"C c
9
:
~}
>|gh4
t
lkDm
(54
kh
Enfin cela nous donne le coût d’un banc sur un temps t :
€
on
!p
,(5.-0DQJ.-@)
(54Z0 J&(M]‚,3.on
t
"9H: ! #
,(5.-0$QJ.]
!$p
3.2.2 Coût d’une configuration pendant un temps donné
Le coût d’une configuration pendant un temps où aucun changement n’aurait lieu
sera alors :
€
p'ƒF!h„
%0$QJ.@)
t
> 46M
> 46<
VXF> d4NYB%3C [
€
t
9
5
on
!$p
,(5.-3$QJ.-
Le coût d’une configuration jusqu’à la fin sera alors
Enfin les temps d’accès seront donnés par :
Toujours avec %3$Q2@)q
pƒ!„
p'ƒF!h„
%0$QJ.)†t
%0$QJ. [O…
€
%0$Q2@)
€
pƒ!„
%0$QJ. [O…
.
> 46M&VXF> d46 .
€
On cherchera donc par la suite à minimiser tout d’abord %3$Q2 puis 0%0$Q2 en
changeant la fonction V (autrement dit en changeant les mémoires d’allocation).
3.2.3 Coût de déplacement
Le déplacement d’un bloc d’une mémoire à une autre peut être utile si le coût de
€1‡
relocation donné par <ˆ F>B.( .(Š‰$.- C O)‹,( 4NYB% C [ (Š‰$4NY/% C BA>B4 est inférieur au
ƒp
gain en énergie obtenu par le déplacement. On notera le coût de déplacement comme
suit :
€/Œ
<,&ˆ F>B.(
.(Š‰$.- C @)
€B‡
<ˆ
ƒp
F>B.(
.(Š‰$.- C [
,(Š‰4NY/% C Ž5(
Si ce coût est négatif, il peut être intéressant de déplacer le bloc
excepte les allumages et extinctions de banc).
4
>
4NY/% C h>B46
de (
vers (\‰ (si l’on
Solutions
avec (Š une mémoire
On supposera à présent avoir mémoires ,(\.( .4a4a4a.(
9
!‘/
possédant un certain nombre de bancs et le Y le plus petit de toutes les mémoires (il
s’agit de la RAM). On suppose également que les autres mémoires n’ont pas de coût de
maintien de l’information (mémoire Flash). (On verra après comment faire lorsqu’il y a
plus d’un type de RAM).
4.1
Recherche de minimum
La première idée venant à l’esprit est de rechercher, pour chaque bloc, la mémoire réalisant le minimum de consommation avec un calcul simple. Cette méthode est possible si
l’on considère que chaque mémoire a une consommation de conservation de l’information proportionnelle à la taille de l’information (pas de banc de mémoire). On cherchera
€
alors une mémoire ( telle que F>B.(G@)j>/46M(54NYB%&C [ >B46 < (54Z soit minimal (en cas
d’égalité on choisit la mémoire de le plus faible).
€
€
La fonction V est alors donnée par V’F>W“)”( tel que •–(˜—f. F>B.(G\™
F>B.(M—vBš
› €
€
}
F>B.(G‚)
F>/.(M—a2Kœ,(546 (M—f46  . On utilisera alors un algorithme de recherche de minimum.
4.2
Méthode du sac à dos
Dans le cas réel, il nous faut remplir les mémoires en tenant compte du moment où
un ajout provoque un allumage de banc et remplir les bancs en conséquence. C’est le but
de l’algorithme présenté ici.
6
4.2.1 Algorithme d’allocation
On réalise les différentes étapes suivantes :
– Suppression des mémoires non éligibles. Détermination de (indépendamment du
fait qu’il reste ou non de la place dans la mémoire).
– Recherche de places restantes en mémoire. Erreur si plus de place disponible.
– Recherche du minimum de consommation.
* Si ce minimum n’allume aucun banc de mémoire (pas d’introduction de coût de
maintien), alors on sélectionne la mémoire réalisant ce minimum.
* Sinon, c’est que ce minimum est en RAM. On réalise alors l’algorithme d’extinction de banc décrit ci-dessous pour le banc allumé par la nouvelle allocation et
on alloue.
4.2.2 Algorithme de libération
– On libère la mémoire
– On regarde si elle est en RAM, si c’est le cas, on réalise l’algorithme d’extinction de
banc sur le banc en cours
4.2.3 Algorithme d’extinction de banc
Principe
Le but de cet algorithme est de choisir entre : on allume un banc de plus qu’on essaye
de remplir au maximum ou on essaye de remplir le banc précédent au maximum. Tout
d’abord, on regarde la place prise par les blocs non déplaçables (i.e. les blocs dont la seule
mémoire éligible est la RAM). Ensuite on appellera
la taille des ž premiers bancs de la
RAM ; elle est retranchée de la taille des blocs non déplaçable (le banc ž étant le banc dont
on se demande si on a intérêt à l’allumer). Enfin, on utilise une variante de l’algorithme
de résolution du problème du sac à dos pour remplir . On va donc chercher à minimiser
€/Œ
€
8Ÿ`Q on
%¡WV£¢?.-0$QJ. [O… .
<,&ˆ F>O [
!$p
pƒ!„
Pour cela on classe les blocs mémoires par leur densité d’accès à la seconde. On
cherche à maximiser le nombre d’entrées/sorties sur la RAM pour le diminuer sur les
autres mémoires. On peut appliquer des coefficients aux en rapport avec leur première mémoire éligible. Par ailleurs, on le diminue du coût de déplacement si la mémoire
n’est pas déjà en RAM. On arrivera donc à un poids pour l’algorithme du sac à dos de
`
_ c
c
¤
® ^|¯°cw±
z%ª «¬ _
z%ª «¬ _ ® ^J¯ : !¥ ¦ p§ –¨A©
9H­ ` Cvz
¨A©
9/² où Y est celui de la mémoire de remplacement
)
:
de la RAM pour le bloc en cours, (
la mémoire où le bloc se situe actuellement et ( ‰
la mémoire de relocation du bloc (( ‰ )³¡WV´¢ si (
)³¡WV£¢ ). On cherche à maximiser
“µ
¤
sur chaque banc mémoire. Il faut également regarder si les déplacements de mémoire
pour atteindre la configuration donnée sont intéressants : on supprime donc au préalable
€;Œ
les blocs en mémoire autre que la RAM tels que <fˆ2¶¸· .
Il ne faut pas oublier de mettre à jour les < et les à chaque calcul (pour on peut
estimer que les accès sont équitablement répartis dans le temps).
Algorithme détaillé
7
¤
Note : on sait que maximiser la somme des dans la RAM c’est minimiser celle des
¤
dans les autres mémoires.
Dans cet algorithme on note m[0.. ] l’ensemble des mémoires et U.i et U.j désigne9
ront les indices respectifs des mémoires (
et (Š‰ citées précédemment, m[0] désignant la
RAM.
SAC-A-DOS_REC(P, minP, T, R)
Res = R
Si T >= 0 Alors
Prendre U dans R tel que U.P/T soit minimal
R <- R \ U
/* on met U dans la RAM */
(R1, m1) = SAC-A-DOS(P, minP, T, R)
Si m1 < minP Alors
minP <- m1
Res <- R1
Fsi
/* on ne met pas U dans la RAM */
Si P + U.P < minP Alors
Si T < U.T Alors
/* on a éteint le banc */
minP <- P + U.P
Res <- { U }
Sinon
/* il faut continuer à l’éteindre */
(R1, m1) = SAC-A-DOS(P + U.P, minP, T - U.T, R)
Si m1 < minP Alors /* si on a rien trouvé, m1 = minP */
minP <- m1
Res <- R1 + { U }
Fsi
Fsi
Fsi
Fsi
Retourner (Res, minP)
SAC-A-DOS(T, R)
(R’, mP) = SAC-A-DOS_REC(0, +infini, T, R)
retourner R’
ETEINDRE_BANC(T1)
T0
<- 0
Ttot <- 0
R
<- { }
Pour tout U bloc mémoire
Faire
Si U n’a qu’une mémoire éligible
8
Alors
U.i’ = U.i
Si U.i = 0
Alors
T0 <- T0 + U.T
Fsi
Sinon
U.i’ <- 0
Si U.i = 0 ou Cdepl(U) < 0 ou (U non alloué et RAM eligible)
Alors
R
<- { U } + R
U.j <- première mémoire éligible autre que la RAM
U.P <- (U.n * (m[U.j].cI/O + Ct) * m[U.j].tI/O
- Cr(U.i, 0) + Cr(0, U.j)) / U.te
Ttot <- Ttot + U.T
Sinon
U.i’ <- U.i
Fsi
Fsi
Fait
Classer R par P/T croissant
/* on sait ici que T1-T0 > Ttot */
R’ <- SAC-A-DOS(Ttot - (T1-T0), R)
Renvoyer la configuration de coût minimal entre :
- On met les blocs de R \ R’ en RAM,
les blocs de R’ dans une autre mémoire
- On met tout les blocs de R en RAM
- On ne change pas la configuration
(si nouveau bloc il y a, on le met en RAM)
4.2.4 Algorithme de réallocation
Une réallocation sera une modification d’une des valeurs de > . La modification du
3C ne sera prise en compte qu’aux réapplications de l’algorithme d’extinction de banc vu
qu’il s’agit d’un paramètre qui sera estimé par l’allocateur.
– Si >B4 change. Soit on a la place de réallouer dans la mémoire en cours et on le fait,
sinon on libère et on alloue.
¤
– Sinon on recalcule >/4
`
– Si la mémoire est en RAM et que º : ¹ a (significativement) diminué en deçà du
`
plus grand º : ¹ des autres mémoires, on réapplique l’algorithme d’extinction de
banc.
`
– Si la mémoire n’est pas en RAM et que º : ¹ a (significativement) augmenté au
9
delà du plus petit
banc.
4.3
`
º:¹
de la RAM, on réapplique l’algorithme d’extinction de
Méthode partielle
4.3.1 Principe
Le problème d’un tel algorithme est sa lenteur ( »¼o½¿¾£ appels récursifs si À est le
nombre de blocs). On lui préférera donc un algorithme donnant une valeur approchée de
la solution optimale : il s’agira de la version gloutonne de cet algorithme (version utilisée
lorsque l’on peut "découper" les objets à mettre dans le sac à dos). On se contentera donc
de remplir les bancs par les blocs de forte densité sans essayer de trouver la solution
optimale.
4.3.2 Détails
On remplacera donc la fonction SAC-A-DOS par la fonction suivante :
SAC-A-DOS(T, R)
R’ <- { }
Tant que T > 0
Faire
Prendre U dans R tel que U.P/T soit minimal
R <- R \ { U }
T <- T + U.T
R’ <- R’ + { U }
Fait
Retourner R’
5
Tests et résultats
5.1
Consommations
5.1.1 Des mémoires
Pour réaliser les tests, il a fallu tout d’abord récupérer les caractéristiques des
mémoires sur les sites constructeurs. Sur le site de Micron Technology [4], on trouve les
spécifications physiques de chaque mémoire de leur construction :
€
(Mo)
(W)
Mémoire Taille (Mo) (W) (ns) (W)
SDRAM
SRAM
Flash
128
8
64
0,238
1
0,0285
0,021
6.426
20,08
0,101
0,101
0
32-32-64
-
0,028-0,028-0,056
-
Cependant ces valeurs ont été obtenues à partir d’estimations (notamment sur le cas
des ) sur la longueur d’un burst2 moyen, et ignorent certaines consommations. J’ai
donc préféré utiliser les valeurs suivantes trouvées dans différents endroits 3,4 :
2
suite d’octets d’adresses contigües envoyés à la mémoire en même temps
Flash : Manuel utilisateur d’une clef USB
4
SDRAM : tiré de [3] - section 7.1
3
10
Mémoire
Taille (Mo)
SDRAM
Flash
256
128
(W)
0,545
0,2
(ns)
0,021
1,33
€
(Mo)
64-64-128
-
(W)
0,0478-0,0478-0,0956
-
Finalement je prendrais ces valeurs divisées par 10 (pour la consommation de maintien) pour des mémoires de 2 Mo.
5.1.2 De l’appareil
La consommation totale de l’appareil a été évaluée en fonction de la consommation
d’un iPAQ à 1 W. Les chiffres constructeurs donnaient une batterie de 1400 mA/h pour
5 V. La batterie était sensée tenir 14 heures mais après discussion avec une personne
habituée à son usage, on a estimé que la durée de vie moyenne de la batterie était de 7
heures.
Soit 5.2
C )SÁ0Â
·h·
(ŠVÃ4NÄ|DÅ£Æ
Ç
Ä
)
Á
Tests
Après implémentation d’une simulation de ces algorithmes, j’ai réalisé des tests sur
différentes traces d’allocation mémoire. Les premières Test1 et Test2 sont des traces imaginaires dans un cas où il y avait clairement intérêt à déplacer un bloc en RAM et dans
le second cas où tous les blocs étaient non déplaçables. Ensuite des tests sur des traces
d’allocations réelles : 8queens (Placement des 8 reines sur un damier), carres (Génération aléatoire de formes), mine (Jeu du démineur) et mp3 (Lecteur MP3). Pour ce faire,
on a mesuré dans une JVM5 les allocations et libérations réalisées par ces programmes ;
les mesures donnaient les tailles des allocations et des réallocations demandées, les blocs
concernés ainsi que les instants des actions et j’ai ensuite pris les temps d’entrées/sorties
comme étant d’environ 10% du temps d’exécution total pour les objets et d’une lectureécriture pour les petit tampons (de tailles inférieures à 200 octets).
5.3
Résultats
Tout d’abord, il n’a pas été possible de réaliser les tests sur les traces réelles pour la
méthode complète du sac à dos, celle-ci mettant plus de 14 heures pour effectuer à peine
2% d’une simulation qui était faite en moins de 20 minutes par les autres algorithmes.
Cet algorithme donnait les mêmes résultats que l’algorithme partiel sur les échantillons
Test1 et Test2. Tous les tests sur Test2 ont donné les mêmes résultats.
Voici les résultats des autres algorithmes 6 :
Trace
Test1
8queens
carres
mine
mp3
5
6
Coût (J)
Temps des I/O (s)
Temps algo (s)
4,45
0,531
0,316
0,229
0,510
0,063
0,247
0,137
0,120
0,285
2,80.10-5
5,22
9,48
0,342
0,404
Java Virtual Machine
Les rapports, gains et pertes sont par rapport à l’algorithme classique
11
A LGORITHME CLASSIQUE ("T OUT EN RAM")
Trace
Test1
8queens
carres
mine
mp3
Trace
Test1
8queens
carres
mine
mp3
5.4
Coût (J)
2,37
0,596
0,357
0,238
0,475
Coût (J)
3,79
0,531
0,316
0,229
0,510
Gain
Temps des I/O (s)
Perte
Temps algo (s)
47%
1,62
2503%
6,10.10-5
-12%
0,301
21,8%
1780
-13%
0,172
25,5%
1240
-3.8%
0,127
5,8%
1030
6.9%
0,314
10,1%
1490
A LGORITHME DU SAC À DOS ( PARTIEL )
Gain Temps des I/O (s)
Perte
Temps algo (s)
15%
0,154
144%
2,10.10-5
0%
0,247
0%
5,59
0%
0,137
0%
9,75
0%
0,120
0%
0,365
0%
0,285
0%
0,433
A LGORITHME DE RECHERCHE DU MINIMUM
Rapport
2,2
3400
1300
3000
3700
Rapport
0,75
1,1
1,0
1,1
1,1
Analyse des résultats
On constate aisément que même si sur un exemple fictif (Test1) on peut gagner beaucoup, voir même gagner légèrement sur des exemples réels (mp3). On a tendance à perdre
plus qu’à gagner pour l’algorithme du sac à dos pour un temps de calcul beaucoup trop
long (plus de 100 fois le temps d’exécution). L’algorithme de recherche du minimal donne
sur la plupart des exemples les mêmes résultats que l’algorithme classique pour un temps
de calcul équivalent.
Ces algorithmes sont donc inefficaces dans leurs formes actuelles. Tout d’abord l’algorithme du sac à dos est trop lent en raison du grand nombre de blocs de mémoire qu’il
faut gérer7 . Ensuite, il s’avère inefficace sur les traces réelles car les densités d’accès sont
trop proches les unes des autres (c’est d’ailleurs la raison pour laquelle l’algorithme de
recherche du minimal donne les mêmes résultats que la RAM) ; Il serait peut-être possible
de gagner sur d’autres traces plus précises (i.e. avec de véritables mesures des nombres
accès). Enfin le fait que l’algorithme ne prenne pas en compte les allocations à venir l’empêche d’allumer un banc de façon anticipée et donc l’algorithme passe du temps, et de
l’énergie à déplacer des blocs d’une mémoire vers l’autre.
Enfin, le ralentissement des applications lorsque l’on gagne de l’énergie (temps des
E/S) semble être impressionnant (jusqu’à 2503% par rapport à la RAM) mais il faut savoir
que ces traces d’allocations tiennent sur des temps bien plus longs 8 : il y a donc réellement
de l’énergie à gagner sans trop de perte de temps.
6
Améliorations possibles
6.1
Idées pour rendre l’algorithme efficace
Plusieurs idées sont réalisables pour rendre l’algorithme efficace :
È
Tout d’abord il faut rendre l’algorithme du sac à dos plus statique. Pour cela on peut
déjà appliquer des coefficients aux coût de déplacement dans le calcul du poids.
7
8
dans les 8000 à 12000 blocs
Test1 : 52 s ; 8queens : 31,5 s ; carres : 21,6 s ; mine : 12,2 s ; mp3 : 3,74 s
12
È
È
È
6.2
Ensuite, il faudrait essayer d’appliquer l’algorithme moins souvent pour gagner
du temps : cela peut être fait en le combinant avec l’algorithme de recherche du
minimum : on recherche le minimum, s’il n’est pas assez éloigné du coût de la
mémoire qui suit, alors on applique l’algorithme du sac à dos.
Par ailleur, il faut penser à réunir les blocs en de plus gros blocs de caractéristiques
voisines : cela permettra de diminuer le nombre de blocs sur lesquels il y aura effectivement des calculs. Ce genre de situation se retrouve classiquement dans certains
allocateurs de mémoire [1].
Une dernière chose réalisable est de tenter d’allouer selon des statistiques : en fonction des données des mémoires allouées, de la mémoire à allouer, et des statistiques
globales d’allocations on peut prevoir le pourcentage de chances que l’on a de gagner en allouant dans telle ou telle mémoire ; une fois ce calcul réalisé, soit l’on
choisit celle qui a le plus de chance de gagner de l’énergie, soit on tire au hasard
avec les pondérations correspondantes 9. On peut également tenté de prévoir de
futures allocations en "étendant" les blocs déjà alloué.
Extension : cas de plusieurs mémoire RAM
Dans le cas de plusieurs mémoire RAM, l’idée d’allocation est de regarder, par recherche de minimum, dans quelle mémoire RAM le bloc consommerait le moins d’énergie. On réalise ainsi l’algorithme d’extinction de banc sur toutes les mémoires RAM et
pour les cas où un banc ne serait pas rempli entièrement, on essaye de le remplir avec les
blocs non alloué dans les autres RAM. Cet algorithme serait, en substance :
pour tout les blocs
Choisir la meilleure RAM et la meilleure mémoire secondaire
par recherche du minimum
pour toutes les mémoires RAM
Réaliser l’extinction de banc, choisir le coût le plus faible
Tant qu’il reste des blocs déplaçables en mémoires secondaires
pour lesquels on n’a pas testé toutes les RAM
pour tous les blocs restants
Choisir la meilleure RAM parmi celles non testées
pour toutes les mémoires RAM
Remplir le banc en cours par l’algorithme du sac à dos
Fin tant que
6.3
Extension : cas continu
Une autre extension possible est de considérer que l’on ne connaît pas le temps d’allocation (cas par exemple d’une application de traitement de texte). On connaîtra en revanche le nombre d’accès moyen à la seconde. Alors la plupart des calculs resteront les
mêmes excepté que l’on devra agir par tranche de temps en estimant le temps restant. On
estime que l’on ne connaît pas le temps d’allocation uniquement d’objets alloué pendant
9
un tirage totalement aléatoire donne des résultats très mauvais
13
un certain moment. Alors on pourra estimé par le minimum de temps d’allocation au début (ou une valeur de telle sorte que dans À % des cas l’allocation dure plus longtemps),
puis on réévaluera < de façon à ce que, si la réévaluation a lieu après secondes de l’allocation, À % des cas des allocations qui aiient duré au moins secondes durent au moins
[ < secondes. Il faudra choisir À
assez grand mais pas trop pour éviter d’évaluer trop
}ÊÉ
Å ).
court ( Å · ™¸À
Références
[1] Poul-Henning Kamp. Phk malloc. http ://people.freebsd.org/ phk/. Allocateur
utilisé dans les systèmes BSD libres (FreeBSD, OpenBSD, NetBSD).
[2] Sacha Krakowiak. Principe des Systèmes d’Exploitation. DUNOD Informatique, 1985.
[3] Jacob Lorch. Operating Systems Techniques for Reducing Processor Energy Consumption.
PhD thesis, University of California at Berkeley, 2001. Chapitre 2.
[4] Micron technology, inc. http ://www.micron.com. Un des principaux constructeurs
de mémoires.
14