Discussion :

[Hibernatus34]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
int main()
{
  //code divers
  {
     Foo f;
     //code exploitant f
  }
  // encore un peu de code
  {
     Bar b;
     // code exploitant b
  }
  //autre code divers
}

Alors qu'en C il eut fallut �crire:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
int main()
{
  Foo f;
  Bar b;
  //code divers
  //code exploitant f
  //code exploitant b
  //autre code divers
}

La diff�rence provenant du fait que dans le code C++ la m�moire utilis�e par f n'est pas allou�e avant que f ne serve, et est vid�e quand il ne sert plus � rien. Idem pour b. Selon le programme, ces trucs peuvent prendre plus ou moins de m�moire, entres autres.

Pardon, mais c'est pas pertinent du tout � mes yeux, la seule diff�rence entre ces 2 codes est la port�e des variables, mais le code compil� sera probablement le m�me, puisque l'allocation de toutes les variables d'une fonction se fait par une seule soustraction. Une variable peut �tre d�clar�e dans un while, le compilo ne sera pas assez stupide pour empiler/d�piler � chaque it�ration. La seule diff�rence viendrait de la pr�sence de constructeurs/destructeurs (c'est d'ailleurs la raison pour laquelle C++ devait permettre ces d�clarations n'importe o�), mais �videmment le C n'en a pas, donc il n'est pas question de comparer �a. Ce que fait le constructeur en C++, une fonction C peut le faire... n'importe o� �galement.

(notez que je pr�f�re de tr�s loin le C++ au C)

screetch : Le code n'est pas 100% �quivalent � un array (�tait-ce le but ?), parce qu'on incr�mente le membre size du vector � chaque it�ration, ce qu'on ne ferait pas pour un array Perso je m'en fous

[rt15]

Pour le d�bat O(2n) est equivalent a O(n), c'est vrai pour les maths.
Maintenant, si les sprinters se mettaient � courir le 100m en 20 secondes, me semble que la diff�rence vous sauterait aux yeux, non ? Un programme qui deviens deux fois plus lent, �a pique en g�n�ral.

Pour ce qui est de l'utilisation de "reserve", en th�orie c'est bien, �a ram�ne probablement � un parcourt de tableau... Sauf que compil� avec g++ (En -O2 ou -O3), le code avec reserve met un temps tout � fait similaire � mon code. Les deux mettant � peu pr�s deux fois le temps pass� sur un parcourt unique...

A v�rifier, mais je suppose que c'est d� au fait que push_back a plus de boulot � faire que l'op�rateur []. Bilan la complexit� a beau �tre n, l'op�ration r�alis�e est deux fois plus complexe (Mise � jour de la size du vecteur probable par exemple).

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
#include <vector>
#include <iostream>
#include <windows.h>
 
using namespace std;
 
#define VECTOR_SIZE 20000000
 
int array[VECTOR_SIZE];
 
void constructor()
{
  vector<int> my_vector(VECTOR_SIZE);
 
  for (int i = 0; i < VECTOR_SIZE; i++)
    my_vector[i] = i;
}
 
void browse()
{
  for (int i = 0; i < VECTOR_SIZE; i++)
    array[i] = i;
}
 
void reserve()
{
  std::vector<int> my_vector;
  my_vector.reserve(VECTOR_SIZE);
 
  for (int i = 0; i < VECTOR_SIZE; i++)
    my_vector.push_back(i);
}
 
int main()
{
  LARGE_INTEGER starting;
  LARGE_INTEGER end;
 
  for (int i = 0; i < 10; i++)
  {
    QueryPerformanceCounter(&starting);
    constructor();
    QueryPerformanceCounter(&end);
    cout << end.QuadPart - starting.QuadPart << endl;
 
    QueryPerformanceCounter(&starting);
    reserve();
    QueryPerformanceCounter(&end);
    cout << end.QuadPart - starting.QuadPart << endl;
 
    QueryPerformanceCounter(&starting);
    browse();
    QueryPerformanceCounter(&end);
    cout << end.QuadPart - starting.QuadPart << endl;
 
    cout << endl;
  }
 
  return 0;
}

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
233871239
232111922
161693399
 
