quelques optimisations... - Page 1

Ce post n'est pas vraiement une question, mais plutôt une remarque.
En ce moment je fait pas mal d'optimisations, alors voici quelques infos:
- on peut facilement rendre 4 fois plus rapide une fonction écrite en C si on la réécrit en assembleur
- un accès mémoire sur 2 octets n'est pas plus rapide qu'un accès mémoire 4 octets, c'est à dire qu'il vaut mieux copier deux pixels à la fois.
- le compilateur gcc (je ne sais plus quelle version) utilise très peu de registres, mais utilise beaucoup trop ldr/str. Mieux vaut utiliser des registres dans les boucles, même si c'est pour des constantes.
- pour voir le fichier assembleur créé par gcc, il suffit d'ajouter -save-temps sur la ligne de commande. Si après on veut réécrire la fonction en assembleur, on a déjà la structure du fichier.

Si vous avez d'autres trucs et astuces pour optimiser, ça m'intéresse.

- un accès mémoire sur 2 octets n'est pas plus rapide qu'un accès mémoire 4 octets, c'est à dire qu'il vaut mieux copier deux pixels à la fois.

C est pas totalement vrai, c est surtout la multiplication de l acces qui est plus longue. on gagne un chouya pour 2octets, mais vu que tu vas le faire 2 fois(pour en avoir 4), bah t y perd enormement. Sure que si tu peux copier 4octet d un coup c est mieux quand meme

Ne pas hesiter a faire des tableaux et mettre des precalculs dedans plutot que de faire faire constament des calculs previsibles.

J'imagine pas des pwads comme Eternal Doom III (qui rament parfois sur GP32) avec un GP Doom réécrit en assembleur...
Du bonheur!!!
Si quelqu'un pouvait se lancer dans la réécriture en assembleur de certains softs GP32 ça tuerait!!!

Mais je sais c'est un boulot très chiant et très long alors faut pas rêver!

une grande partie de gpdoom est en ARM c'est déja mieux que ole C

Bah si tu lis le readme de la version 8 il dit que le code est totalement en C et sans optimisations.

Alors à moins que dans la version 9 ils aient réécrit en arm...

exactement ^^