Η εργασία αποτελεί μελέτη της λειτουργίας των caches, χρησιμοποιώντας μια συγκεκριμένη cache δομή. Η εργασία αυτή έχει σα σκοπό τη μελέτη των κρυφών μνημών με μη ομοιογενή χρόνο προσπέλασης στα διάφορα «φυσικά» σημεία της επιφάνειάς της. Αντικειμενικός σκοπός των κρυφών αυτών μνημών, είναι να τοποθετούνται τα δεδομένα που χρησιμοποιούνται συχνότερα, σε θέσεις που βρίσκονται κοντύτερα στον επεξεργαστή και έχουν λιγότερες διασυνδέσεις καλωδίων, άρα έχουν και το μικρότερο χρόνο προσπέλασης. Όταν αυτό είναι επιτεύξιμο, τα δεδομένα που χρησιμοποιούνται περισσότερες φορές, χρειάζονται τον ελάχιστο χρόνο για την προσπέλασή τους. Για το σκοπό αυτό επιλέξαμε έναν ήδη προτεινόμενο μηχανισμό, τον οποίο αναλύσαμε εκτενώς. Η επιλογή αυτή δεν έγινε τυχαία, αλλά επιλέξαμε έναν μηχανισμό που διαφέρει στη λογική από τη γενική έννοια των εν λόγω κρυφών μνημών (NUCA), έχοντας σαν κύρια διαφορά ότι διαφοροποιεί εντελώς τη διαχείριση του tag από εκείνη του data array, αντίθετα με τις γενικότερης έννοιας NUCA μνήμες. Εκτός από τη λειτουργία της δομής αυτής όπως είχε προταθεί, εισάγουμε στη διαχείριση των δεδομένων και την πληροφορία της πρόβλεψης για να δούμε πως μπορεί να επιδράσει στην απόδοση και αν μπορούμε να καταφέρουμε κάποια βελτίωση. / This work is a study of cache memories, using a specific cache structure. Its goal is to study cache memories with non-uniform access time for all blocks throughout the cache surface (NUCA). The objective of these "hidden" memories is to put the most often used data at the closest to processor positions (blocks), which have fewer wire connections and therefore smaller access time. Whenever this is feasible, the data used most often need are accessed in the least possible amount of time. For this purpose we chose an already proposed mechanism, which was analyzed extensively. The selection was not random, but chose a structure that differs from the usual NUCA structure, having as main diferrence that it completely decouples the tag array management from the data array, contrary to the general concept of NUCA memories. Apart from this strucure's function as originally proposed, we introduced prediction in both tag and data arrays management to see how it can affect performance and whether we can achieve some performance improvement.

Les applications modernes ont des tendances de diverger à la fois le profile I/O et les requiers du stockage. La liaison d'une application scientifique ou commerciale avec un system "general-purpose" produit probablement un résultât sous-optimale. Même sous la présence des systèmes "purpose specific" des application aux classes multiples de workloads ont encore besoin de distribuer du travail de calcul au correct system. Cependant, cette stratégie n'est pas triviale comme des plateformes différentes butent diversifier leur propos et par conséquence elles requièrent que l'application intégrée des chemins multiples de code. Le but de l'implémentation de ces chemins n'est pas trivial, il requiert beaucoup d'effort et des capacités de codage. Le problème devient vaste quand les applications ont besoin de bénéficier de plusieurs data-stores en parallèle. Dans cette dissertation, on va introduire les "storage containers" comme le prochain étape logique, mais révolutionnaire. Un "storage container" est une infrastructure virtuelle qui découple une application de ses data-stores correspondants avec la même manière que Docker découple l'application runtime des servers physiques. En particulier, un "storage container" est un middleware qui sépare des changements fait pour bouts de code des application par des utilisateurs scientifiques, de celui fait pour des actions de I/O par des développeurs ou des administrateurs.Pour faciliter le développement et déploiement d'un "storage container" on va introduire un cadre appelé Tromos. Parmi son filtre, tout qui est nécessaire pour qu'un architecte d'une application construite une solution de stockage est de modéliser l'environnement voulu dans un fichier de définition and laisser le reste au logiciel. Tromos est livré avec un dépôt de plugins parmi les quelles l'architecte peut choisir d'optimiser le conteneur pour l'application activée. Parmi des options disponibles, sont inclus des transformations des données, des politiques de placement des données, des méthodes de reconstruction des données, du management d'espace de noms, et de la gestion de la cohérence à la demande. Comme preuve de concept, on utilisera Tromos pour créer des environnements de stockage personnalisés facilement comparés à Gluster, un système de stockage bien établi et polyvalent. Les résultats vous montrent que les "storage containers" adaptés aux applications, même s'ils sont auto-produits, peuvent surpasser les systèmes "general purpose" les plus sophistiqués en supprimant simplement la surcharge inutile de fonctionnalités factices. / Modern applications tend to diverge both in the I/O profile and storage requirements. Matching a scientific or commercial application with a general-purpose system will most likely yield suboptimal performance. Even in the presence of purpose-specific' systems, applications with multiple classes of workloads are still in need to disseminate the workload to the right system. This strategy, however, is not trivial as different platforms aim at diversified goals and therefore require the application to incorporate multiple codepaths. Implementing such codepaths is non-trivial, requires a lot of effort and programming skills, and is error-prone. The hurdles are getting worse when applications need to leverage multiple data-stores in parallel. In this dissertation, we introduce "storage containers" as the next logical in the storage evolution. A "storage container" is virtual infrastructure that decouples the application from the underlying data-stores in the same way Docker decouples the application runtime from the physical servers. In other words, it is middleware that separate changes made to application codes by science users from changes made to I/O actions by developers or administrators.To facilitate the development and deployment of a "storage container" we introduce a framework called Tromos. Through its lens, all that it takes for an application architect to spin-up a custom storage solution is to model the target environment into a definition file and let the framework handles the rest. Tromos comes with a repository of plugins which the architect can choose as to optimize the container for the application at hand. Available options include data transformations, data placement policies, data reconstruction methods, namespace management, and on-demand consistency handling.As a proof-of-concept we use Tromos to prototype customized storage environments which we compare against Gluster; a well-estalished and versatile storage system. The results have shown that application-tailored "storage containers", even if they are auto-produced, can outperform more mature "general-purpose" systems by merely removing the unnecessary overhead of unused features.