Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3405 connectés 

  FORUM HardWare.fr
  Programmation

  [C] Problème de macro

 
 


Dernière réponse
Sujet : [C] Problème de macro
bjone l'inline est pas génant.
 
le "register" peut être une contre-optimisation.
 
un bon compilo avec toutes les options d'optimisations saura relativement très bien allouer les registres aux varibles, et le fait de forcer une variable dans un registre pourrait s'avérer être une contre-optimisation, par exemple:
 
ça comme ça, c'est pas forcément mauvais:
 

Code :
  1. unsigned char *Buffer=surface->pixels;
  3. int i=hauteur;
  5. do {
  6. register int j=largeur;
  7. register unsigned char *Ptr=Buffer; // ligne courante  
  9. // traitement pixel par pixel  
  10. do {
  11.     *Ptr=traitement(*Ptr);
  12.     // d'autres register pour le traitement()
  13.     Ptr++;
  14. } while(--j);
  16. Buffer+=largeur; // ligne suivante  
  18. } while(--i);

 
 
et ça c'est plustôt pas bon si la boucle pixel par pixel n'a plus de registre:
 

Code :
  1. register unsigned char *Buffer=surface->pixels;
  3. register int i=hauteur;
  5. do {
  6. int j=largeur;
  7. unsigned char *Ptr=Buffer; // ligne courante  
  9. // traitement pixel par pixel  
  10. do {
  11.     *Ptr=traitement(*Ptr);
  12.     Ptr++;
  13. } while(--j);
  15. Buffer+=largeur; // ligne suivante  
  17. } while(--i);

 
 
 
la règle d'or c'est de toujours favoriser la boucle la plus imbriqué pour gagner du temps, il faut favoriser le code qui a la plus haute fréquence d'éxécution...

Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse
[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 
Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
bjone l'inline est pas génant.
 
le "register" peut être une contre-optimisation.
 
un bon compilo avec toutes les options d'optimisations saura relativement très bien allouer les registres aux varibles, et le fait de forcer une variable dans un registre pourrait s'avérer être une contre-optimisation, par exemple:
 
ça comme ça, c'est pas forcément mauvais:
 

Code :
  1. unsigned char *Buffer=surface->pixels;
  3. int i=hauteur;
  5. do {
  6. register int j=largeur;
  7. register unsigned char *Ptr=Buffer; // ligne courante  
  9. // traitement pixel par pixel  
  10. do {
  11.     *Ptr=traitement(*Ptr);
  12.     // d'autres register pour le traitement()
  13.     Ptr++;
  14. } while(--j);
  16. Buffer+=largeur; // ligne suivante  
  18. } while(--i);

 
 
et ça c'est plustôt pas bon si la boucle pixel par pixel n'a plus de registre:
 

Code :
  1. register unsigned char *Buffer=surface->pixels;
  3. register int i=hauteur;
  5. do {
  6. int j=largeur;
  7. unsigned char *Ptr=Buffer; // ligne courante  
  9. // traitement pixel par pixel  
  10. do {
  11.     *Ptr=traitement(*Ptr);
  12.     Ptr++;
  13. } while(--j);
  15. Buffer+=largeur; // ligne suivante  
  17. } while(--i);

 
 
 
la règle d'or c'est de toujours favoriser la boucle la plus imbriqué pour gagner du temps, il faut favoriser le code qui a la plus haute fréquence d'éxécution...
Jar Jar

bjone a écrit a écrit :

ensuite la pluspart des compilateurs C ou C++ font de l'expansion en ligne automatique, donc si tu mets toutes les options d'optimisations et ça devrait aller (au pire tu contrôles le code généré en assembleur). Même pas forcément besoin d'un inline.


De toute façon, inline, c'est comme register : la norme précise bien que ce n'est qu'une indication d'optimisation qui n'a rien d'impératif.
bjone effectivement, il faut probablement rajouter une parenthèse.
 
pour la vitesse oui un "call" (appel de sous-fonction) par pixel dans une routine travaillant au niveau pixel réduirait dramatiquement les performances, même sur un cpu actuel (ni les CPU ni les optimisations de carte 3D ne compensent des erreurs de programmation)
 
ensuite la pluspart des compilateurs C ou C++ font de l'expansion en ligne automatique, donc si tu mets toutes les options d'optimisations et ça devrait aller (au pire tu contrôles le code généré en assembleur). Même pas forcément besoin d'un inline.
 
ensuite si tu veux booster y'a une méthode plus simple pour gagner du temps:
 
unsigned char *Buffer=surface->pixels;
 
et tu te balades avec un Buffer[....]
 
ensuite vu que tu risques de faire des for, je te conseilles une approche type:
 

Code :
  1. unsigned char *Buffer=surface->pixels;
  3. int i=hauteur;
  5. do {
  6.   int j=largeur;
  7.   unsigned char *Ptr=Buffer; // ligne courante
  9.   // traitement pixel par pixel
  10.   do {
  11.      *Ptr=traitement(*Ptr);
  12.      Ptr++;
  13.   } while(--j);
  15.   Buffer+=largeur; // ligne suivante
  17. } while(--i);


 
1) effectivement éviter les "call", si le compilo fait de l'expension en ligne, pas de problème....
 
