Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - phénomène de fragmentation
(Article écrit par Xavier Leclercq et extrait d'Amiga News - avril 1992)
|
|
Nous allons donc tenter ensemble un début d'approche de la question (bel effort !).
Pour que vous compreniez le problème (car, premier point, la fragmentation est un problème),
je vais vous exposer simplement le drame qui se déroule à chaque fois que vous sauvez un
fichier sur disque.
Comme tout le monde le sait, une disquette est constituée de cylindres, subdivisés en pistes,
puis en secteurs. Chaque secteur est une suite séquentielle de 512 octets. Lorsque vous décidez
de sauver un fichier sur le support magnétique, AmigaDOS réservera un certain nombre de
secteurs pour cette opération.
Or, un secteur est une unité indivisible : la table de réservation (bitmap) indique le secteur
numéro xxx qui sera réservé comme étant le bloc de données numéro x du fichier. Il n'est pas
question d'envisager de ne réserver qu'un demi-bloc par ci, un quart de bloc par là, etc.
Vous avez bien deviné l'horreur : si votre fichier n'a pas une taille multiple de 512 (avec
FFS) le dernier bloc (de la table de hachage du fichier) aura forcément des octets non remplis par le fichier.
Concrètement
Prenons le fichier "Bidon". Ce fichier a une taille de 513 octets. En simplifiant au maximum
(c'est-à-dire en ne tenant pas compte des informations relatives au fichier et en travaillant
en FFS avec des blocs de données pures), il y aura donc réservations de deux secteurs car le 513e
petit dernier octet ne peut pas tenir sur le premier secteur qui est saturé à 512 octets.
Le dernier bloc de données contient donc un octet significatif du fichier "Bidon" et 511 octets
non utilisés !
Le cas est extrême mais il souligne bien le problème : il n'y a plus moyen d'exploiter les 511 octets
non utilisés pour le fichier car le secteur est réservé au fichier Bidon et son assignation est
indivisible... On appelle ce phénomène : fragmentation.
La fragmentation externe et interne
La fragmentation interne est par exemple le cas de la fragmentation sur disque
et peut donc se résumer en ces termes : lorsque la taille du fichier n'est pas nécessairement un
multiple entier de la taille d'un secteur, le dernier secteur alloué à cet ensemble de secteurs
n'est pas utilisé en entier, ce qui produit un fragment interne non exploité à ce secteur.
Jusqu'ici, c'est très simple à comprendre. L'Amiga n'est évidemment pas la seule machine à avoir ce
genre de problèmes. Pour tenter de réduire au maximum ces fragments internes, on pourrait être plus
précis pour désigner l'emplacement du fichier sur la disquette. Mais évidemment,
cela implique un surplus d'informations à gérer et à stocker. Donc aucun système n'est parfait et
à fragmentation interne moindre, risque de correspondre une gestion plus lourde et donc plus lente.
Quant au phénomène de fragmentation externe, plus complexe, nous pouvons l'aborder en parlant
d'allocation de la mémoire. Si vous demandez d'allouer un bloc mémoire et que chacune des zones libres
est de taille strictement supérieure à ce bloc, il faut choisir une zone libre et lui préserver ce
bloc ce qui produit une nouvelle zone libre de taille plus petite (d'un bloc). Ainsi, lors des
modifications successives de zones, on peut obtenir une grande quantité de fragments trop petits
pour permettre le placement contigu d'un nouvel ensemble d'informations.
Exemple : le système dispose séquentiellement en mémoire d'une zone libre de 10 ko, d'une
seconde zone occupée de 50 ko et d'une troisième zone libre de 40 ko.
Une demande d'allocation de 32 ko parvient au système, qui donc occupera la troisième zone,
laissant un fragment libre de 8 ko. Puis, une seconde demande de placement de 15 ko
intervient. On s'aperçoit que l'espace libre total restant (18 ko) pourrait permettre
de satisfaire la requête de 15 ko mais l'espace occupé ne serait pas adjacent.
Il n'est donc pas possible de satisfaire la requête. Le phénomène de fragmentation externe laisse deux
fragments externes inutilisables pour toute requête supérieure à 10 ko.
Mais nous avons beaucoup de chance sur Amiga. La stratégie de placements des zones par l'exec.library
et la fragmentation externe qui résulte de l'application de cette stratégie est optimum et minimum
(merci les segments qui permettent, entre autres, d'expliquer cette bonne utilisation de la mémoire grâce
à un chargement dynamique relatif et non absolu des programmes...).
Pour vous rassurez, je vous propose un petit programme assembleur qui permettra de tester la macro ASM
et de constater la faible fragmentation externe de la mémoire...
Je fais remarquer que le raisonnement qui consiste en l'utilisation pour
cette détection de fragmentation externe de la mémoire Chip,
ne tient pas compte de l'espace mémoire qui est pris par chaque zone,
considérant qu'il s'agit de mémoire Fast tout en sachant que la fragmentation
est détectée pour de la mémoire Chip.
Donc pour simplifier mes propos qui doivent être un peu embrouillés :
si vous n'avez pas de mémoire Fast et qu'execbase n'est pas situé en mémoire Fast,
les résultats seront quelque peu incorrect.
Conclusion
L'Amiga, même avec un fort phénomène de fragmentation interne sur disque (mais c'est souvent le cas aussi
sur les autres micro et mini-ordinateurs) peut se vanter d'une utilisation globale pratiquement maximale
de son espace mémoire...
|
