Tableau d'étiquettes séparé par rapport à un tableau de données

Question

Je me demande où les étiquettes sont normalement stockées. J'ai vu des caches de données d'étiquette combinées où les étiquettes et les données sont stockées ensemble, et où seulement la partie d'étiquette est accédée avant d'accéder à la partie de données quand il y a une étiquette correspondante avec l'adresse de mémoire. D'autre part, j'ai vu des caches d'étiquettes et de données complètement séparés, avec des bits valides séparés et d'autres bits. Je me demande lesquelles de ces approches sont couramment utilisées, et s'il y a une différence de performance ou d'efficacité énergétique entre ces deux structures?

Merci d'avance.

Answer 1

Les caches de premier niveau sont généralement implémentés comme étant virtuellement indexés et marqués physiquement. Ce qui signifie que vous prenez l'adresse virtuelle, obtenez les bits d'index et commencez à localiser l'entrée indexée par les bits d'index, dans le cache. En même temps, vous envoyez l'adresse virtuelle à l'unité de traduction virtuelle à physique (par exemple: TLB) et obtenez l'adresse physique.

Si le bit valide n'est pas défini, vous avez envoyé l'adresse physique au cache de niveau suivant. Si le bit valide est défini, (à ce moment vous aurez déjà l'adresse physique de TLB), vous faites la comparaison d'étiquette. Pensez à l'implémentation de la balise cacheline + comme des tuples de liste (ex: en python) qui peuvent être indexés par les bits d'index. Une fois que vous avez localisé l'entrée dans la liste, vérifiez pour la 0e entrée pour l'étiquette et la 1ère entrée pour les données dans l'uplet sélectionné.

Maintenant à la vraie question de faire, nous gardons la balise et les données physiquement adjacentes dans le cache et quel genre d'avantages nous avons en faisant ainsi? Je pense que c'est à quel genre de domaines d'application que vous utiliseriez le cache. Pensez maintenant à la partie étiquette et données qui sont deux unités distinctes et peuvent être mises sous tension ou hors tension (ne pas s'éteindre, DVFS uniquement). Si votre application a un ratio supérieur à (nombre d'accès au cache/instructions numérisées), il est logique de conserver à la fois la mise sous tension et la liaison, car vous avez plus de chances d'obtenir une demande de cache vivre et prêt à partir.

Si votre application a un faible ratio (les instructions d'accès au cache num/num sont exécutées), il n'y a pas de raison de gaspiller l'énergie en gardant les deux sous tension. Vous pouvez simplement garder la balise sous tension et sur un coup dans la balise, vous mettez sous tension la partie de données et répondez.