Bulldozer et innovations

[Doc TB]

Ils sont clairement revenus dans un schéma beaucoup plus classique. Pour l'heure, les samples n'ont pas le SMT activé. C'est étrange si "proche" de la sortie théorique. Sans rapport, mais j'aimerais bien savoir comment ils vont découper et gérer l'AVX2 avec leurs unités là.

Plus généralement, je ne comprends pas du tout leur stratégie de vouloir faire un 8 core + HT. Si leurs timings leur permet, un 4C+HT clocké plus haut serait bien plus efficace niveau cout et power.

[Thamior]

A priori leurs datapaths et unités font 128-bit, donc je suppose que tout ce qui est 256-bit sera fait en deux fois, ou plutôt en utilisant deux unités à la fois.

Par rapport aux 8 coeurs, je dirais que ce sont les gens du marketing qui sont intéressés (plus de coeurs c'est mieux c'est bien connu). Peut-être aussi que leur implèm du SMT n'est pas encore au point niveau perf...

[Doc TB]

Il y a un loup sur le L3 avec les samples actuels aussi. Ils ont 16 Mo de L3 en 16-way mais j'ai l'impression qu'il est virtuellement découpé en 2. On dirait (impression sur les premiers retours) que les coeurs sont séparés en 2 blocs de 4 et que chaque "bloc" ne peut accéder qu'à 8 Mo. J'ai du mal à comprendre comment ils gèrent la cohérence de tout ce dawa.

[Thamior]

Hmm, sur les slides ils annoncent 8Mo de L3 donc ça paraît raisonnable de n'accéder qu'à 8Mo de L3. Ou on a pas vu la même chose?

[Doc TB]

Lol, l'edit d'Anandtech :

http://www.anandtech.com/show/10578/...chy-revealed/2

Edit 7:18am: Actually, the slide above is being slightly evasive in its description. It doesn't say how many cores the L3 cache is stretched over, or if there is a common LLC between all cores in the chip. However, we have recieved information from a source (which can't be confirmed via public AMD documents) that states that Zen will feature two sets of 8MB L3 cache between two groups of four cores each, giving 16 MB of L3 total. This would means 2 MB/core, but it also implies that there is no last-level unified cache in silicon across all cores, which Intel has. The reasons behind something like this is typically to do with modularity, and being able to scale a core design from low core counts to high core counts. But it would still leave a Zen core with the same L3 cache per core as Intel.

On dirait qu'il lit ce forum :D

PS : Son edit n'étant pas à la bonne heure, je ne suis pas sur que j'ai posté ça avant lui en fait. Ceci dit, je promet que je n'ai pas lu Anandtech avant mon commentaire du dessus :D

[hellsing]

tu as pas un die shot , on pourra peut être voir la répartition du cache physiquement (alexko tu avais les précedents).

Et ils ont (j'espère) peut être un 4C4H en embuscade mais montrent que le plus gros.

[Thamior]

Il apparaît en effet que ce soit 8Mo de L3 par cluster de 4 coeurs.
Un peu réminiscent des premiers Core 2 Quad si je ne m'abuse?

Sinon le L2 est inclusif, et le "L3 is filled from L2 victims" que j'ai du mal à parser (le L3 est juste un victim cache pour les L2?).

[Møgluglu]

Oui, sauf qu'il ne doit pas être exclusif comme le serait un victim cache. Ni inclusif ni exclusif.
Au premier accès, on monte la donnée dans le L1 et le L2 sans toucher au L3. Une fois évincée du L1 puis du L2 on la déplace dans le L3. Mais une fois dans le L3 elle peut encore revenir dans le L2 sans disparaitre du L3.

[Thamior]

C'est vrai. Donc si tu fais du streaming tu ne mets rien dans ton L3. D'un autre côté, tu ne prefetches rien dans ton L3 non plus.
Cela dit AMD mentionne que le L3 est "mostly exclusive of the L2". Est-ce que recharger 512Ko depuis le L3 dans le L2 c'est "mostly exclusive", je ne sais pas .

AMD disait pour Shanghai :

First access to an address (which would lead to an L3 miss) will bring the line straight into L1 data cache. Thus the L3 is non-inclusive. Only after it is evicted from L1 and then from L2, will it come into L3. Once in L3, there are various scenarios where the L3 returns data and retains the line. The L3 behaves as an inclusive cache by keeping a copy, if it is likely the data is being accessed by multiple cores, versus behaving as an exclusive cache by removing the data from the L3 cache (and placing it solely in the L1 cache, creating space for other L2 victim/copy-backs), if it is likely the data is only being accessed by a single core. So this duplication of data in this “mostly exclusive” design happens only when it is possible for the data to be shared, emphasizing the role of the L3 to enable sharing of data between the cores. This is also seen when making a decision to evict a line from L3, where it prefers to evict unshared lines over shared lines.

Je surinterprète peut-être mais d'après les slides sur Zen ça pourrait-être quelque chose comme ça (on retrouve la terminologie "mostly exclusive"). Je ne sais pas si Bulldozer faisait quelque chose de similaire.

Je jetterai bien un oeil au nombre d'invalidations générées pour respecter l'inclusivité du L2. Là il y a en gros 256Ko de L2 par thread (512Ko L2 et 2 threads/L2), alors que chez Intel si on divise le cache inclusif par le nombre de threads on a entre 512Ko et 1Mo. Enfin, ce n'est sans doute pas un problème, je suis juste curieux. Et puis d'un autre côté c'est pas comme si ils communiquaient sur la gestion de la cohérence.

[Alexko]

Ils sont clairement revenus dans un schéma beaucoup plus classique. Pour l'heure, les samples n'ont pas le SMT activé. C'est étrange si "proche" de la sortie théorique. Sans rapport, mais j'aimerais bien savoir comment ils vont découper et gérer l'AVX2 avec leurs unités là.

Plus généralement, je ne comprends pas du tout leur stratégie de vouloir faire un 8 core + HT. Si leurs timings leur permet, un 4C+HT clocké plus haut serait bien plus efficace niveau cout et power.

C'est officiel que le SMT n'est pas activé ? Et si oui, quelqu'un a déjà benché Blender avec et sans SMT ? J'imagine que ça doit se trouver sans trop de difficulté.

Concernant leur stratégie, je subodore que leur archi, leur process, règles de design et bibliothèques de synthèse sont mal adaptés aux hautes fréquences, et qu'ils n'ont aucune chance d'être compétitifs avec un Kaby Lake quad-core en n'utilisant que quatre cores. Donc je trouve assez logique d'en mettre 8 et de baisser un peu les fréquences pour améliorer le rapport perfs/W et être sûr de gagner des benchmarks.

Vaut mieux être devant dans certains benchmarks et derrière dans d'autres que tout le temps derrière, même en n'étant pas super loin.

[Thamior]

Je suppose que pas mal de monde a déjà jeté un oeil aux slides de mercredi (chez Ars par exemple), mais moi ce qui me hype le plus, c'est à 16:45 dans la présentation de Hot Chips. Je ne sais pas exactement quelle forme de memory bypassing est implémentée, mais je trouve ça plutôt bienvenu (après je suis peut-être un peu biaisé ).