Optimisations et GFA

[Cooper]

Comme nous le savons tous, le GFA n'est pas un foudre de guerre, mais il y a plein de techniques sioux pour speeder un peu tout ça, donc je pensais ouvrir ce topic pour que nous puissions partager nos techniques et nos savoirs sur les optimisations niveau vitesse d'exécution. (astuces GFA only, pas la peine de dire "on met un bout d'asm et ça va speeder )

Je commence en posant ma modeste pierre à ce qui j'espère sera un bel édifice Je me doute bien que ce sont de modestes améliorations mais c'est pour donner l'idée du truc.

boucles :

au lieu de faire :

Code: Tout sélectionner

FOR i=1 to 10
  afficher_sprite(i)
NEXT i

faire :

Code: Tout sélectionner

afficher_sprite(1)
afficher_sprite(2)
afficher_sprite(3)
afficher_sprite(4)
afficher_sprite(5)
afficher_sprite(6)
afficher_sprite(7)
afficher_sprite(8)
afficher_sprite(9)
afficher_sprite(10)

Dérouler les boucles quoi (cf articles de Deneb et Jedi dans cette même rubrique)

calculs :

Eviter les multiplications, divisions. Privilégier des tableaux dans lesquels on aura précalculé les différentes valeurs.

Par exemple, au lieu de :

Code: Tout sélectionner

PRINT var%*10

faire :

Code: Tout sélectionner

'précalculer au début du programme nos indices de tableaux
DIM table_de_10%(100)
FOR i=1 to 100
table_de_10%(i)=i*10
NEXT i
'
' et en cours d'execution
PRINT table_de_10%(var%)
'

Si vous faites cela sur une dizaine de multiplications ou divisions, vous gagnerez un temps fou !

C'est à vous, le but n'étant pas de faire le code le plus propre, mais le plus rapide (genre démos, jeux)

[Cooper]

Personne pour booster du code ?

[ColdFire]

A part déplier des boucles, précalculer comme expliquer plus haut et éviter les sauts incessants vers une procédure, je ne sait quoi proposer

Il y a peut-être un truc tout bête : le SELECT CASE ENDSELECT au lieu du IF (dans les cas où c'est possible)

Mais à part ça je n'ai pas d'idées



ColdFire

[Cooper]

Y'a aussi le décalage de bits pour les divisions ou multiplications, mais je sais plus comment ça marche

Une aide dans la salle ?

[Rajah]

Pour les décalages de bits, petits pervers, ce sont avec les fonctions SHL SHL& SHL| si vous portez à gauche, ou SHR SHR& SHR| si vous portez à droite. Respectivement pour les entiers longs 32 bits, les entiers 16 bits et les bytes.

Sinon, si vous bossez avec des entiers, mettre % & ou | car sinon ce seront des # ou rien, donc des flottants et ça va consommer un max.

Si vous divisez par 2 un entier 16 bits positif : SHR&(val&,1) (sous réserve que le bit décalé ne se retrouve pas de l'autre côté, là, un doute m'habite)

De plus, privilégiez les fonctions plutôt que les signes : ADD(val1&,val2&) plutôt que val1& + val2&, car avec le + il passera pas un calcul flottant, et qui dit flotte dit consommation.

Mais attention, parfois, pour des divisions, il vaut mieux calculer sur des flottants, sinon le résultat sera catastrophique (perte de précision).
idem pour les grosses multiplications, si ça dépasse 32 bits dans votre jolie formule, vaut mieux passer en flottant et donc les *

[ColdFire]

Je suis tellement habitué à utiliser le symbole à la fin de mes variables, que je n'y avait même pas pensé

Pour les ADD, je n'y avait pas pensé non plus en dehors d'une incrémentation.
C'est pas bête du tout !

Sinon, y'a pas des optimisations niveau accès disque ? Il me semble que le INP(#1) n'est pas ce qu'il y'a de mieux niveau performances.

Déjas quant c'est possible, j'utilise INP& ou INP% pour lire sur 16 ou 32 bits.


ColdFire

[Rajah]

Ah, oui, et puis INC val& ou DEC val& sont plus rapides que ADD val&,1 et SUB val&,1
Mais je crois qu'on le sait tous...

[Rajah]

Autre truc : dans les FUNCTION qui doivent retourner une valeur chiffrée...

Code: Tout sélectionner

FUNCTION calcul_reponse_question_univers_et_tout_le_reste
$F%
LOCAL duree_calcul
'
duree_calcul=50*60*60*24*365*7500000 ! snif, ça dépasse 32 bits, donc pas de LONG
'
PAUSE duree_calcul
RETURN 42
ENDFUNC

1) bizarrement, les variables déclarées en LOCAL coûtent plus en temps de gestion qu'une variable globale, donc les LOCAL sont à utiliser avec modération si vous voulez aller vite. Si vous voulez faire propre, il vaut mieux par contre.
En C : les variables locales sont plus propres ET plus rapides.

2) le $F% indique au compilateur "la fonction retourne un entier LONG 32 bits".
Si cette option de compilation n'est pas indiquée, il retournera toujours la valeur sur un flottant... et qui dit flotte...
On pourrait aussi mettre $F& et $F| voire $F! (pour les booléens) mais gros bug, Lonny Pursell s'est aperçu que le compilo n'interprétait pas ces trucs, et qu'ils ne servaient donc à rien : résultat, avec un $F&, la valeur retournée est un flottant, donc ça devient lent. Mettez un $F%, même pour un BYTE, cela sera mieux que rien.

Bon, ces petites combines, c'est du gagne-petit ; on peut être laxiste ça et là... mais si votre appel de fonction se trouve dans une méga-boucle de la mort qui tue, cela peut être intéressant. Comme d'hab, c'est avec des centimes qu'on fait des millions.

[leglod]

C'est interessent SHR pour la division par 8 16 ou 32 mais comment on fait pour la multiplication c'est possible ?

[tomchi]

SHR pour la division, SHL pour multiplier.