Vous attendez-vous que les générations futures CPU ne sont pas en cache cohérente?

Question

Je suis la conception d'un programme et je trouve que l'hypothèse la cohérence du cache implicite rendre la conception beaucoup plus facile. Par exemple, mon seul écrivain (toujours le même fil) lecteur multiples (toujours d'autres threads) scénarios n'utilisez pas mutex.

Il est pas un problème pour le processeur Intel actuel. Mais je veux que ce programme pour générer des revenus pour au moins les dix prochaines années (un peu de temps pour le logiciel) donc je me demande si vous pensez que cela pourrait être un problème pour les architectures cpu futures.

Answer 1

Je soupçonne que les générations futures CPU encore gérer la cohérence du cache pour vous. Sans cela, la plupart des méthodes de programmation traditionnelles échoueraient. Je doute toute l'architecture du processeur qui sera largement utilisé au cours des dix prochaines années invalidera le modèle de programmation en cours - il peut prolonger, mais il est difficile de laisser tomber quelque chose si largement supposé

.

Cela étant dit, la programmation avec l'hypothèse de la cohérence du cache implicite est pas toujours une bonne idée. Il y a beaucoup de problèmes avec faux partage qui peut facilement être évité si vous essayez d'isoler volontairement vos données . Manipulation cela peut bien conduire à d'énormes performances (booste plutôt, l'absence de pertes énormes de performance) sur les processeurs de la génération actuelle. Certes, il est plus de travail dans la conception, mais il est souvent nécessaire.

Answer 2

Nous sommes déjà là. Ordinateurs réclamer la cohérence du cache, mais en même temps ils ont un tampon de stockage temporaire pour les écritures, lit peut être complété par ce tampon au lieu du cache (le tampon de stockage vient de devenir un cache incohérent) et invalider les demandes sont également mis en attente permettant au processeur d'utiliser temporairement des lignes de cache qu'il connaît sont obsolètes.

X86 n'utilise pas beaucoup de ces techniques, mais il n'utilise certains. Tant que la mémoire reste nettement plus lent que le processeur, attendez-vous à voir plus de ces techniques et d'autres encore conçus pour être utilisés. Même itanium, a échoué car il est, utilise beaucoup de ces idées, alors attendez-vous intel les migrer en x86 au fil du temps.

En ce qui concerne éviter les serrures, etc: il est toujours difficile de guage niveau d'expertise des gens sur Internet donc soit vous êtes mal orienté avec ce que vous pensez pourrait travailler, ou vous êtes à la fine pointe de la programmation lockfree. Dur à dire.

Comprenez-vous le protocole MESI, les barrières de mémoire et de la visibilité? Avez-vous lu des trucs de Paul McKenney, etc?

Answer 3

Je ne sais pas en tant que tel. Mais je voudrais voir une tendance vers des modes cohérents non-cache.

Le changement d'esprit conceptuel est important (ne peut pas passer uniquement les données dans un appel de méthode, doit passer par une file d'attente d'une méthode async), mais il est nécessaire que nous nous dirigeons de plus en plus dans un monde multi-cœurs de toute façon. Plus on se rapproche d'un processeur par banque de mémoire le mieux. Parce que nous travaillons dans un monde de routage des messages réseau, où les données sont tout simplement pas disponibles plutôt que d'avoir des fils qui peuvent silencieusement taper du pied sur les données.

Cependant, comme Reed Copsey souligne, le monde entier x86 de l'informatique repose sur l'hypothèse de la cohérence du cache (ce qui est encore plus grande que la part de marché de Microsoft!). Donc, il ne disparaîtra pas de sitôt!

Answer 4

Voici un document d'auteurs de renom dans la zone de l'architecture informatique qui soutient que cohérence du cache est là pour rester .

http://acg.cis.upenn.edu/papers/cacm12_why_coherence.pdf

"Pourquoi on-Chip Cache cohérence est là pour rester" -Par Martin, Hill et Sorin

Answer 5

Vous faites une demande étrange. Vous demandez notre (la communauté SO) hypothèses sur les architectures CPU futures - une proposition très dangereuse. Êtes-vous prêt à mettre votre argent où notre est la bouche? Parce que si nous avons tort et que votre demande échouerons ce sera vous qui n'a pas faire de l'argent ..

De toute façon, je soupçonne que les choses ne vont pas changer cela de façon spectaculaire à cause de tout le code existant qui a été écrit pour l'exécution un seul thread mais c'est juste mon avis.

Answer 6

La question semble prêter à confusion pour moi. L'architecture du processeur n'est pas important, ce qui est important est le modèle de mémoire de la plate-forme pour laquelle vous travaillez.

Vous développez l'application est un certain environnement, avec un certain modèle de mémoire défini. Par exemple. si vous ciblez actuellement x86, vous pouvez être sûr que toute future plate-forme mettra en œuvre le même modèle de mémoire quand il est en cours d'exécution du code x86. La même chose est vraie pour les machines virtuelles Java ou .NET et d'autres plates-formes d'exécution.

Si vous vous attendez au port de votre application en cours à d'autres plates-formes, si le modèle de la mémoire de la plate-forme sera différente, vous devrez régler pour cela, mais dans ce cas, vous êtes celui qui fait le port et vous avez le contrôle complet sur la façon dont vous le faites. Ceci est cependant vrai même pour les plates-formes actuelles, par exemple modèle de mémoire PowerPC permet beaucoup plus réordonnancements arrive que le x86 un.