Performances du A7 par rapport au Intel Core2Duo : besoin d'infos!
Bonjour,
J'ai passé un code qui marche très bien sous Mac OS sous iOS. Très gros problème de performance.
Il s'agit d'un AURender, soit du calcul de 44100 nombres par seconde, avec seulement des fonctions de base (+/-, *), très peu de fonctions transcendantes (sin, tan...), et de très nombreux accès à la RAM (réactualisation permanentes des valeurs pour les oscillos, les filtres, etc.).
Le synthé sous MacOS balance 12 voix en titillant seulement le Core2Duo Intel (5/10% suivant les patchs). Sous iOS, passé 4 notes, je suis à 80% du CPU.
Voilà le problème! 
Maintenant les questions : xd
Peut-on savoir les performances du A7 par rapport au "bon vieux" Intel Core2Duo 2.4 GHz de mon "bon vieux" Mac. En clair, "combien de fois moins" je dois écrire des calculs comme décrits plus haut.
A moins que le problème ne vienne de l'accès à la RAM??? ??? Doit-en être moins gourmand dans la réécriture des valeurs? (une bonne vingtaine par voix 44100 fois par seconde...)
Sous MacOS, le moteur audio est en C++. Il est un mélange de C et d'Objectiv-C sous iOS (j'utilise des classes Objectiv-C, mais en les "pointant" comme des structures, comme cela est manifestement permis, du genre :
"monInstance.maValeur = uneValeur")
le C++ serait-il plus rapide que mon "mélange"??
Le A7 a l'air pourtant très performant, j'ai des moteurs audio qui tournent très bien dessus en test.
Quelqu'un aurait-il des réponses? (bien que Apple, ai-je compris en fouillant un peu sur le Web, demeure très discret sur les performances de ses matériels...)
Merci...
Réponses
J'ai progressé pas mal. En faisant faire l'essentiel des calculs dans la classe qui conserve les valeurs plutôt que dans l'AudioRender, on gagne beaucoup en performance.
Avant :
la classe audio instancie les "boites à valeurs", et réécrit dedans continuellement.
Maintenant :
la classe audio instancie les "boites à valeurs" et appelle une méthode de calcul de cette "boite" pour en récupérer le résultat.
(44100 fois par seconde et par voix toujours).
C'est ce que faisait d'ailleurs la version MacOS, via un AudioUnit.
Question : Apparemment, le fait de réécrire en Objectiv-C avec des set et des get des valeurs semble consommer plus de puissance processeur plutôt que de rester en C dans la classe. (Le nombre de calculs n'a pas changé de fait...)
Connaitriez-vous la règle à ce sujet?
Attention ! Tout ce qui est process temps réel comme du traitement audio doit être le plus performant possible pour être viable. Exit donc l'Objective-C et les types objet à cause du runtime dynamique (résolution nom du sélecteur / adresse de fonction à chaque appel). Il est impératif de rester en C et en type primitif / structure C si on veut faire des choses qui marchent correctement.
Merci Céroce et Yoann pour vos réponses.
En effet, le simple fait d'avoir passé l'essentiel des méthodes en C dans la classe qui conserve les valeurs m'a permis de fortes économies en CPU :
Avant, 4 voix consommaient 85% du CPU. Maintenant, 8 voix consomment 25% du CPU!!
C'est la bonne voie!
Il y a encore beaucoup de travail, mais c'est encourageant.
Concernant le A7, j'ai lu sur je ne sais plus quel site qu'il s'agit d'un double coeur également, cadencé un peu moins vite que mon Intel. Manifestement, on peut s'appuyer dessus pour faire des choses importantes.
Il n'y a pas que la fréquence du processeur qui compte dans ce genre d'histoire mais également la taille de la mémoire cache ainsi que la spécialisation et le nombre de cycle utilisé par instruction.
Coté instruction je ne me suis jamais amusé à comparer le jeu intel au jeu ARM, il faudrait regarder s'il y a de grosses différences.
::) Ce ne serait pas plutôt la bonne voix ?
Merci Yoann pour ta réponse.
Dernière question, concernant la RAM justement. Manifestement, celle de l'iPad est limitée. J'ai lu ici :
http://forum.iphonesoft.fr/viewtopic.php?id=7148
que l'on atteignait même pas le Go (là encore, grosse différence avec le Mac...).
A combien selon vous convient-il de limiter la conso RAM de l'appli?
Par ailleurs, cette RAM est-elle prise sur la flashRam de l'appareil ou est-ce un composant à part?
//////
En fait, ma version Mac n'utilisait que 26Mo à 30 Mo, la version iPad semble en consommer d'avantage!! (40 à 50 Mo!!) J'ai eu un plantage comme cela apparemment. J'ai du mal manifestement à contrôler cette consommation.
Le problème est d'autant plus bizarre que le simple fait de rajouter une instance de classe d'une douzaine de float32, recopiée dans l'éditeur graphique + un UIButton rajoute 3Mo de données!! Cela me semble beaucoup!
Y a t-il une méthode pour connaà®tre la taille mémoire d'un objet? (Je n'ai rien vu dans NSObject).
Ben, c'est de la SDRAM, comme sur un ordinateur classique.
La Flash, c'est différent, c'est un type d'EEPROM, c'est pour le stockage persistant.
C'est parce que tu as des dépendances. Par exemple, des frameworks vont se charger, ou les rendus des écrans sont conservés...
Pas à ma connaissance, mais ça va pas chercher loin, il y a la structure du runtime ObjC qui conserve les infos de l'objet, puis les variables d'instance, et le code de la classe (un seul exemplaire par Classe).
Je n'ai pas pu travailler ces deux derniers jours à mon projet.
Merci Céroce pour toutes ces bonnes informations.