Scrolling, aidez moi !!! - Page 6

Ah oui, c'est vrai.
Mais il les avait écrites en C, ses fonctions. Donc c'est normal que ce soit un peu plus lent.
Quoique pour les fonctions 16x il n'y a vraiment pas beaucoup de gain de rapidité après les avoir écrites en assembleur (8.

Mais pas dans Extgraph : les routines clippées sont dans le GDK (je crois que c comme ça que ça s'appelle), qui est certes publié, mais seulement en bêta.. et pr lequel il n'y a jamais eu bncp de pub...

Euh, tu as mal compris là. "Lui-même" se reportait à Vertyos. Seulement, il n'a pas publié ses routines adaptées parce qu'il les jugeait trop lentes. Personnellement, je retiens qu'il devrait quand-même les publier. Il y a pas mal de gens pour lesquels une routine "lente" (c'est-à-dire seulement 50 fois plus rapide que le BASIC au lieu de 100 fois ) convient très bien.

En fait ce ne sont même pas des adaptations j'ai tout reprit à zéro, pensant que ça serait toujours mieux que de bidouiller Extgraph.

Les fonctions 8x8 et 16x16 marchent et sont très lente (presque 15% de moins en vitesse par rapport à Extgraph), les fonctions 32x32 sont elles completement inutilisables (2 fois plus lentes qu'Extgraph ).

Si ça interesse quelqun je ne suis absolument pas contre lui envoyer, mais je ne sais pas si c'est une bonne idée, sachant qu'il peut avoir quelque chose de bien plus performant.

Ximoon a écrit :
Nous ne déroulons pas nos boucles, nous... Sinon je parie que nos routines dépassent les tiennes enfin on verra

Mais oui...
Arretez de me gaver avec cette histoire de routine ou les boucles sont deroullé.. les veritables connaisseur savent que cela n'agit peu a partir d'un certain rang et que XLib est loin d'avoir des boucle déroulées...
Il est possible de faire mieux que XLib je ne le nie pas.. mais j'ai pas passé toute ma vie dessus..

Kevin> oops
dsl

Et puis tu la fais comme tu veux ton optimisation vitesse, je ne comprend pas qu'ils croient qu'on puisse casser une fonction en disant qu'elle déroule ses boucles

1. il est riducle de ne pas derouler les boucle du tout comme Extgraphlib!
2. Il est ridicule de derouler entierement les boucles.
3. Tout est dit.. et chaqun fait la lib qu'il veut, on a pas les meme objectif, moi je pense pas que perdre 2/3 Ko soit dramatique!

C simple en informatique c comme l'univers (non je me prend pas commen van damme ) il y a des fleche, des molécules etc..

Non en fait l'informatique est regis par la meme loi de conservation que l'univers, cad que si on produit de la chaleur on per de la masse, mais pert de la chaleur on "gagne" de la masse (c tordu oui je sais)

En info, quand on optimise pour la taille, on perd de la vitesse (boucle non déroulé), mais si on optimise pour la vitesse (boucle completement déroulé) on pert de la taille... Donc faut faire un bon comprimis et dérouler un peu les boucles, comme sa, on a le "pretexte" c plus rapide et "sa pas prend pas trop de place" en meme temps !

Vala pour la pensée #philo# du #jour#

Non mais en fait c'est comment en physique, a partir d'un certain rang, on neglige des donnée, et bien pour les boucle, il faut trouver le moment ou le dbra/f est negligeable devant le contenu de la routine.. Vive Extgraphlib...

Thibaut a écrit :
Et puis tu la fais comme tu veux ton optimisation vitesse, je ne comprend pas qu'ils croient qu'on puisse casser une fonction en disant qu'elle déroule ses boucles

Le problème est que ça prend une place énorme. Plus on déroule, plus on perd de la place. Et avec un gain linéaire de vitesse, la taille augmente exponentiellement.

et bien didonc.. si la êrte de place est de l'ordre exponentielle et que le gain de vitesse est lineaire.. faudrais se relir de temps en temps!)

en tout cas, dérouler une boucle fait souvent parti des 1res optimisations (cf memcpy etc.). Je ne comprends pas ceux qui ne comprennent pas cela et pourtant des programmeurs respectables ....

TiMad
a écrit : et bien didonc.. si la êrte de place est de l'ordre exponentielle et que le gain de vitesse est lineaire.. faudrais se relir de temps en temps!)

Je pense que c'est toi qui n'as pas compris...

Déjà, il faudrait savoir si vous exprimez le gain en dB

Kevin c plutot

La vitesse augment de la meme maniere qu'un ln(x) (g oublié le nom de cette courbe .. ), et la taille de maniere linéaire

sa serait plut juste

de manière logarithmique ?
logarithmiquement ?

Tiens, j'ai fait rire Kevin


Soit N le nombre de fois que le code élémentaire doit se répéter.
Soit C le nombre de cycles pris par le code élémentaire.
Soit D le nombre de cycles pris par le dbf.
Soit T le nombre de cycles pris au total par la routine.

Soit O la longueur du code élémentaire.
Soit L la longueur totale de la routine.

Enroulage complet :
L = O
T = N*(C + D)

On double la taille :
L = 2*O
T = N*C + N/2*D = N*(C + D/2)

On triple la taille :
L = 3*O
T = N*C + N/3*D = N*(C + D/3)


=>
- la fonction qui donne la longueur est : L(x) = O*x
- la fonction qui donne le temps est : T(x) = N*(C+D/x)
Ce qui donne une courbe en 1/x :



On voit hyper-clairement que le temps d'exécution est grand si on ne déroule pas, mais qu'il finit par ne plus diminuer de manière sensible quand on déroule trop.

Pour finir : la taille augmente linéairement, et le temps diminue ???ment.

erreur: L=O*x+<Taille du DBF>
Enfin ce n'est pas le dbf qui va beaucoup augmenter la taille...

Exponentiellement inverse ??

c pas exponentiel, c hyperbolique (je sais pas si ça se dit en +infini ou si c'est valable seulement en 0)

bonne question...

Link :

tout ca pour dire que c'est pas exponentielle.
et puis on peu jouer sur les mots mais bon a depend aussi comme on considere les termes///