Il me semblait que c'était à surface constante, d'où problème de « mur de la chaleur » etc. Pareillement les moulti-cœurs ne changent rien au problème d'intégration.
Techniquement la surface est constante, non ? Je veux dire, j'ai pas vu d'augmentation significative de la taille des puces qu'on met dans un PC. :)
Concernant la programmation des PS3 & co:
Le gros problème du Cell B.E. était surtout qu'à sa sortie (i.e. à la sortie de la PS3) il n'y avait pas de bonne chaîne de compilation pour développer sur la plate-forme. Quand le problème de programmabilité de la PS3 avait été soulevé à l'époque, j'en avais parlé à un pote qui avait bossé sur la PS2 pour faire du middleware à destination d'autres studios de dév. Sa réponse était en substance « Non mais c'est n'importe quoi, la PS2 aussi avait l'équivalent de 2 SPU. Simplement maintenant il y a plus de gens s'intéressant à comment on programme ces machines qu'avant, du coup la difficulté pour les programmer est plus largement connue. »
Pour avoir eu à faire un peu de prog sur Cell et sur d'autres machines exotiques (pas de caches, juste des scratchpads, aka des mémoires locales sans mémoire virtuelle, etc.), je peux dire que oui, c'est assez compliqué, surtout si y'a pas d'outils pour aider. Depuis (mais hélas bien trop tard), des gens ont développé des chargeurs automatiques de code et données depuis/vers les SPU de la PS3 (une amélioration sur les code overlays, un truc qui avait été pas mal utilisé pour … MS-DOS et DR-DOS, par ex), des systèmes de cache logiciel aussi — qui permettent de proposer un système de « constance1 » plus faible que ce qu'on utilise habituellement dans les architectures multicœur classiques, etc.
Donc bien entendu que l'archi a un impact sur les perfs, mais c'est bien le problème de beaucoup d'archis en règle générale : elles viennent avec des trucs révolutionnaires, mais les architectes ne pensent pas suffisamment aux gens qui vont programmer ces trucs. Après, c'est la responsabilité du fabricant aussi de fournir les bons outils (chaîne de compilation, etc.) pour que ça soit suffisamment simple à utiliser.
[1] « constance » est la meilleure approximation que j'ai pu trouver pour « consistency » (qui est différence de « coherency » ou « cohérence »).
[^] # Re: LLVM
Posté par lasher . En réponse au journal pythran rampe. Évalué à 3.
Techniquement la surface est constante, non ? Je veux dire, j'ai pas vu d'augmentation significative de la taille des puces qu'on met dans un PC. :)
Concernant la programmation des PS3 & co:
Le gros problème du Cell B.E. était surtout qu'à sa sortie (i.e. à la sortie de la PS3) il n'y avait pas de bonne chaîne de compilation pour développer sur la plate-forme. Quand le problème de programmabilité de la PS3 avait été soulevé à l'époque, j'en avais parlé à un pote qui avait bossé sur la PS2 pour faire du middleware à destination d'autres studios de dév. Sa réponse était en substance « Non mais c'est n'importe quoi, la PS2 aussi avait l'équivalent de 2 SPU. Simplement maintenant il y a plus de gens s'intéressant à comment on programme ces machines qu'avant, du coup la difficulté pour les programmer est plus largement connue. »
Pour avoir eu à faire un peu de prog sur Cell et sur d'autres machines exotiques (pas de caches, juste des scratchpads, aka des mémoires locales sans mémoire virtuelle, etc.), je peux dire que oui, c'est assez compliqué, surtout si y'a pas d'outils pour aider. Depuis (mais hélas bien trop tard), des gens ont développé des chargeurs automatiques de code et données depuis/vers les SPU de la PS3 (une amélioration sur les code overlays, un truc qui avait été pas mal utilisé pour … MS-DOS et DR-DOS, par ex), des systèmes de cache logiciel aussi — qui permettent de proposer un système de « constance1 » plus faible que ce qu'on utilise habituellement dans les architectures multicœur classiques, etc.
Donc bien entendu que l'archi a un impact sur les perfs, mais c'est bien le problème de beaucoup d'archis en règle générale : elles viennent avec des trucs révolutionnaires, mais les architectes ne pensent pas suffisamment aux gens qui vont programmer ces trucs. Après, c'est la responsabilité du fabricant aussi de fournir les bons outils (chaîne de compilation, etc.) pour que ça soit suffisamment simple à utiliser.
[1] « constance » est la meilleure approximation que j'ai pu trouver pour « consistency » (qui est différence de « coherency » ou « cohérence »).