IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

double[] vs valarray


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    620
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Août 2006
    Messages : 620
    Par défaut double[] vs valarray
    Bonjour,

    J'ai une question relativement bas niveau : on a fait des comparaisons de performances entre des vlarray de double et des braves tableaux de double type C' pour constater des différences de perf d'un facteur 20, environ... Est-ce qu'il existe des fortes différences de performances entre différentes implémentations de valarray ? Le choix de cette classe est sa simplicité d'écriture pour les opérations vectorielles... Bref, sinon est-ce qu'il y a une raison fondamentale qui explique qu'une classe type valarry ou vector soit tellement plus lente ? Peut-on imaginer des solutions objets rapides, si tel est le cas ?

    Merci beaucoup pour toute suggestion !

    Marc

  2. #2
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 147
    Billets dans le blog
    4
    Par défaut
    Bonjour,

    je n'ai jamais utilisé le valarray, mais concernant le vector
    - il faut faire attention à sa taille, le remplir uniquement à coup de push_back ça entraîne de nombreux redimensionnements et copie de contenus
    - l'utilisation de vector::at sera plus lente que operator[] puisque at ajoute des vérifications
    - attention aux copies en paramètres de fonction => (const)&
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    620
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Août 2006
    Messages : 620
    Par défaut
    Bonjour Bousk,

    Merci pour ta réponse ! En l'occurence, il s'agit de manipuler des tableaux de dimensions fixes (3, typiquement) et de calculer des braves produits scalaires, un peu de calcul matriciel, etc, mais les valarray avait été retenus pour leur simplicité syntaxique. Du coup, la question qu'on se pose est : est-ce qu'on peut imaginer construire nous-mêmes une classe qui fasse le boulot sans une telle perte de performances ou bien vaut-il mieux revenir aux types de base du C ?

    Encore merci !

    Marc

  4. #4
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 026
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 026
    Par défaut
    Si valarray est un conteneur de la STL tu peux retrouver sa complexité pour différentes opérations.
    Toutes les implémentations de valarray ont alors la même complexité.

    Ensuite, pour les performances, comment avez-vous procédé pour les calculer? Une différence d'un facteur 20 me semble tout de même un peu gros.
    Une mauvaise compréhension d'un conteneur peut entraîné à une mauvaise utilisation et donc à des pertes de performances.
    Par exemple pour les vecteur, si on connait la taille du tableau, il faut réserver l'espace au début plutôt que de faire des push_back qui reallouera régulièrement plus d'espace comme l'a dit Bousk.


    Sinon, je ne sais pas exactement quelle sera l'utilisation finale, mais je pense que le gain de temps au niveau de la programmation est beaucoup plus bénéfique qu'un gain de temps au niveau de l'exécution dans votre cas.

  5. #5
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 147
    Billets dans le blog
    4
    Par défaut
    La question est : pourquoi tu aurais quelque chose de plus lent ?
    Une classe ce n'est jamais qu'un moyen d'aggréger les données entre elles. Une classe ne rendra pas l'application particulièrement plus rapide ou lente, ce sont avant tout les algos qui jouent sur ça.
    Que tu aies
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    struct Vector {
      float values[3];
      Vector(float, float, float);
      void add(float);
    };
    int main()
    {
     Vector v(0,1,2);
     v.add(4);
     return 1;
    }
    ou
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    void add(float*, float);
    int main()
    {
     float values[3] = {0, 1, 2};
     add(values, 4);
     return 1;
    }
    c'est identique.

    Quant à la performance, il faut bien se demander si elle est nécessaire et à quel point. Puis où aller la chercher.
    Est-ce que ça vaut vraiment le coup d'avoir un C-array ? et tous les problèmes qui peuvent en découdre.
    Pourquoi pas un std::vector correctement utilsé ?
    Ou un std::array si le C++11 est utilisable.

    edit: pour du calcul matriciel j'utilise glm que j'ai découverte pour openGL.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  6. #6
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Par défaut
    @[Hugo]
    Pour ce type de problématique, tu devrais passer par un lib existante (ou au moins voir comment elles sont implémentées)

    Une technique indispensable à utiliser dans ce cas, c'est les expressions template (cf Abrahams)

  7. #7
    Membre éclairé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    620
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Août 2006
    Messages : 620
    Par défaut
    Ouahou, merci à tous pour vos réponses :-)

    Ensuite, pour les performances, comment avez-vous procédé pour les calculer?
    A la hache : on a pris un cas et comparé le temps d'exécution avec les deux implémentations.

    Une différence d'un facteur 20 me semble tout de même un peu gros.
    Indeed

    Une mauvaise compréhension d'un conteneur peut entraîné à une mauvaise utilisation et donc à des pertes de performances.
    Par exemple pour les vecteur, si on connait la taille du tableau, il faut réserver l'espace au début plutôt que de faire des push_back qui reallouera régulièrement plus d'espace comme l'a dit Bousk.
    On est à taille fixe, ici, donc pas de problème de ce genre.

    Sinon, je ne sais pas exactement quelle sera l'utilisation finale, mais je pense que le gain de temps au niveau de la programmation est beaucoup plus bénéfique qu'un gain de temps au niveau de l'exécution dans votre cas.
    Euh, en fait on voudrait les deux : c'est pour faire du calcul massivement parallèle, à l'arrivée, et les perf sont vraiment importantes (voilà ce que ça donne quand des physiciens se mettent au C++, savent rien faire ces gens-là ;-) )

    Quant à la performance, il faut bien se demander si elle est nécessaire et à quel point. Puis où aller la chercher.
    Est-ce que ça vaut vraiment le coup d'avoir un C-array ? et tous les problèmes qui peuvent en découdre.
    Pourquoi pas un std::vector correctement utilsé ?
    Ou un std::array si le C++11 est utilisable.
    Merci pour ces pistes, on va méditer tout ça. C++11 pourrait être utilisable... Quel serait le bénéfice, ici ?

    edit: pour du calcul matriciel j'utilise glm que j'ai découverte pour openGL.
    Je vais aller regarder ça. Pour le moment, tout l'algèbre est géré par lapack et on voudrait limiter le nombre de bibliothèques au minimum.

    Pour ce type de problématique, tu devrais passer par un lib existante (ou au moins voir comment elles sont implémentées)

    Une technique indispensable à utiliser dans ce cas, c'est les expressions template (cf Abrahams)
    OK, merci, je vais aller gratter dans cette direction !

    Merci encore à tous !

    Marc

Discussions similaires

  1. Réponses: 4
    Dernier message: 12/09/2003, 11h38
  2. division de "double" par "0"
    Par ickis dans le forum C
    Réponses: 14
    Dernier message: 31/08/2003, 19h09
  3. abs pour un long double
    Par barthelv dans le forum C
    Réponses: 2
    Dernier message: 23/07/2003, 16h16
  4. String -> long double (_strlold ?)
    Par haypo dans le forum C
    Réponses: 7
    Dernier message: 25/07/2002, 20h22
  5. Réponses: 3
    Dernier message: 12/06/2002, 21h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo