XLib, GraphX, Extgraph ou Genlib ??? - Page 4

"Non, ce n'est plus du _nostub, parce que le nom dit "no stub"! Si tu mets un kernel dans le programme, il y a un stub!
"

Neu²,un kernel est un prog nostub.
Un prog contenant un kernel (integré dans le prog) est un programme nostub.. ne necessite pas de stub pour se lancer

TiMad
a écrit : Neu²,

Arrête de m'insulter!

un kernel est un prog nostub.

Oui, je sais, je ne suis pas bête à ce point!

Un prog contenant un kernel (integré dans le prog) est un programme nostub.. ne necessite pas de stub pour se lancer

Là non: Un programme "stub" ne "nécessite" pas un stub, il contient un stub, qui s'occupe de lancer le kernel que le programme nécessite. Si tu intègres le kernel au programme, ça n'enlève pas le stub. Donc ça reste un programme "stub".

N'importe quoi!!!
Sachatn que le stub est le programme lui meme, c'est donc du nostub


Bon ne plus j'ai perdu mon temps avec des conneries.. j'ai bencher extgraphlib, et elle est X est au minimum 25% plus rapide...

moi, je dis:
- on patche une rom avec un kernel en permanence installé et avec les libs std (optimisée) et un mix entre XLib/genlib

Kevin : la différence entre Xlib et GraphX est de 800 sprites/seconde, donc la différence X/Ext peut franchement avoisiner 1000

entre X et GX???

Heu oui j'ai pas précisé : sur un type de sprites particulier (16x16 masqués je crois). Elle peut être moindre sur d'autres types.

Et puis il faut relativiser une différence de 800 sur une routine où X irait à 1000 spr/s, ça ne ferait plus que 200 spr/s pour GX.

Mais cette différence a étré constatée sur une routine à 4000 spr/s, ce qui fait que la routine GX tourne à 3200 spr/s, ce qui est une vitesse très acceptable

mais as-tu testé dans différentes conditions?
parceque si X fait des lsl et GX de lsr par ex selon les coordonnées ça changera

mais 3200 sps c'est honnète

Bah oui c'est acceptable !

>> parceque si X fait des lsl et GX de lsr par ex selon les coordonnées ça changera

erf C'est vraiment la base de la base de la base de la base de la base de l'optimisation ! toutes les bibliothèques optimisées utilisent les deux sens de décalage, en fonction du modulo par 16 de l'abscisse.

Je sais mais c'était un exemple!
juste pour dire que le benc c'est afficher tous les sprites de (-32,-32) à (239+32,127+32)

C'est ce qui a été fait

cool
faudra que je benche les miennes rien que pour voir comment je me fais latter...

Thibaut a écrit :
Mais cette différence a étré constatée sur une routine à 4000 spr/s, ce qui fait que la routine GX tourne à 3200 spr/s, ce qui est une vitesse très acceptable

C'est ce que je dis tout le temps: si ExtGraph fait vraiment 3000 sprites/seconde - 1000 moins de XLib, comme dit TiMad -, c'est tout à fait acceptable. Mais vous préférez tous vous acharner sur la "lenteur" de ExtGraph que de faire ces considérations...

>> 3000 sprites/seconde - 1000 moins de XLib, comme dit TiMad -
On dit "1000 de moins que Xlib"

Est-ce que la fonction de ExtGraph choisit le sens de rotation en fonction du modulo par 16 de l'abscisse ?

Non.
Tu t'attends quoi d'une routine de sprites écrite en C? Qu'elle fasse le café?

Bah ouai, Einstein le fait, demande aux testeurs !

a part ça, ta réponse m'étonne. Vous pourriez gagner pas mal en vitesse en adaptant le sens de décalage en fonction de l'abscisse.

Mais il n'y a pas de swap ni de rol/ror en C...

Et puis 2 sens de rotation => 2 routines différentes => 2 fois plus de place!

Tant pis pour vous

Je trouve étrange que la différence Ext-X soit si faible (4000-3000) si vous n'intégrez pas cette optimisation

c'est alors que, comme KK l'a dit, le compilo qui optimise bien...

Un bon codeur ASM optimise obligatoirement mieux qu'un compilateur, ou alors il n'est pas un bon codeur ASM...
PpHd et JS sont des bons codeurs ASM jusqu'à preuve du contraire.

> Un bon codeur ASM optimise obligatoirement mieux qu'un compilateur, ou alors il n'est pas un bon codeur ASM...
Il existe aussi le cas: un bon codeur ASM qui utilise un algorithme de m****, ce qui fait perdre tout le bénéfice. GCC n'est pas si mauvais que ça...

Et pour de processeurs avancés (au-delà du Pentium), c'est en général une hérésie que de coder en assembleur, le compilateur fait bien mieux...

Heuuu si le même codeur (très bon en ASM et en C) implémente le même algorithme de merde en C et en ASM, la version ASM a d'énormes chances d'être plus rapide.

PpHd et TiMad sont à mon avis capables de mettre au point de bons algorithmes, et en l'occurence il n'y a pas 36 algos possibles pour afficher un sprite, donc

Quant à GCC, c'est vrai qu'il fait des choses assez étonnantes je précise par contre que Visual C++ de M$ semble plus performant (d'après Pollux, exemples à l'appui).

oué, au niveau algorithmie, c pas le langage qui fait la plus grosse différence :
un bon algo codé en C sera plus rapide qu'un mauvais codé en ASM
(enfin, sauf exceptions)

Je suis d'accord, le même algorithme sera très probablement plus rapide en ASM qu'en C.
Au fait: il n'y a pas 36 algorithmes non plus pour afficher une chaîne de caractères...

oué, c vrai que pr aficher une chaine, y'a pas 56 possibilités

par contre, pr afficher une chaine centrée sur l'écran...
y'a le moyen "standard" : un parcour de la chaine pr déterminer sa longueur, puis un second pr l'afficher...
mais en mettant la longueur de la chaine en premier caractère (caractère qui sera sauté à l'affichage), on peut gagner du temps (un parcours au lieu de deux). Bon, OK, c plus une chaine C, mais ça permet de gagner pas mal, je penses...
vous voyez une autre possibilité pr écrire une haine centrée que c deux là ?

>> il n'y a pas 36 algorithmes non plus pour afficher une chaîne de caractères...

et pour des chaines centrées sur l'écran ?

A part par un tour de magie, je ne vois pas comment faire plus rapide sans avoir la longueur

Parcourir la chaîne pour avoir la longueur, c'est vraiment trivial. Je ne pense vraiment pas que ça ait vraiment une influence sur la vitesse - c'est assez négligeable comme temps par rapport au temps mis pour l'affichage.