Fonctions C pour manipuler les chaines - Page 2

c'est lent... faut voir si c'est pour des chaine longue ou non sinon ya moyen d'optimiser..

Vertyos :
Heu... C'est exactement ma routine ça BiHi

Ué mais celle-ci je l'ai testée et Raphaël disait que la tienne marchait pas...

Ouais bah justement cette fois ça marche ! Je ne sais pas ce que j'avais foutu la dernière fois. Au fait tu ne l'aurait pas benché par hasard ?
Bon de toute façon je vais le faire tout de suite.
Merci bien les gars c'est sympa !

Au fait si dans fonction FindNextChar() je mets les premiers paramètres en registres c'est mieux en vitesse ?

unsigned short FindNextChar(register char Char asm("%a0"), unsigned short current_position asm("%a1"), char *buffer)
{
char *tmp = &(buffer[current_position]);
while(*tmp && *(tmp++) != Char)
current_position++;
return current_position;
}

En tout cas je gagne en place. Au passage TIGCC est vraiment génial ! J'ai suis passé de 12 ko à 11 ko.

Tu peux aussi déclarer ta fonction comme ça pour passer les arguments par registre:
__attribute((__regparm__))
unsigned short FindNextChar(char Char, unsigned short current_position, char *buffer);

Pour un short comme ton current_position, je te conseille plutôt %d0.
Et sinon, tu peux aussi utiliser %a2, %a3 et %a4 pour le passage par registres (et %a5 si tu n'utilises pas OPTIMIZE_ROM_CALLS, mais surtout ne touche pas à %a6 (%fp) et %a7 (%sp), sinon GCC ne va pas aimer).

Ok, merci.
Et je voulais savoir, Kevin, c'est laquelle de fonction qui sera la plus rapide entre celle-là :

char *sub_str(unsigned int begin, unsigned int end, char *str)
{
unsigned int i=0,j=0;
char *str_return = malloc((end-begin+1));
for(i=begin;i<end;i++)
{

str_return[j]=str[i];
j++;
}
str_return[j]=0;
return str_return;
}

et celle-là :

char *sub_str(int begin, int end, char *str asm("a0"))
{
int i = end-begin+1;
char *str_return = malloc(i), *tmp;

str += begin;
tmp = str_return;
while(--i) {
*tmp++ = *str++;
}
*tmp = 0;
return str_return;
}

Parce-que dans mon bench avec la fonction qui utilise les pointeurs, j'obtiens des résultats très aléatoire et des fois c'est pire que la première fonction. C'est normale ? C'est peut-être mon bench qui est mal foutu aussi. Mais qd j'utilise des pointeurs pour mes fonctions les perforamances sont très aléatoire.

Ton bench est surement mal foutu. Sinon à vue de nez je pense que la 2eme est plus rapide (enfin si GCC l'optimise comme il faut, ce que je pense qu'il fait).

Ouais de toute façon j'ai fait un bench dans mon programme (c'est là que ça ce voit le mieux) et en comparant avec les anciennes sources en enlevant les grosses conneries du genre strlen() dans une fonction qui est sans cesse appelé dans la partie compilation de mon programme, je voit que le pogramme actuel est presque deux fois plus rapide avec les routines utilisants les pointeurs, donc c'est du tout bon !
Merci encore !

Je confirme ce qu'a dit Vertyos: normalement, la solution avec les pointeurs devrait être plus rapide. Mais sache que GCC sait convertir la première en la deuxième dans certains cas, ce qui explique peut-être tes résultats bizarres.

Ouais, ok. Mais dans tout les cas c'est sûr que ce sera plus optimisé en taille et en rapidité en utilisant les pointeurs ?
Parce-que là je vois bien que je gagne déjà en place.
Et au fait avec les registre : si je met asm("a0") dans les paramètres des fonctions je gagne souvent quelque mais si je met asm("a2") je perd souvent bcp d'octets !

La grosse différence est que a0 est détruit par les appels de fonctions, a2 non. Dans certains cas, l'un est mieux, dans certains cas l'autre. À essayer cas par cas.

Tu peux aussi te contenter d'utiliser __attribute__((regparm)), comme ça le compilo peut décider de la meilleure solution. Ce n'est pas souvent une bonne idée de nommer directement en asm les paramètres si tu n'as pas absolument besoin de le mettre dans cette variable précise.

Ouais, je m'en doute bien et il suffit de mettre ça devant la fonction ?
Et c'est peux optimiser à la foisla taille et à la fois la vitesse ? Enfin le gain en vitesse sera peut-être minime ?

