Question liée à memset

Salut tout le monde !

J'aimerai modifier (accélérer) les deux boucles suivantes :

Code:

---

1 2 3 4

px = new int[output_width]; for(i=0; i<crop_x0; i++) px[i] = -128; for(i=crop_x0+crop_w; i<output_width; i++) px[i] = -128;

---

J'ai pensé à memset() mais je ne pense pas que ce soit possible...
Pouvez-vous m'éclairer ?

Merci d'avance !

Pour ce que j'en sais, un memset ne sera pas plus rapide qu'une boucle for. Je dirais même plus: je ne connais rien de plus rapide qu'une boucle for pour initilialiser un tableau, surtout si c'est un tableau d'entiers.

OK.
J'ai une autre question, bête :).
J'ai deux tableaux, initialisés avec des valeurs, et j'aimerais avoir un pointeur qui pointe sur l'un, ou l'autre, en fonction d'un flag...
J'ai essayé ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int **p1; static int tab1[16][10]={0}; static int tab2[16][10]={1};   if (flag) { p1=(int **)tab1; } else { p1=(int **)tab2; }

---

Mais ça ne fonctionne pas...
L'erreur doit être bête, mais je ne la vois pas.


EDIT : J'ai modifié le code, comme indiqué ci-dessus, et ça fonctionne.

Tu ne peux pas pointer sur un tableau à deux dimensions avec un int* ou un int**.
Tu ne peux pas non plus transtyper un tableau statique à deux dimensions en pointeur sur pointeur d'int. Ca ne représente pas du tout la même chose en mémoire.

La solution est de donner le bon type à p1 (référence sur tableau à deux dimensions) :

Code:

---

1 2 3

static int tab1[16][10]={0}; static int tab2[16][10]={1}; int (&p1)[16][10] = flag ? tab1 : tab2;

---

Tu peux aussi utiliser un pointeur (int (*tab)[16][10]) si tu dois réaliser l'affectation après la déclaration.

2 remarques:

1/ La solution que tu proposes (progfou) ne fonctionne pas. Pour s'en convaincre, rajoute la ligne suivante aprés l'affectation de p1:

Code:

---

int i = p1[3][4];

---

Pourquoi? Laurent l'a trés bien expliqué. D'ailleurs, je l'ignorais, merci Laurent :D

2/ Le code:

Code:

---

int tab1[16][10]={0};

---

va initialiser à 0 uniquement la première 'case' de ton tableau.

Oui, tout à fait, je me suis pris un segmentation fault :).
Merci laurent ;).

Citation:

---

va initialiser à 0 uniquement la première 'case' de ton tableau.

---

Je crois que c'est une syntaxe valide pour initialiser tout le tableau. La règle générale étant que s'il n'y a pas assez d'initialiseurs, le dernier est pris pour initialiser les éléments restant.

Ha. Parce qu'en fait, ne trouvant pas la solution à ce problème de memset, j'ai testé des trucs, et je me suis rendu compte que le code suivant

Code:

---

1 2 3 4 5 6

int tab[3][5]={1}; for (int i = 0; i<3; i++){ for (int j=0; j<5; j++) cout << tab[i][j]; cout << endl; }

---

me sors l'output suivant:

Citation:

---

Envoyé par console

10000
00000
00000

---

Avec visual 2005.

Les tableaux sont des exemples, en fait, ils ont une série de valeur, mais c'est trop gros pour passer ici, et ça ne sert à rien ;).

ha oui, une dernière remarque:
il est tout de même beaucoup plus pratique de manipuler des tableaux à 1 dimensions qu'à 2 dimensions... et encore plus pratique d'utiliser des vecteurs (std::vector)... et il y a également le boost::multi_array qui est trés pratique.
:D

Citation:

---

Envoyé par Laurent Gomila

Je crois que c'est une syntaxe valide pour initialiser tout le tableau. La règle générale étant que s'il n'y a pas assez d'initialiseurs, le dernier est pris pour initialiser les éléments restant.

---

Les elements restants sont initialise a 0.

Ah d'accord... Merci pour la précision.

Citation:

---

Pour ce que j'en sais, un memset ne sera pas plus rapide qu'une boucle for. Je dirais même plus: je ne connais rien de plus rapide qu'une boucle for pour initilialiser un tableau, surtout si c'est un tableau d'entiers.

---

memset sera potentiellement plus rapide, si, car il écrira par paquets et exploitera la vectorisation.
Mais notre ami ne peut pas utiliser memset puisqu'il ne veut pas donner à chaque octet une valeur x.

Edit: s/virtualisation/vectorisation/

Pourtant dans son code il initialise chaque octet à -128?

Citation:

---

Envoyé par coyotte507

Pourtant dans son code il initialise chaque octet à -128?

---

Chaque int.

Citation:

---

Envoyé par loufoque

memset sera potentiellement plus rapide, si, car il écrira par paquets et exploitera la vectorisation.

---

