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

  FORUM HardWare.fr
  Programmation

  [C] Problème de macro

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[C] Problème de macro

n°171871
bobdupont
Posté le 05-07-2002 à 13:46:45  profilanswer
 

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]

mood
Publicité
Posté le 05-07-2002 à 13:46:45  profilanswer
 

n°172004
bobdupont
Posté le 05-07-2002 à 15:33:24  profilanswer
 

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°

n°172011
darkoli
Le Petit Dinosaure Bleu
Posté le 05-07-2002 à 15:42:55  profilanswer
 

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


---------------
Le site de l'année :D (XHTML 1.0 strict) : http://darkoli.free.fr/index.html
n°172012
LetoII
Le dormeur doit se réveiller
Posté le 05-07-2002 à 15:43:57  profilanswer
 

Rajoute un groupe de parenthés autour, marchera peut être mieu


---------------
Le Tyran
n°172032
Harkonnen
Modérateur
Un modo pour les bannir tous
Posté le 05-07-2002 à 16:10:09  profilanswer
 

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...


---------------
J'ai un string dans l'array (Paris Hilton)
n°172036
bobdupont
Posté le 05-07-2002 à 16:13:15  profilanswer
 

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

n°172100
Jar Jar
Intaigriste
Posté le 05-07-2002 à 17:36:26  profilanswer
 

bobdupont a écrit a écrit :

Il s'agit d'un source C


inline existe en C99.


---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book
n°172113
bjone
Insert booze to continue
Posté le 05-07-2002 à 18:03:14  profilanswer
 

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....


Message édité par bjone le 05-07-2002 à 18:06:20
n°172115
Jar Jar
Intaigriste
Posté le 05-07-2002 à 18:05:24  profilanswer
 

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.


---------------
« No question is too silly to ask, but, of course, some are too silly to answer. » -- Perl book
n°172116
bjone
Insert booze to continue
Posté le 05-07-2002 à 18:10:43  profilanswer
 

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...


Message édité par bjone le 05-07-2002 à 18:11:25

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation

  [C] Problème de macro

 

Sujets relatifs
[Word] Creer une macro pour retirer les images...Probleme de chaine de caractere dans un formulaire
[php] probleme de varriable et de tableau[PHP] - Problème de formatage d'un champ TIMESTAMP
[EXCEL] Problème avec les cellulesChti probleme de debutant
Problème avec une vielle macro Excell[asp] probleme de recordcount dans l'objet recordset
PHP/Vbulletin problème 
Plus de sujets relatifs à : [C] Problème de macro

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.072 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR