 |
Vendredi 23 mai 2025 - 21:16 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Est-il vraiment possible d'accélérer un Amiga de façon spectaculaire avec ce logiciel de mémoire tampon ? L'inspecteur Ardichvili enquête...
Le texte paru dans une publicité parue en avril 1993 à l'occasion de la sortie de HyperCache sur le marché français m'avait donné envie d'essayer ce produit.
C'était alléchant. Je cite : "...les résultats sont spectaculaires, les vitesses de transfert théoriques sont multipliées par 5 pour les disques durs et par 20 pour les disquettes... l'utilisateur a réellement l'impression d'un Amiga deux fois plus rapide...".
J'avais à peine fini de saliver que Someware me proposait l'essai du produit. Comme d'habitude, je me suis livré à quelques essais chiffrés, car on ne sait jamais... Mais d'abord, il convient de présenter le produit. Je pourrais me contenter de vous renvoyer au communiqué et à la publicité, qui reprennent à peu de chose près le texte de la documentation. Au passage, celle-ci est bien faite, très complète, bien traduite et bien imprimée. Chose qui devient malheureusement de plus en plus rare, elle est écrite en bon français, sans fautes d'orthographe ou de grammaire (s'il y en a, elles sont bien... cachées).
C'est quoi un cache ?
Pour accélérer la lecture des fichiers sur un disque (ou d'ailleurs sur toute autre mémoire de masse), on fait passer l'information lue par une mémoire tampon qui conserve, selon sa taille, tout ou partie de l'information collectée au cours d'une lecture. De cette manière, lorsque l'on voudra effectuer une seconde lecture de cette information, il y a des chances pour qu'on puisse en retrouver une partie dans le cache et donc y accéder plus rapidement qu'en effectuant une relecture sur le disque.
L'utilisateur le moins "informaticien" de l'Amiga utilise quotidiennement au moins un cache sans le savoir, c'est celui que le système attribue d'office aux lecteurs de disquettes. La taille de ce tampon a varié selon les versions d'AmigaOS, sur ma machine il est de 5 blocs, soit 2,5 ko. C'est un minimum fixé en vue de l'utilisation de machines munies de peu de mémoire, à tel point que la séquence de démarrage standard s'empresse d'en ajouter 15, ce qui met la taille du tampon à 10 ko. Ceci est suffisant pour contenir une ou deux commandes comme Dir, List ou Copy.
Pour un disque dur, comme on se trouve en général en présence d'une machine ayant au mois un mégaoctet de mémoire, on peut se montrer moins chiche. Par exemple, GVP recommande, si ma mémoire est bonne, 16 ou 32 ko de tampon par partition, mais on peut parfaitement affecter des tampons bien plus importants, selon la mémoire dont on dispose. Le tampon simple, créé par la commande AddBuffers ou par dimensionnement des tampons de partitions dans le programme d'organisation du disque dur (HDToolBox, GVPSFaaastPrep, etc.), présente plusieurs faiblesses :
- Toute nouvelle lecture vient écraser le haut (ou le bas, je n'en sais rien, mais l'effet est le même)
du tampon et donc en efface peut-être précisément une information dont on pourrait avoir besoin à nouveau.
- Dans le cas d'un disque dur à plusieurs partitions, il faut un tampon par partition. Cela monte vite. Pour des raisons que je n'expliquerai pas ici, j'ai sept partitions sur mon disque dur, avec chacune 32 ko de tampon ; au total cela fait 224 ko, c'est lourd ; je connais pourtant quelqu'un qui fait de la PAO et qui a besoin d'accès fréquents à beaucoup de fichiers de tailles diverses. Il met sur ses partitions des tampons de 128 ko.
Les caches de HyperCache
HyperCache réserve une zone de mémoire composée de "s" régions comprenant chacune "l" lignes de "p" secteurs (ou blocs de 512 octets). Tout se passe comme si l'on disposait en fait de "s" caches côte-à-côte, à la différence près que lorsque l'un d'eux est plein, on peut commencer à déborder sur un voisin. Chaque "ligne" ou groupe de "p" blocs a la caractéristique suivante : les "p" blocs sont des blocs consécutifs du disque, lus à la suite de l'un d'eux qui contenait une information recherchée. L'idée est que, chaque fois que cela est possible, le système enregistre les blocs d'un fichier à la suite, et que l'on a donc ainsi plus de chances de stocker dans le cache une information dont on pourrait avoir besoin ultérieurement. Selon les besoins, on peut modifier les valeurs des paramètres s, l et p.
L'algorithme d'exploitation s'appelle en anglais "N-Way associative look-ahead cache system", assez cavalièrement traduit "système de cache anticipatif N-chemin associatif". Personnellement, j'aurais traduit par "système de cache anticipatif et associatif à N voies" ; c'est beaucoup plus clair ainsi (gag !). Je laisserai à Cédric Beust le soin de nous expliquer un jour ce que c'est, c'est sûrement très intéressant. Il y a des moments où, n'ayant pas fait des études d'informatique, je me demande ce que je suis venu faire dans cette galère.
La question à cent sous est : "Est-ce que c'est efficace ?". Avec les questions subsidiaires : "Les accès à mon disque dur seront-ils 5 fois plus rapides ?" et "Mon Amiga ira-t-il deux fois plus vite ?"
Installation
Attention, HyperCache ne fonctionne pas avec les contrôleurs de disques durs Hardframe, et certains pilotes de périphériques, écrits sans respecter les conventions de programmation de Commodore (tiens, il n' y a pas que les auteurs de démos qui prennent des libertés !) poseront des problèmes. Someware invite toutefois les utilisateurs qui rencontreraient ce type de problèmes à les contacter.
Copier les fichiers HyperCache (ou HyperCache030) et Summary dans C: ou dans tout répertoire qui est dans un chemin accessible de partout. Puis lancer HyperCache par une commande :
| HyperCache -v vol -s# -l# -p# |
...où "vol" est le nom de l'unité physique bénéficiaire du cache, les "#" représentent le nombre de régions, lignes et secteurs pré-lus. Par défaut, HyperCache démarre avec 8 régions de 32 lignes de 4 secteurs, soit 1024 secteurs ou 512 ko. C'est en général inutilement gros. On en reparlera. Si vous mettez cette instruction dans votre séquence de démarrage, vous pouvez la mettre dans la "user-startup", mais si vous voulez réellement accélérer votre démarrage et si vous vous sentez à l'aise pour le faire, mettez-la assez bien en tête de la startup-sequence, en ajoutant un argument "-n" pour éviter que HyperCache ne demande l'ouverture d'une fenêtre d'affichage, chose peu appréciée par IPrefs, et en indiquant bien le chemin complet si vous n'avez pas mis HyperCache dans C:.
On arrête HyperCache en libérant la mémoire correspondante, par l'instruction :
| HyperCache -v vol -q |
Il faut arrêter HyperCache avant de pouvoir le relancer avec d'autres paramètres. Il suffit d'une seule instance de HyperCache pour affecter toutes les partitions d'un même disque dur. Par contre, il faudra lancer une deuxième fois HyperCache si on veut en bénéficier sur un lecteur de disquette, un lecteur à cartouche, etc., bref pour toute unité physique. On peut lancer autant de fois HyperCache que l'on veut, c'est une simple question de mémoire disponible.
On voit déjà l'intérêt de HyperCache dans le cas de nombreuses partitions : j'ai remplacé les 224 ko de tampons de mes sept partitions (que j'ai réduits à 8 ko chacun) par un HyperCache de 256 ko. Le total a augmenté de 50 ko, mais avec des avantages dont nous parlerons plus loin. La grande question est maintenant : "Comment dimensionner ce cache, et, pour une dimension donnée, quelle combinaison de s, l et p adopter ?" La réponse n'est pas simple.
Premier contact
La machine est toujours mon vieux Amiga 2000B avec sa carte GVP Combo (68030 à 22 MHz), un disque dur Maxtor de 120 Mo et 8 Mo de mémoire. Il y a 2 Mo de mémoire Chip (MegaChip) et 6 Mo de mémoire Fast 32 bits sur la Combo. Cette configuration est grossièrement équivalente en performance à un A3000 classique. Le contenu des ROM est copié en mémoire par l'instruction CPU Fastrom, ce qui rend l'exécution des fonctions d'Intuition rapides. De même le Workbench est en 4 couleurs car mon expérience en 8 couleurs a été très brève vu l'intolérable ralentissement des affichages. C'est donc un ensemble assez homogène qui -sans être la Ferrari de l'Amiga- ne se traîne pas.
Je lance HyperCache avec les valeurs par défaut en tout début de startup-sequence. Le démarrage passe de 32 à 27 secondes, c'est toujours ça de pris. J'ouvre, ferme et rouvre la fenêtre de la partition système dans le Workbench, et là je ne constate pas de différence notable.
En démarrant en mode 68000 sur une disquette, aucun gain sur le temps d'exécution de la séquence de démarrage, mais par contre, à la seconde ouverture des fenêtres, c'est instantané. Pas étonnant, avec 500 ko de cache, il y a une bonne partie de la disquette dans le cache ! J'arrête HyperCache et je commence à monter les tampons sur df0: avec AddBuffers. Pas de surprise, les résultats sont aussi bons avec 500 ko de tampon créés par AddBuffers.
Redémarrage normal, je charge une petite image (200 ko) par Mostra. L'ensemble de la procédure n'a pas l'air bien plus rapide. En fait, si le chargement de l'image prend 5 centièmes de secondes au lieu de 2 dixièmes, l'effet n'est pas très marquant. Ouverture d'un répertoire assez chargé (200 fichiers) par Browser II : pas non plus d'impression d'amélioration sensible, essentiellement pour les mêmes raisons.
Je lance ProWrite et cette fois, victoire, ça met 4 secondes au lieu de 8. En effet, au lancement, ProWrite met en mémoire toute la structure du répertoire Fonts: (c'est un vrai fouillis, j'ai une bonne centaine de polices, trois tailles en moyenne) : c'est là que le fameux algorithme N-machin anticipatif et le nombre de régions font merveille.
Au total, je suis assez perplexe, il va falloir faire des essais systématiques.
Essais
Tout d'abord, chacun des trois paramètres peut prendre des valeurs comprises entre 2 et 64 (normalement, on utilise des puissances de 2), soit six valeurs, il y a donc 216 combinaisons possibles et le produit est limité par la taille de mémoire disponible. Ensuite, pour une même taille du cache, les diverses combinaisons sont diversement efficaces, en fonction de la structure des partitions utilisées (nombre et tailles des fichiers et complexité de l'arborescence des répertoires).
Enfin, il n'est pas nécessairement idiot de comparer les résultats à ceux obtenus en augmentant tout simplement la taille des tampons du système par AddBuffers.
Comme vous aurez de toute manière à faire des essais avant de trouver la combinaison qui vous convient, je vous recommande de créer dans votre répertoire S: deux petits scripts (à protéger avec +s), qui vous rendront service (je suppose qu'une partition de votre disque s'appelle "Work:". Il vaut mieux mettre ce nom dans le script que le mettre en argument, cela évite de la retaper chaque fois) :
Pour arrêter HyperCache :
HOFF date hypercache -v work -n -q date |
Pour lancer HyperCache :
HON s 1 p
.key reg,lin,pre
.bra {
.ket }
date
hypercache -v work -n -q
hypercache -v work: -n -s {reg} -l {lin} -p {pre}
summary
date
|
...où s, l et p sont trois nombres compris entre 2 et 64.
"summary" vous affiche un tableau récapitulatif des données du cache que vous venez de lancer. Je le trouve plus pratique que l'option "-i" ou que l'utilisation de HyperCache sans l'argument "-n", qui ne rend pas le curseur après exécution.
Tests classiques
La documentation explique comment interpréter les résultats des mesures effectuées avec DiskSpeed, SysInfo et SPSTransfer. Elle déclare que DiskSpeed est un bon indicateur des performances que l'on peut obtenir avec et sans HyperCache. Va pour DiskSpeed.
L'essai a été fait avec les valeurs par défaut pour HyperCache (cache de 500 ko, 8 régions de 32 lignes de 4 secteurs). Nous donnons ici les gains de vitesse en facteur d'accélération, pas en %. En fichiers par seconde :
| Création de fichiers | 1,25 | 1,4 | 1,25 |
| Ouverture/fermeture | 7,3 | 10,1 | 32,0 |
| Balayage (scan) | 5,5 | 22,0 | 19,4 |
| Effacement | 2,0 | 10,3 | 3,6 |
En octets lus par seconde :
| HyperCache + tampon de 4 ko | 6,36 | 17,8 | 51,4 |
| HyperCache + tampon de 262 ko | 1,45 | 2,1 | 1,04 |
Comme on peut le voir, les résultats sont d'autant meilleurs que le lecteur est lent, avec toutefois certaines inversions surprenantes. Il faut garder présent à l'esprit que pour les tests de création, ouverture/fermeture, balayage et effacement des fichiers, DiskSpeed crée des fichiers de longueur nulle, cantonnés dans un espace assez restreint du disque, ce qui est favorable à HyperCache.
Par ailleurs, le test de vitesse de lecture est effectué en relisant "n" fois un même fichier de 240 ko. Dès que le cache est d'une taille supérieure à cette valeur, on ne mesure plus que la vitesse de lecture de la mémoire ! Ceci montre une fois de plus toute la difficulté de traduire en impact sur l'utilisation quotidienne les résultats de tests standard.
Cas pratiques
Manipulations de fichiers
Balayage d'un répertoire avec la commande :
| dir >ram:toto syst: opt a |
La partition comporte 1300 fichiers occupant 11 Mo. Le tampon de la partition est de 4 ko.
- Sans HyperCache : 19 secondes.
- Avec un cache de 4 régions de 4 lignes de 8 secteurs, soit 64 ko : 9 secondes.
Dans le cas de figure, les essais sur une trentaine de combinaisons montrent qu'il n'y a pas intérêt, quelle que soit la combinaison choisie, à dépasser une taille de 64 ko pour le cache. La performance originale, sans HyperCache et avec le tampon de 32 ko, était de 16 secondes.
Copie d'un répertoire dans RAM:toto
Ceci, contrairement à l'essai précédent, implique une lecture complète des fichiers. L'écriture dans RAM:toto a pour but de réduire au minimum l'impact de la vitesse d'écriture du disque. Le répertoire contient 420 fichiers occupant 3 Mo. Tampon système de 4 ko.
- Sans HyperCache : 34 secondes.
- HyperCache 4 4 8, 64 ko : 20 secondes.
Accès simultanés au même disque
La manipulation consiste à lancer en arrière-plan et simultanément les deux opérations ci-dessus. C'est ce genre d'action qui fait émettre aux lecteurs de disquettes des bruits si épouvantables. Les fichiers sont situés sur deux partitions différentes. Tampons système de 4 ko sur chacune des partitions.
- Sans HyperCache : 1'34".
- HyperCache 4 4 8, 64 ko : 38".
- HyperCache 8 4 8, 128 ko : 34".
Conclusion de ces premières manipulations : HyperCache réduit bien le temps nécessaire à ces opérations aux deux tiers ou à la moitié du temps initial. Il faut toutefois ne pas oublier que dans la pratique, cet effet sera atténué par les temps d'écriture et d'affichage, qui ne sont pas affectés par HyperCache (ni par aucun autre tampon mémoire d'ailleurs).
Animation
Une animation pas trop grosse (9 Mo, 200 images) créée par Vista Pro 2, est jouée avec l'utilitaire Vistanim, capable de faire défiler au maximum 13 images par seconde. Vistanim lit le fichier à travers le tampon, en charge ce qu'il peut dans la mémoire, et refait des lectures au fur et à mesure que la place mémoire se libère.
Le défilement à vitesse maxi a été obtenu avec 150 ko de tampon obtenus par AddBuffers (300 tampons ajoutés). La même vitesse a été obtenue avec un cache 2 4 64 de 256 ko, mais il restait des saccades dans l'animation. Un cache de 500 ko n'a pas amélioré les choses. Pour l'animation, la création d'un tampon par AddBuffers est préférable.
L'essai a été effectué également à partir de l'unité à cartouches. Dans ce cas, HyperCache n'a apporté aucune amélioration quelle que soit la dimension ou la configuration du cache. Avec un tampon créé par AddBuffers, même un tampon de 2 Mo n'a accéléré le défilement que de 20% environ. Ce résultat est paradoxal en ce sens qu'il contredit les résultats des essais de DiskSpeed, qui semblaient indiquer une accélération d'autant plus puissante que l'unité physique est lente. La raison en est que, vu qu'il était impossible de créer un cache qui contienne toute l'animation, on est finalement limité dans l'alimentation de la mémoire par la vitesse de lecture du périphérique, cette dernière ne permettant tout simplement pas de lire assez d'octets à la seconde pour assurer le défilement de l'animation au-delà d'une certaine valeur.
Traitement d'images
L'essai porte sur une tentative d'améliorer la performance d'ImageMaster dans l'exécution d'une procédure de doublement d'une image. Nous nous mettons dans la situation d'une mémoire limitée, en faisant appel à GigaMem pour disposer de la mémoire nécessaire au traitement. Nous essaierons de compenser par l'emploi de HyperCache la perte de vitesse résultant des accès au disque.
Voici les détails de la manipulation : GigaMem est configuré avec un "tout petit" tampon propre de 500 ko (les auteurs conseillent de lui consacrer la moitié de la mémoire disponible) et un fichier de mémoire virtuelle sur le disque dur, de 10 Mo. De plus, il est spécifié que ImageMaster consommera en priorité de la mémoire virtuelle. Ensuite, ImageMaster est chargé. Enfin, diverses choses sont copiées dans RAM:T de manière à ce qu'il ne reste qu'environ 900 ko de mémoire Chip, et pratiquement plus rien en mémoire Fast. Le tampon de la partition est à 4 ko.
Ceci n'est pas une manipulation à essayer sur de petites configurations : en effet, ImageMaster demande au moins 3 Mo (1,7 Mo pour lui-même, un système 2.0 un peu étoffé occupe facilement 1 Mo, et il faut bien qu'il reste un peu de mémoire). Ajoutez à cela le tampon de GigaMem et celui de HyperCache, il faut au moins 4 Mo en tout. Mais 4 Mo de mémoire totale pour faire confortablement du traitement d'image, c'est très juste.
Bon, on démarre. Chargement d'une image pas trop grosse (140 ko), choix de la fonction "Clip 2x", la région choisie est "Entire image" et top chrono.
- Sans HyperCache : 2'52".
- HyperCache 2 8 8, 64 ko : 23".
- HyperCache 2 16 8, 128 ko : 1'15".
Et maintenant, sans HyperCache mais avec un tampon créé par AddBuffers :
- Tampon de 8 ko : 2'51".
- Tampon de 32 ko : 2'24".
- Tampon de 64 ko : 44".
- Tampon de 128 ko : 43".
Sauvegarde d'une partition ou d'un répertoire
De manière à minimiser les effets d'autres facteurs que HyperCache, on a sauvegardé par ABackup, sans compression, et vers un fichier situé dans RAM:T, un répertoire d'une taille de 5 Mo contenant 650 fichiers.
- Sans HyperCache, tampon de 8 ko sur la partition : 2'32".
- Avec HyperCache 8 4 4, 64 ko : 10".
- Sans HyperCache, tampon de 100 ko par AddBuffers : 1'25".
Compilation
Un répertoire comprend les fichiers sources et un certain nombre de fichiers ".h" ainsi que le Dmakefile pour recompiler un programme quelconque. L'ensemble pèse environ 850 ko. La compilation est faite par DICE, les programmes sont résidents.
Premier essai : recompilation des bibliothèques mathématiques.
- Sans HyperCache, tampon de 8 ko : 3'05".
- Sans HyperCache, tampon de 256 ko : 2'18".
- Avec HyperCache 16 8 4, 256 ko : 1'45".
- Sans HyperCache, tampon de 8 ko : 2'08".
- Sans HyperCache, tampon de 256 ko : 1'38".
- Avec HyperCache 16 8 4, 256 ko : 1'41".
| dsearch tagada #?.c #?.h |
- Sans HyperCache, tampon de 8 ko : 7".
- Sans HyperCache, tampon de 256 ko : 3".
- Avec HyperCache 8 8 8, 256 ko : 5".
La documentation de HyperCache donne les indications suivantes, très logiques (heureusement !) :
- Si vous avez de nombreux fichiers de petite taille, augmentez le nombre de régions (s).
- Si vous avez peu de fichiers, mais de grande taille, augmentez le nombre de lignes (l).
- Si les fichiers sont très fragmentés sur le disque (ceci peut se mesurer avec un utilitaire comme Quarterback Tools), il est inutile et même nuisible d'avoir un nombre de secteurs pré-lus (p) trop grand, car il y a peu de chances que les blocs d'un fichier soient adjacents, et la prélecture d'une suite de blocs n'améliore pas les chances de trouver plus vite le bloc cherché.
Il y a un autre moyen de limiter les effets de la fragmentation, qui est de partitionner intelligemment le disque dur, en mettant dans des partitions différentes les fichiers subissant peu ou pas de modifications (fichiers système, programmes d'application) d'une part, et d'autre part les fichiers de données susceptibles d'être modifiés souvent (images, sources de compilation). C'est cette méthode qui permet également une organisation intelligente des sauvegardes. Reprenons un essai cité plus haut (dir >ram:toto opt a) pour un répertoire non fragmenté :
- Sans HyperCache, tampon de 4 ko : 20".
- HyperCache 4 4 8, 64 ko : 9".
- HyperCache 8 4 4 64 ko : 11".
- HyperCache 2 32 2, 64 ko : 13".
Conclusion
Si après lecture de tout ce qui précède, vous sentez perplexe, c'est le contraire qui serait anormal ! HyperCache améliore la performance en lecture dans la grande majorité des cas. Le gain constaté dans les cas pratiques examinés ci-dessus est de l'ordre de 30 à 50% sur les temps de lecture. L'amélioration sur toutes les opérations qui comportent également une part importante de lecture et d'affichage sera évidemment moindre.
Ceci fait que je n'ai pas eu l'impression d'avoir une machine deux fois plus rapide, sauf dans le cas précis du chargement de ProWrite. Toutefois, l'amélioration est sensible, car si j'utilise la machine deux ou trois heures durant à des tâches diverses, je sens la présence ou l'absence du cache.
Par contre, dans la majorité des cas, AddBuffers fait aussi bien. L'énorme avantage de HyperCache, surtout pour moi qui ai de nombreuses partitions sur mon disque dur, est qu'un seul cache suffit et que j'ai pu réduire fortement la taille des tampons système. HyperCache est comme on dit "transparent" pour l'utilisateur, c'est-à-dire qu'une fois lancé, on peut l'oublier. Il fait apparemment bon ménage avec tout ce qui tourne sur l'Amiga (je n'ai pas rencontré d'incompatibilité et il y a vraiment toutes sortes de choses qui tournent en arrière-plan sur ma bécane).
HyperCache est une solution économique pour accélérer les accès aux unités de mémoire de masse. L'effet sera d'autant plus sensible que la machine est limitée en mémoire. Il vous faudra en tout état de cause passer un peu de temps pour optimiser le choix des paramètres en fonction de votre machine, de la configuration de votre mémoire de masse et de vos applications.
Annexe : mise à jour de septembre 1993
Les conclusions de mon article sur HyperCache, paru dans le numéro de juillet-août d'Amiga News, risquent de ne pas rendre tout à fait justice à ce produit. Aussi, je voudrais repréciser certains éléments, à la lumière d'essais complémentaires.
A part le fait qu'il ne faut qu'un seul cache pour l'ensemble des partitions d'une même unité physique, HyperCache est susceptible d'améliorer substantiellement la performance de l'Amiga dans le cas de lectures et relectures répétées d'un ensemble de fichiers, dans un ordre quelconque, mais à condition que la taille du cache soit appropriée. En fait, HyperCache améliore la vitesse de lecture en deux temps.
Dans un premier temps, on ressent l'effet de la prélecture des secteurs. Le fait de lire à l'avance un certain nombre de secteurs consécutifs augmente fortement les chances de trouver rapidement la suite du fichier ou le fichier suivant. Cette amélioration se ressent dès la première opération de lecture ; elle s'observe avec des tailles de cache assez modestes et l'augmentation de la taille du cache n'améliore rien, jusqu'au moment où cette taille est suffisante pour que le cache puisse conserver l'ensemble des fichiers auxquels on veut accéder. C'est là qu'apparaît l'avantage d'HyperCache sur AddBuffers : HyperCache conserve les fichiers plus longtemps.
Pour mettre ceci en évidence, j'ai procédé, en collaboration avec Éric Gontier de Someware, à des essais un peu plus fouillés que ceux de l'article précédent, en voici un bref rapport.
On prend huit fichiers, de taille moyenne de 25 ko, que l'on lit au moyen d'un petit programme écrit en C. Ces fichiers sont répartis dans 4 répertoires situés sur deux partitions différentes. Ils ne sont donc certainement pas contigus. On les lit (c'est-à-dire on en lit tous les caractères) dans un ordre A, la lecture étant encadrée de deux appels au "timer". On les relit ensuite dans un ordre différent B, et on compare les temps. Les résultats donnés sont extraits d'une série d'environ 50 essais effectués avec des variations très larges sur les paramètres de lancement d'HyperCache.
- Sans HyperCache, avec un tampon de 15 ko sur chaque partition : 3"54.
- Avec un HyperCache de 2 8 8 (64 ko), première lecture (A) : 2"46.
- Avec un HyperCache de 2 8 8 (64 ko), deuxième lecture (B) : 2"42.
- Avec un HyperCache de 4 8 16 (256 ko), (A) : 2"40.
- Avec un HyperCache de 4 8 16 (256 ko), (B) : 2"08.
- Avec un HyperCache de 4 16 16 (512 ko), (A) : 2"36.
- Avec un HyperCache de 4 16 16 (512 ko), (B) : 1"58.
1. Le gain de vitesse sur la première lecture est obtenu avec des tailles de cache modestes.
2. Le gain de vitesse devient important avec un cache de grande taille. A titre de référence, avec AddBuffers, le temps ne descend pas au-dessous de 2"42 pour 200 tampons (100 ko) sur chaque partition. On comprend également que les auteurs d'HyperCache lui ont donné une taille par défaut de 512 ko, ce choix ne paraît pas évident a priori. Il semble d'ailleurs qu'il soit nécessaire que le cache soit passablement plus grand que l'ensemble des fichiers concernés, sans que je puisse en donner la raison. L'ensemble des fichiers du test faisait moins de 200 ko, et l'on constate que pour obtenir l'amélioration maximale, le cache de 256 ko ne suffit pas. Par ailleurs, la seconde série d'essais a confirmé le bien fondé de la recommandation de faire coopérer HyperCache avec un tampon d'environ le dixième de la taille du cache.
L'amélioration est plus significative encore dans le cas des accès simultanés. L'essai consiste à lancer deux fois le programme de test en arrière-plan. Le temps tombe de 1'33" à 47", soit à la moitié. Si l'on déduit de ces temps le temps d'exécution du programme (mesuré en exécutant ce programme sur une copie des fichiers en RAM:), soit 24", on constate que le temps d'exécution des opérations de lecture seules passe de 67" à 24", soit un facteur d'accélération de 3 du temps de lecture seule.
Cette nouvelle série d'essais montre qu'à condition de donner à HyperCache une taille suffisante, la gestion intelligente d'HyperCache donne lieu à un avantage significatif, chaque fois que l'on a besoin d'accéder de manière répétitive, mais dans un ordre quelconque, à un grand nombre de fichiers. On voit aussi que le fonctionnement du multitâche s'en trouve amélioré.
Conclusion
Moyennant l'utilisation d'un cache de dimension suffisante (cette dimension étant à déterminer expérimentalement en fonction de la configuration et des applications), HyperCache est susceptible d'améliorer sensiblement les conditions de travail dans le cas de compilation de programmes, ainsi que dans les cas où l'on utilise concurremment plusieurs programmes qui appellent fréquemment de nombreux fichiers, comme la PAO ou les applications de gestion.
Pour ces types d'utilisation, le fait d'avoir à chercher un peu pour trouver le meilleur réglage sera largement compensé par un confort de travail accru. Dans cette optique et vu son prix, HyperCache est une bonne affaire.
|
Nom : HyperCache. Développeur : David Plummer. Éditeur : Silicon Prairie Software. Distributeur (France) : Someware. Genre : gestion de mémoire tampon. Date : 1992. Configuration minimale : Amiga OCS, 68000, 1 Mo de mémoire, AmigaOS 2.0. Licence : commercial. Prix : 320 FF. |
|
