Didier Guillion a dit:Oui, en effet il vaut mieux savoir lire un minimum l'assembleur. Mais pour debogger aussi de toute manière.
L'ordre de grandeur entre non optimisé et optimisé est assez important, mais cela depends de l'application. Une application basée sur une interface va de toute facon passer 90% du temps dans le systeme donc tu ne verra pas de difference. Mais si tu ecrit une application avec de gros calcul, commme un encodeur/decodeur MPEG par exemple, avec des fonctions qui passent tres souvent et prennent 80% de ton temps CPU, cela vaut le coup de gagner 10-15 % dessus. Et si tu ne gagne pas assez, il vaut mieux la reecrire en assembleur.
Pour l'alignement des données, je ne suis pas tres callé en microprocesseur, mais si j'ai bien compris, il y a un cache pour les instructions, l'agencement des instructions en mémoire peut perturber le fonctionnement de ce cache.
De meme certains processeurs aiment tomber sur des mulitples de 32, 16 ou 8 octets (peut etre aussi le cache).
Ce que te signale d'ailleurs Shark.
Cordialement
Pour information, et de ma propre expérience lors du développement des routines de rasterisations de sprites :
- Code brut compilé avec Codewarior optimisations compilo à fond = Coef 1
- Désassemblage et "cheating" des instruction en C (manière d'écrire, ordre, etc..) = coef 1,2
- Réécriture en Assembleur PPC, avec obsession de l'optimisation maximal de l'usage des registres du PPC, et du chevauchement des instructions en vue d'une utilisation maximal des 2 ALU = Coef 1,4
Bref, en gros là ou cela vaut vraiment le coup de se fatiguer, en faisant de la haute couture , j'ai gagné 40% de perfs.
Maintenant j'ai pas testé sous Xcode, avec GCC, mais j'image que cela sera comme sous Cw si pas plus mauvais.