236877116
232803109
115653265
 
237220459
234170832
114499161
 
237944784
237114185
115160248
 
239684284
233381540
114996329
 
238357294
232007671
114847537
 
246558018
231487116
120612464
 
267180473
244786381
103820297
 
272322960
238285341
116277903
 
243198732
232527302
115246334

Quand je dis "fin", c'est pour dire que c'est petit voire n�gligeable (En th�orie on peut m�me tout � fait dire que les perfs C vs C++ sont comparables), pas pour dire qu'il faut �tre un super h�ro pour voir la diff�rence.

Mais c'est juste que quand des gens commencent � �crire que passer du code C en C++ peut, notamment, am�liorer les perfs... C'est comme dire que le java peut �tre plus rapide que l'assembleur. C'est vrai (Encore que je n'ai jamais eu la preuve montre en main ), mais c'est beaucoup plus rare que l'inverse.

[Hibernatus34]

rt15:
1. Le fait de mettre 2 fois plus de temps � alimenter un tableau est n�gligeable, le fait de pouvoir acc�der � ce tableau aussi efficacement qu'en C, une fois ce tableau aliment� est beaucoup plus important pour la plupart des algorithmes. Tu ne d�velopperas pas de programmes plus rapides avec des raisonnements aussi limit�s.

2. Certaines optimisations ne sont envisageables qu'� un certain niveau d'abstraction. Pour prendre un exemple qui te parlera je pense, imagine programmer tout Photoshop en assembleur en entrela�ant � la main les instructions pour b�n�ficier des fameuses optims du Pentium... Heureusement qu'il existe le compilo C capable de le faire � ta place.

L'exemple typique du C++ plus rapide que le C, c'est le qsort Vs. std::sort.

[screetch]

...

c'est gentil d'avoir retirer l'allocation dynamique du tableau pour favoriser le C.
en faisant l'allocation dynamique j'obtiens des resultats un peu plus proches deja.....

c'est deja pas facile de comparer du C et du C++, mais prendre une loupe pour regarder un element sans considerer un programme entier c'est tres contre-productif.

De mon experience, les deux ont la meme vitesse; le C++ perd par moment mais gagne par d'autres, et regarder individuellement c'est contre productif.

C'est comme mettre un exemple de 4 lignes en java qui va plus vite qu'en C++ sans regarder que eclipse qui est une vrai appli java cette fois, rame comme pas permis.

En plus, si on cherche bien, on trouve toujours des trucs mieux ou moins bien (plus ou moins rapide), ca n'a vraiment aucun interet...

[rt15]

Dommage que le code de photoshop ne soit pas libre.
D'apr�s le web, photoshop utilise ou utilisait pas mal SSE2.
SSE2 n'est pas utilisable efficacement en C, tout du moins pas sans une biblioth�que. Une biblioth�que �crite partiellement en assembleur.
L'alternative est d'utiliser directement l'assembleur.

A ma connaissance, aucun compilateur C ou C++ � l'heure actuelle n'est tout simplement capable d'optimiser des calculs efficacement en utilisant SSE. Car il faut une compr�hension profonde des dits calculs pour pouvoir les rendre parall�les et adapt�s � SSE. Les compilos peuvent utiliser SSE pour des "d�tails", fonctions built-in ou autre, mais ils ne vont pas transformer nos propre code de calcul en du jolie code machine exploitant bien SSE.

Photoshop est pr�cis�ment dans le cas o� une optimisation tr�s travaill�e a �t� mise en place. Car pour certaines partie du code, la performance est critique. Et ils ont fait quoi ? Ils ont fait du C++ ???? Non, ils ont certainement fait de l'assembleur, ou utiliser une biblioth�que faite en assembleur.

Pour optimiser, on se rapproche de la machine. C++ -> C. C -> ASM. On ne fait pas du haut niveau. �a marchera seulement quand les compilos seront plus intelligent que les hommes.

Merci pour qsort, vs sort, je vais voire �a.

[edit]
Mon code C++ ci-dessus n'est pas l� pour comparer les temps C vs C++, surtout que c'est que du C++ lol. C'est plus pour comparer reserver et le constructeur et se donner une id�e de ce que �a donne par rapport � un parcourt simple.

[screetch]

pour optimiser, on s'approche de la machine en C comme ne C++ comme en assembly, ca passe en premier lieu par une grosse optimisation du cache memoire qui est le bottleneck de toute application, surtout photoshop (on comprend bien que photoshop, c'est le processing d'image hein qu'il faut optimiser, pas l'interface utilisateur)

et on utilise SSE en C++ avec les "intrinsic", et on encapsule le tout dans des classes C++. Eh ouais, c'est comme ca qu'on fait, on ecrit pas de l'assembleur.

j'ai travaille sur d'autres codes ou la performance etait critique, il y avait pas une goutte d'assembleur, c'etait du C++ avec des intrinsic, et une tres tres grosse passe pour faire du traitement par batch (qui n'est as contraire au C++ mais la le C++ n'est pas forcement l'outil le plus adapte)

la meilleure preuve que photoshop ne doit pas contenir d'assembleur, c'est que sous visual studio en configuration 64bits on a plus le droit a l'assembleur.

[Hibernatus34]

Je suis d'accord rt15. Mais justement, si on peut combiner plusieurs langages c'est id�al.
L'assembleur tu l'utiliseras pour du code court et ex�cut� � haute fr�quence.
Le C++ permet de faire de l'assembleur inline, mais aussi du C inline d'une certaine mani�re.

Et je suis s�r qu'un d�veloppeur avis� sur les questions de bas niveau tel que toi, probablement adepte aussi de code explicite et simple, ferait un tr�s bon d�veloppeur C++, juste diff�rent des d�veloppeurs C++ qui aiment d�velopper des templates monstrueux, ou ceux qui veulent faire du Java en C++ etc. A chacun sa mani�re de profiter du C++, mais refuser en bloc le C++ n'a pas de sens.

PS. screetch : asm inline ou intrinsics, franchement quand tu vois la t�te d'un code bourr� d'intrinsics SSE2 c'est kif-kif
Et l'assembleur, m�me s'il est pas inline peut �tre link� � un projet C++, c'est pas tellement le probl�me (j'esp�re quand m�me que Microsoft va r�tablir l'inline )

[grim7reaper]

programmatiquement, le code philosophique de rt15 n'est pas equivalent a son pendant vector, le code equivalent est:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <vector>
 
#define VECTOR_SIZE 10000000
 
int main()
{
  std::vector<int> my_vector;
  my_vector.reserve(VECTOR_SIZE);
 
  for (int i = 0; i < VECTOR_SIZE; i++)
    my_vector.push_back(i);
 
  return 0;
}

Le v�ritable code C++ �quivalent au code de rt15 serait l�utilisation de std::array.
Son code C utilise un tableau statique, le std::vector a une s�mantique de tableau dynamique (avec ce que �a implique comme surco�t). Donc la comparaison est biais�e.
D�ailleurs, en utilisant std::array il n�y a pas de diff�rence de perf� entre le C et le C++ sur cet exemple (qui vaut ce qu�il vaut).

[Freem]

Je suis d'accord rt15. Mais justement, si on peut combiner plusieurs langages c'est id�al.
L'assembleur tu l'utiliseras pour du code court et ex�cut� � haute fr�quence.
Le C++ permet de faire de l'assembleur inline, mais aussi du C inline d'une certaine mani�re.

Et je suis s�r qu'un d�veloppeur avis� sur les questions de bas niveau tel que toi, probablement adepte aussi de code explicite et simple, ferait un tr�s bon d�veloppeur C++, juste diff�rent des d�veloppeurs C++ qui aiment d�velopper des templates monstrueux, ou ceux qui veulent faire du Java en C++ etc. A chacun sa mani�re de profiter du C++, mais refuser en bloc le C++ n'a pas de sens.

PS. screetch : asm inline ou intrinsics, franchement quand tu vois la t�te d'un code bourr� d'intrinsics SSE2 c'est kif-kif
Et l'assembleur, m�me s'il est pas inline peut �tre link� � un projet C++, c'est pas tellement le probl�me (j'esp�re quand m�me que Microsoft va r�tablir l'inline )

Je n'ai pas l'impression qu'il refuse le C++ en bloc.
Il argumentait juste sur le fait que j'ai dit que le C++ pourrait optimiser le code, nuance.
Le souci ayant �t� que, comme lui avec son exemple du vector, j'aie pris un (tr�s) mauvais exemple.

Personnellement, je pense que C et C++, bien utilis�s, sont aussi rapides l'un que l'autre (C �tant un sous-ensemble du langage C++, dans celui-ci).
0 diff�rence, vu qu'au final, tous les langages natifs sont �gaux face au code machine.
Le probl�me �tant que, pour moi, et je crois ne pas �tre le seul � le penser, bien utiliser le C est plus complexe que bien utiliser le C++.

Par exemple, dans les documents de GCC, il est pr�cis� qu'ils utilisent un garbage collector en C.
Bien.
Le probl�me des garbage collector, selon moi, c'est qu'ils ne lib�rent pas la m�moire aussit�t qu'elle n'est plus n�cessaire, contrairement � la RAII.
Sans compter que la m�canique interne du GC n�cessite s�rement des variables, qui vont �tre modifi�es par des calculs, ce qui consomme du temps processeur. Ensuite, le GC, si je ne suis pas dans le faux, va appeler la fonction qui permet de lib�rer l'objet en question.

Pourquoi avoir utilis� un GC?
Je pense que c'est parce que l'usage de la RAII est plus contraignant en C qu'en C++.
Niveau performance, il me semble �vident que la RAII soit plus efficace dans l'absolu qu'un GC (m�moire lib�r�e aussit�t => moins de swap et moins de changement de segment de donn�es. Dans l'absolu, am�lioration - faible pour les changement de segment - des perf. Et �conomie d'un m�canisme de GC, qui doit au final lib�rer quand m�me la m�moire, re am�lioration probable des perf).

Le fait est qu'en C++ aussi, on peut avoir un GC. Mais que la RAII, est aussi nettement plus simple � utiliser en C++ qu'en C: pas besoin de penser tout le temps a appeler un faux destructeur ou un faux constructeur.

De ce changement de langage, ce qui va en r�sulter, c'est donc, pour moi, un changement naturel et progressif dans l'architecture du logiciel, qui devrait pouvoir permettre des am�liorations de perf.

Effectivement, j'avais totalement tord en prenant le raccourcis C++ peut rendre le code plus rapide.
Mea culpa donc.

PS: je me permet tout de m�me de dire que l'exemple du vector m'a piqu� les yeux, mais c'est de bonne guerre, mon exemple ayant aussi �t� mauvais: dans la pratique, je n'utilise pas le changement de scope de fa�on aussi laide, mais plut�t des fonctions, le compilo me les mettant je pense inline selon les options de compilation et la situation.
C'�tait pour l'exemple, mais il �tait tr�s mauvais



Par rapport � votre d�bat "O(2n) est equivalent a O(n)" la r�ponse est tr�s simple.
En maths, il ne me semble pas que �quivalent soit �gal. Donc, O(2n) �quivaut toujours � O(n), mais O(2n) diff�re de O(n). Me semble m�me me souvenir que les matheux ont un symbole sp�cial pour l'�quivalence...
Mais bon, moi et les maths...

[screetch]

pourt les maths (et j'espere que ca clot le sujet car on comprend bien les intentions des uns et des autres)
la definition de O:

f est born�e, par le dessus, par g asymptotiquement
(� un facteur pr�s)

la remarque importante, c'est "a un facteur pres". donc O(2n) = O(n) = O(5000n)
mais dans la plupart des cas si on a equivalence des O pour deux algorithmes (tous les deux en O(n) on cherchera a savoir par quel facteur.