Purebasic travaille plus vite avec des .l ou des .w ou .b ?

[comtois]

pour reprendre le débat portant sur le type de variable qu'il vaut mieux utiliser , je me demandais depuis un moment , ce qu'il valait mieux faire ?

Il faut choisir le type au plus juste ,car ça influence sur les performances ? ou seulement sur la mémoire dispo ?

ça n'a aucune importance ?

les différences sont minimes ?

bref , quels sont les critères à prendre en compte pour choisir un type de variable .

[Jenova]

bah la dessus je peu dors et déjà te répondre, c'est tout à fait logique, une variable qui exploite plus d'octet demande plus de travail processeur, si l'utilisation de cette variable est ponctuelle elle n'influence pas des masse, mais si son utilisation est vitale pour chaque frame alors il en résultera une baisse de rapiditée. Le C++ permet d'optimiser tout son code au plus juste, ce n'est pas pour rien.

[filperj]

D'après ce que j'ai compris (mais je suis loin d'être un expert), lire/écrire en mémoire un long, un word ou un octet prend le même temps, parceque le format "naturel" de la machine est le 32 bits.
(et ce n'est pas du tout spécifique à PB)

[comtois]

je suis de ton avis filperj , c'est pour ça que j'aimerais qu'on me confirme ça ou qu'on me détrompe .

[Jenova]

bah moi je sais ça de quelqu'un qui programme en assembleur et C++, à ce qu'il parrait tout au final est reduit en octet, et plus il y aurai d'octet et plus il y aurai de cycle processeur.

[Jenova]

Le mieux, je vais essayer de contacter un amis à moi, il fait son master en IA, c'est un vrai boss en prog, il connais une quantitée de lengages de prog incroyable, je vais lui demander et des que j'ai une réponce je vous la donne, on serra fixé.

[filperj]

Petit test:

Code : Tout sélectionner

depart=gettickcount_()
beaucoup=Pow(10,9)
For t=1 To beaucoup
  octet1.b=octet2.b
Next
arrivee=gettickcount_()
Debug arrivee-depart

et ensuite

Code : Tout sélectionner

depart=gettickcount_()
beaucoup=Pow(10,9)
For t=1 To beaucoup
  long1.l=long2.l
Next
arrivee=gettickcount_()
Debug arrivee-depart

Et ben chez moi, après plusieurs essais, le test avec les longs semble nettement plus rapide, dans les 15% de temps en moins.

[Jenova]

En attendant la réponce de mon ami je vient de tomber sur un forum ou le sujet est abordé, il va dans le sens précédament cité, à savoir que la gestion d'une variable type long ou float est aussi rapide qu'un byte.
Voici le lien (voir LeGreg):
http://www.developpez.net/forums/viewto ... 7&start=90

[comtois]

2 - utilisez les types dont vous avez besoin. C'est quoi cette histoire de préférer les types entiers. on ne "préfère" pas utiliser tel ou tel type, on a "besoin" d'utiliser un type float plutot qu'un type int. Je ne sais pas qui a pondu cette règle.
Par ailleurs pour parler d'éfficacité il faut juste se rappeler que utiliser des types float sur un processeur moderne est aussi rapide que d'utiliser des int (multiplication addition, je ne parle pas de la multiplication par une puissance de deux dont on a parlé plus haut). il peut être couteux par contre de faire la conversion int/float et vice versa trop souvent par ligne de code...

5 - Il fut un temps ou précalculer les cosinus etait bien vu par toutes les machines. A l'heure actuelles certaines machines sont tellement compliquées que vouloir y appliquer des règles simples ne t'apporteront aucun benefice.
Par exemple les processeurs modernes ont un moyen de calculer les sinus et cosinus d'un angle en une seule instruction au cout d'un nombre consequent de cycles. Et lire depuis un tableau assez important en taille mais qui n'était pas dans le cache lors de la lecture entraine un cout en cycles encore plus important. Choisissez votre camp.

Mon conseil: limitez les calculs de cosinus au strict nécessaire et ne faites le coup du tableau précalculé que si vous avez montré par A+B que cette solution vous apportera le gain nécessaire sans perdre la précision dont vous avez besoin.

Bon je retiens ça , en gros , on se casse pas la tête ,on fait confiance à sa machine qui est jeune robuste et moderne et au compilateur

et on choisit le bon type pour ses variables , pour pas gâcher... comme dirait guy


et en reprenant le post au début je retiens ça

Un changement d'algorithme par contre permet des gains énorme de performances ! On passant d'une liste simplement chaînée à une liste doublement chaînée je passe d'un calcul de 3.5 secondes à 20 millisecondes !!! Simplement car effacer un élément dans une liste chaînée demande à connaître l'élément précédent, il faut donc parcourir la liste ... quand tu as 1 million d'élément, ça prend le temps qu'il faut


Oui le meilleur moyen de faire du code rapide
c'est de faire une analyse du probleme et d'en déduire
la structure de donnée la moins mauvaise à utiliser.

Donc conseil au programmeur débutant: n'apprend pas de quel coté du if il faut mettre le bloc le plus probable, cela te donnera une fausse idée que tu maitrises la machine. Par contre prend des cours d'algorithmique de base ou lis un bouquin (style introduction a l'algorithmique de Thomas Cormen).

ça me semble être un bon conseil

[Fred]

En fait, ca va dependre de l'optimisation du code. Si on considère les choses simplement, tout est prévu pour fonctionner en 32 bits sur un processeur en 32 bits donc l'utilisation de .l donnera le meilleur resultat (ca evite les prbleme d'alignements memoire etc..). Mais, il est fort possible qu'un compilateur puisse faire des acces memoire en 32 bits pour lire 4 octets d'affilé (dans le cas d'un tableau d'octet par exemple) ce qui rendera la routine bien plus rapide. Pour ma part, je conseillerais de n'utiliser les autres types (.b et .w) que quand c'est strictement nécessaire.

Par contre je sais pas ou le gars a trouvé que les opérations sur les floats etaient aussi rapide que sur les entiers, parce c'est plus qu'inexacte. Les floats bossent en interne sur 80 bits, et l'unité de calcul n'a pas un systeme de registre efficace, ni un systeme d'acces à la memoire efficace donc c'est beaucoup plus lent..

[comtois]

Merci Fred,ça a le mérite de clarifier les choses , je ne vais plus me prendre la tête

[JCB]

Dans votre test de boucle, vous faussez le probleme !
Si on utilise une variable blus longue, c'est justement pout faire le travail en moins d'itérations