2) remonter tout ce qui est constant dans la boucle la plus imbriqué pour refaire monter le calcul des constantes dans les boucles supérieures... (par exemple remonter des calculs de constante propres à chaque ligne dans le while() des lignes)
 
3) éviter les calcul d'adresse par des multiplications genre [y*largeur+x], favoriser des incrémentations/addition de pointeurs....
 
4) tables de précalcul...
 
pour gagner du temps il ne faut pas chercher à avoir un foncion putpixel/getpixel rapide, mais à avoir la routine qui traite un bloc de pixel relativement bien optimisée)
Pour booster, il faut pas penser un routine qui traite un élément, mais une routine qui traite un "tableau" d'éléments....
Jar Jar

bobdupont a écrit a écrit :

Il s'agit d'un source C


inline existe en C99.
bobdupont

Harkonnen a écrit a écrit :

 
Ce genre d'optimisation était valable à l'époque des 8086... mais de nos jours ??  :sarcastic:  




 
C'est une fonction pour lire 1 pixel dans la mémoire video
+ c'est rapide mieux c'est
 

Harkonnen a écrit a écrit :

 
De plus, si vraiment tu tiens à ne pas faire d'appel de fonction, tu peux toujours déclarer cette fonction inline...




 
Il s'agit d'un source C
Harkonnen

bobdupont a écrit a écrit :

 
Ben pour éviter un appel de f°




Ce genre d'optimisation était valable à l'époque des 8086... mais de nos jours ??  :sarcastic:  
 
De plus, si vraiment tu tiens à ne pas faire d'appel de fonction, tu peux toujours déclarer cette fonction inline...
LetoII Rajoute un groupe de parenthés autour, marchera peut être mieu
darkoli

bobdupont a écrit a écrit :

Bon j'ai trouvé, c'était 1 manque de () autour du x et du y (pb classque avec les macros)
 
 
Ben pour éviter un appel de f°




 
??? Mouais

bobdupont Bon j'ai trouvé, c'était 1 manque de () autour du x et du y (pb classque avec les macros)
 
 

tomiotomio a écrit a écrit :

 
par ailleurs, je vois pas bien  l interet d en faire une maccro




 
Ben pour éviter un appel de f°
bobdupont Salut,
 
J'ai 1 fonction qui marche très bien et j'ai voulu en faire une macro. Mais sous forme de macro, ça ne marche plus. Je voia aucune différence entre les 2 :
 
 

Code :
  1. //La fonction :
  3. Uint8  getpixel8(SDL_Surface *surface, int x, int y) {
  4. return ((Uint8 *)surface->pixels)[x + y * surface->w];
  5. }
  7. //La macro :
  8. #define GETPIXEL8(surface, x ,y) ((Uint8 *)surface->pixels)[x + y * surface->w]

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)