Est-ce que tu aurais des sources qui parlent de ça s'il te plait? Parce que je ne trouve rien sur le sujet (gotw, faqs, ...)

edit: je précise un peu les raisons de mon interrogation: les compilateurs sont sensés dérouler les boucles, et il me semble que le résultat revient au même que le traitement par paquet.

Citation:

---

Envoyé par coyotte507

Pourtant dans son code il initialise chaque octet à -128?

---

Dans le cas présent, c'est un tableau de int (4 octets). Or memset fonctionne par octet uniquement.

Je n'ai pas suivit la discution de prés, mais il y a un exemple sur boost.org qui peut etre interessant pour vous :

http://www.boost.org/libs/type_trait...ll_example.cpp

il semblerai que les librairies standart courante integre déjà ces optimisations... En tout cas chez moi je n'ai aucune difference (en release). S'il est possible de faire "mieux", ça m'interesse ^^

Citation:

---

Envoyé par r0d

ha oui, une dernière remarque:
il est tout de même beaucoup plus pratique de manipuler des tableaux à 1 dimensions qu'à 2 dimensions... et encore plus pratique d'utiliser des vecteurs (std::vector)... et il y a également le boost::multi_array qui est trés pratique.
:D

---

lol,
j'y croi pas que std::vector est aussi rapide qu'un tableau :P
c'est juste plus securisé.
Puis le prob d'un tableau c'est comme tout faut savoir s'en servire :mouarf:

Citation:

---

j'y croi pas que std::vector est aussi rapide qu'un tableau

---

Pourtant, c'est le cas.
Pourquoi ça ne le saurait pas ?

Citation:

---

Envoyé par loufoque

Pourtant, c'est le cas.
Pourquoi ça ne le saurait pas ?

---

ben a premier vu, parcourir un tableau directement et plus rapide que de le parcourir par des fonctions (cas du std::vector). Aprés je peut me trompé, mais meme les iterator sont pas de vrai "pointeur" (accés plus lent) et je n'ai jamais vu, pour du traitement d'image, une seule lib qui utilise le std::vector pour son buffer. Ou meme pour des partie les plus optimisé d'un code. Donc pour moi, les vector encapsule un tableau, il est donc plus lent du a l'accés par des fonctions. Par contre il est plus securisé.

Tout peut être correctement inliné (même les opérations sur les itérateurs), donc cela revient strictement aux mêmes opérations que tu aurais faites sur ton tableau brut. Donc tu peux t'attendre à n'avoir aucune perte de performance après une compilation optimisée.

Citation:

---

Envoyé par Laurent Gomila

Tout peut être correctement inliné (même les opérations sur les itérateurs), donc cela revient strictement aux mêmes opérations que tu aurais faites sur ton tableau brut. Donc tu peux t'attendre à n'avoir aucune perte de performance après une compilation optimisée.

---

voici le code de l'operateur [] pour le vector de VC8

reference operator[](size_type _Pos)
{ // subscript mutable sequence
_SCL_SECURE_VALIDATE_RANGE(_Pos < size());
return (*(_Myfirst + _Pos));
}

comme il y as "_SCL_SECURE_VALIDATE_RANGE(_Pos < size());" a chaque appel (inline ou non)
Pour moi c'est plus lent mais plus securisé.

Citation:

---

Envoyé par Mongaulois

comme il y as "_SCL_SECURE_VALIDATE_RANGE(_Pos < size());" a chaque appel (inline ou non) Pour moi c'est plus lent mais plus securisé.

---

Regarde un peu comment c'est defini.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Regarde un peu comment c'est defini.

---

Code:

---

1 2 3 4 5 6 7 8 9

#define _SCL_SECURE_VALIDATE_RANGE(cond) \ { \ if (!(cond)) \ { \ _ASSERTE((#cond, 0)); \ _SCL_SECURE_OUT_OF_RANGE_NO_ASSERT; \ } \ __analysis_assume(cond); \ }

---

il y as bien au moin test

Tu n'es pas remonté suffisamment loin. Cette macro ne fait quelque chose que si la macro _SECURE_SCL est définie à 1. Tu peux donc n'activer ces tests supplémentaires que lorsque tu le souhaites (genre en mode debug). Dans le cas contraire le code ne comportera aucune instruction superflue.

a ok.
j'ai rien dit.
merci (enfin une reponse claire):D

petit détail mais qui accelerera un peu tes boucles "for" : utilise "++i" plutot que "i++". Pourquoi ?
car l'operateur de post incrementation realise plus d'operations que l'operateur de pre incrementation et utilise une variable temporaire. Voici leur implementation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class X { public: X & operator++(void) // pré incrémentation { *this+=increment; return *this; } const X operator++(int) // post incrémentation { const X temp=const_cast<const X>(*this); // copie de l’objet dans son état actuel operator++(); // pre incrementation return temp; } };

---

Ca ne fera quand même aucune différence sur les types primitifs.