Je vais écrire quelques programmes de traitement d'images pour Texas Instruments DAVINCI Platform. Il existe des outils adaptés à la programmation dans le langage C, mais je me demande s'il est vraiment possible de tirer pleinement parti du processeur DSP sans recourir à une langue de montage. Connaissez-vous des comparaisons de vitesse entre les programmes écrits en C et dans l'assembleur sur cette plate-forme DSP?
8 Réponses :
Le C-compilateur (autant que j'ai testé) ne tire pas pleinement parti de l'architecture.
Mais vous pouvez vous en sortir, car le DSP peut être assez rapide pour les opérations que vous devez faire.
Donc, il s'agit de tester et de profiler votre code pour voir les pièces qui doivent être accélérées pour que le système fonctionne.
Oui, pas complet, mais quelle différence d'efficacité avez-vous eu entre C et ASM?
@Michael: Si vous voulez une réponse générale à laquelle est plus rapide, je pense que ce n'est pas une bonne question, car cela dépend toujours du code particulier dont vous parlez. C'est pourquoi vous devez tester, profiler, étape unique, peu importe. Si dans le code particulier, vous voyez une fraction de temps élevée dépensée en particulier du code, et vous pouvez voir ce que C génère et vous pouvez voir comment le faire mieux avec ASM, alors c'est quand ASM peut battre C. Il n'y a pas de réponse générale .
J'ai utilisé des autres DSPS TI et C était généralement bien. L'approche habituelle consiste à commencer par écrire tout en C, puis profilez le code pour voir si quelque chose doit être optimisé à la main.
Vous pouvez souvent faire l'optimisation en C aussi, en ajustant le code C jusqu'à ce que vous obteniez la sortie de montage souhaitée. Il est important de savoir comment le DSP fonctionne et quels moyens de travailler sont plus rapides ou plus lents.
"Vous pouvez souvent faire l'optimisation en C aussi, en ajustant le code C jusqu'à ce que vous obteniez la sortie de montage souhaitée" - Cette technique en particulier a toujours fonctionné super pour moi avec Sony Hardware.
@Crash: moi aussi. C'est tout ce que je veux vraiment qu'un compilateur fasse - sauvez-moi de devoir écrire ASM. Je me fiche de "langues nounou" qui supposent que je ne sais pas vraiment ce que je fais.
dépend du compilateur C et de votre définition de "assez rapide". Les compilateurs C Standard C ont souvent du mal à utiliser efficacement le matériel DSP spécial, tels que:
généralement c est un bon endroit pour commencer. Vous pouvez obtenir le cadre global et les algorithmes ébranlé rapidement et écrivent la majeure partie de la plomberie qui déplace les données entre les mathématiques réelles. Une fois que c'est en place et que vous êtes heureux que vos structures de données soient correctes, vous pouvez regarder dans un profileur et déterminer quelles routines doivent être pressées à la main.
@Crash: Droite. Ce que je trouve souvent est: vous savez ce qui prend vraiment du temps (au moins la première fois que vous l'écrivez)? Pas le calcul. La structure de données!
Je suis d'accord. J'ai souvent plus de performances simplement en repensant la mise en page de mes données.
J'en collerais jusqu'à C jusqu'à ce que je sache qu'il y a un point chaud qui pourrait bénéficier du codage de montage. C'est la méthode "Profilage" que j'utilise. vous pourriez être surpris que là-bas sont des moyens d'accélérer le code qui ne sont pas des points chauds, mais plutôt des appels de fonction intermédiaires qui pourraient être supprimés.
Le compilateur TI pour le C64X / C64X + DSP sur OMAP3 comprend la prise en charge de ce que TI appelle des appels de fonction "intrinsèque". Ils ne sont pas vraiment des appels de fonction, ils ne sont qu'un moyen de dire au compilateur Quel outil d'assemblage à utiliser pour une opération qui pourrait ne pas être directement expansable dans C. Il est particulièrement utile pour tirer parti des opérations SIMD dans le C64X / C64X + DSP de C.
Un exemple pourrait être:
a = _add2 (b, c);
Cette instruction SIMD ajoute les 16 bits bas / hauts de B et C de B et C ensemble et stockent les résultats dans les bits inférieurs / hauts 16 bits d'A. Vous ne pouvez pas l'exprimer dans régulier C, mais vous pouvez le faire avec l'intrinsèque C OPCODES.
J'ai utilisé de manière intrinsèque pour devenir très proche de ce que vous pouviez faire avec une langue d'assemblage à part entière (à moins de 5 à 10%). Il est particulièrement utile pour les fonctions vidéo telles que le filtrage et la compensation de mouvement (_Dotpsu4!).
Je compile habituellement avec le commutateur -al et je regarde le pipeline pour essayer d'identifier les unités fonctionnelles surchargées, puis regardez mon intrinsique pour voir si je peux rééquilibrer la boucle (si j'utilise trop d'unités S, Je pourrais voir si je pouvais changer l'opcode pour utiliser une unité M).
En outre, il est utile de vous rappeler que le DSP C64X a 64 registres, chargez donc les variables locales et
Le comparateur simple de la vitesse signifie rien. Certainement c si plus pratique que l'assembleur. Vous devez mesurer le coût du temps de votre système, si le code C satisfait de votre besoin de vitesse, vous n'avez pas à utiliser Assembleur. Si la vitesse n'est pas suffisante, vous pouvez profiler votre code, trouver le code source le plus de temps tel que le code de boucle, puis l'optimiser!
Compilez à l'aide de l'optimisation -O3. C'est très puissant.
Dans le cas où il n'est pas assez bon, vous pouvez optimiser davantage le code de montage généré à votre goût au lieu de tout codé vous-même dans ASM à partir de zéro.