Sony améliore le SDK PS3

[KaMbiOkIkA]

Je n'ai pas vraiment compris ce que tu voulais dire ouasse. Mais par contre, ici on parle du SDK de la PS3, et donc de l'utilisation du Cell spécifiquement au jeu. C'est Sony dans son SDK qui fournit les "API" nécessaires à la gestion du Cell et de ses SPE. Je serai très curieux de savoir combien de lignes en ASM il y a dans un jeu commercial comme COD4, HS, ou autres. Par ailleurs, comment peux-tu expliquer techniquement que selon toi, une utilisation du Cell en C via le SDK de la PS3 soit pitoyable à son équivalent en ASM ??? A part quelques optimisations particulières, il y en aura très peu. Maintenant je comprends bien que l'architecture du Cell, et globalement de la PS3, éloigne les développeurs de ce qui se fait généralement jusqu'à présent. Mais on retrouve ce phénomène quand on dev en ASM, mais aussi quand on dev en C/C++.

C'est d'ailleurs pour cela que Inimz a fait un schéma pour expliquer globalement le processus de développement d'un jeu "standard". Il manque quelques infos à ce schéma pour qu'il soit plus clair, mais ce qu'il voulait dire, c'est qu'aujourd'hui, l'architecture de la PS3 fait qu'on court-circuite ces principes de bases. Rien d'autres.

Et enfin, ce que tu dis pour le Cell et valable pour tous les processeurs. On peut faire des merveilles en optimisant au max un code pour un processeur, y'a qu'à voir ce qu'on sait faire sur Amiga par exemple, avec des processeurs MC680x0, qui ferait rigoler un calculateur HP. Seulement, cette façon de faire ne colle pas vraiment à la réalité du développement de jeux professionnels, entends par la, dont c'est un métier.

++

[ouasse]

Je n'ai pas vraiment compris ce que tu voulais dire ouasse. Mais par contre, ici on parle du SDK de la PS3, et donc de l'utilisation du Cell spécifiquement au jeu. C'est Sony dans son SDK qui fournit les "API" nécessaires à la gestion du Cell et de ses SPE. Je serai très curieux de savoir combien de lignes en ASM il y a dans un jeu commercial comme COD4, HS, ou autres. Par ailleurs, comment peux-tu expliquer techniquement que selon toi, une utilisation du Cell en C via le SDK de la PS3 soit pitoyable à son équivalent en ASM ??? A part quelques optimisations particulières, il y en aura très peu. Maintenant je comprends bien que l'architecture du Cell, et globalement de la PS3, éloigne les développeurs de ce qui se fait généralement jusqu'à présent. Mais on retrouve ce phénomène quand on dev en ASM, mais aussi quand on dev en C/C++.

C'est d'ailleurs pour cela que Inimz a fait un schéma pour expliquer globalement le processus de développement d'un jeu "standard". Il manque quelques infos à ce schéma pour qu'il soit plus clair, mais ce qu'il voulait dire, c'est qu'aujourd'hui, l'architecture de la PS3 fait qu'on court-circuite ces principes de bases. Rien d'autres.

Et enfin, ce que tu dis pour le Cell et valable pour tous les processeurs. On peut faire des merveilles en optimisant au max un code pour un processeur, y'a qu'à voir ce qu'on sait faire sur Amiga par exemple, avec des processeurs MC680x0, qui ferait rigoler un calculateur HP. Seulement, cette façon de faire ne colle pas vraiment à la réalité du développement de jeux professionnels, entends par la, dont c'est un métier.

++

en fait je m'adressais surtout à ceux qui m'expliquent que le compilateur est capable de générer tout seul le code machine le plus efficace, quelle que soit l'architecture, à partir d'un code C. Ce que je disais dans mon message précédent, c'est que sur le Cell, comme une grosse partie de ce que fait un processeur habituellement tout seul doit être explicitement indiqué dans un code pour le Cell (notamment les prédictions de branchements, et les accès mémoire non-alignés), un code en C standard a peu de chances de tourner efficacement dessus.

Après, un peut se passer de l'assembleur, mais il reste quand même un besoin de bien connaitre l'architecture sur laquelle on travaille, et spécifiquement pour le Cell, qui, au risque de me répéter ne peut pas se programmer comme n'importe quel autre processeur.

Un exemple ? Le compilateur C pour SPE d'IBM (j'imagine que c'est celui qu'utilise Sony) est capable de générer tout seul des instructions de prédiction de branchement si la condition dans un test "if" est calculée suffisamment à l'avance. On perdra d'autant moins de temps que le calcul de la condition du "if" se trouve loin avant. On doit pré-calculer les conditions des tests, et jongler avec les opérations, en les exécutant dans le meilleur ordre qui soit pour optimiser le temps sur les différents "if" du programme.

Autre exemple : l'écriture d'un entier en mémoire. une écriture d'un entier de 32 bits ne peut pas se faire directement. comme les accès mémoire se font forcément sur des mots de 128 bits, il faut lire lire le mot qui recouvre notre entier de 32 bits, faire un masquage, insérer l'entier et réécrire le mot qu'on vient de modifier. Inutile de dire qu'avec une boucle de type "for" qui écrit tour à tour dans tous les éléments d'un tableau d'entiers, on se retrouve à faire 4 lectures et 4 écritures en mémoire, alors qu'on aurait pu faire la même chose avec une simple écriture d'un mot de 128 bits généré avec les opérations vectorielles du SPE. Et encore je ne compte pas les branchements inutiles qu'on économise en diminuant le nombre de tours de boucle, très coûteux sur le Cell.

Donc même en restant à programmer en C, on a besoin de connaître l'architecture du Cell, et un minimum de connaissances en langage assembleur est nécessaire.