Le gain en vitesse est important lui aussi, surtout pour les chaînes de petites tailles. Si tu ne mets pas ça, le compilo va devoir copier l'adresse de la chaîne dans la pile, puis lire cette adresse dans la pile, et enfin restaurer la valeur du pointeur de pile.

Ah, d'accord, merci.

Pollux
: Tu peux aussi te contenter d'utiliser __attribute__((regparm)), comme ça le compilo peut décider de la meilleure solution.

Sauf qu'il ne choisit pas la meilleure solution, mais assigne bêtement les registres dans l'ordre numérique. Donc une spécification explicite peut souvent donner quelque chose de mieux.

Sauf qu'il ne choisit pas la meilleure solution, mais assigne bêtement les registres dans l'ordre numérique. Donc une spécification explicite peut souvent donner quelque chose de mieux.

Non. Je ne vois absolument pas pourquoi regparm sans paramètre supplémentaire serait obligé de faire ça. Si je décide d'introduire des optimisations agressives dans GTC version PC (optimisation globale), c'est certainement l'une des choses que je rajouterai.

Pollux
:

Sauf qu'il ne choisit pas la meilleure solution, mais assigne bêtement les registres dans l'ordre numérique. Donc une spécification explicite peut souvent donner quelque chose de mieux.

Non. Je ne vois absolument pas pourquoi regparm sans paramètre supplémentaire serait obligé de faire ça.

Parce que c'est la seule chose qui est implémentée.

Je ne vois absolument pas pourquoi regparm sans paramètre supplémentaire serait obligé de faire ça.

Ben il faut de toute façon que la façon dont il assigne les registres aux paramètres ne dépende *que* du prototype de la fonction, pour que le compilateur sache comment l'appeler sans avoir besoin du code... donc ça limite les optimisations ad hoc possibles, non ?

Sally
:

Je ne vois absolument pas pourquoi regparm sans paramètre supplémentaire serait obligé de faire ça.

Ben il faut de toute façon que la façon dont il assigne les registres aux paramètres ne dépende *que* du prototype de la fonction, pour que le compilateur sache comment l'appeler sans avoir besoin du code... donc ça limite les optimisations ad hoc possibles, non ?

Pas franchement. Le compilo peut de toute manière, à la phase de link, voir à quel endroit est appelée la fonction, et si il sait comment optimiser tous les appels et qu'il peut certifier que c'est du code C (et donc pas automodifiant), je ne vois pas pourquoi il ne pourrait pas se permettre de le modifier. On peut aussi le faire avec une compilation en 2 passes (ainsi que bcp d'autres optimisations)

Parce que c'est la seule chose qui est implémentée.

Et si je sortais la première version de GTC avec un générateur aléatoire pour l'ordre d'assignation des registres quand il n'y a pas de paramètre?

./51 > tu ferais modifier le code par le linker (donc au moment où ce code est déjà assemblé) ??
Euh, en fait je ne dois pas bien comprendre ce que tu veux dire parce que ce que je comprends me semble TOTALEMENT absurde :\
on est bien d'accord qu'au moment où tu linkes, tu as une fonction appelée sur laquelle il n'est a priori pas marqué d'où elle sort ses paramètres (y a juste un point d'entrée) et une fonction appelante dont l'utilisation des registres est déjà déterminée ? non ?

Le compilo peut parfaitement générer des infos supplémentaires sur la fonction. Par exemple, l'assembleur TIGCC 0.95 génère des infos supplémentaires sur le code. Si on pousse la logique plus loin, c'est ce qu'on obtient - et on pourrait encore faire pas mal d'optimisations globales de ce style pour améliorer significativement le code ...

Ah bon.
Mais même avec ces informations, ça me paraît toujours délicat de modifier la fonction appelante au moment du link... ça voudrait dire que tu la compiles en sachant que le passage des paramètres se fera par registres mais sans savoir lesquels, mais alors comment savoir quels registres utiliser par ailleurs pour optimiser ? tu ne peux pas non plus ? donc tu vas aller modifier du code absolument partout quand tu linkes ?
(je précise, au cas où vous n'auriez pas encore compris, que je n'y connais pas grand-chose en compilateurs )

Ben un exemple serait que le compilo génère plusieurs versions du même code... Ou encore le linker peut faire un simple échange de registres si le compilo se rend compte que la fonction appelée est codée plus efficacement comme ça. On peut aussi faire plusieurs passes de génération de code

Bon, OK, c'est possible.
Mais ça m'a quand même l'air tout sauf trivial

Oui, mais ça fait partie des possibilités d'optimisation. En tout cas c'est bien plus crédible que l'hypothèse selon laquelle le fait que le compilo suppose que les opérations signées n'overflowent pas permettrait souvent d'énormes optimisations.