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

Débats sur le développement - Le Best Of Discussion :

[Débat] C++ vs Java


Sujet :

Débats sur le développement - Le Best Of

  1. #641
    Membre habitué Avatar de 5:35pm
    Profil pro
    Inscrit en
    avril 2006
    Messages
    201
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 201
    Points : 144
    Points
    144
    Par défaut
    Citation Envoyé par leopard261 Voir le message
    java est aussi rapide que c++
    elle est bien bonne celle la

  2. #642
    Membre habitué Avatar de 5:35pm
    Profil pro
    Inscrit en
    avril 2006
    Messages
    201
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 201
    Points : 144
    Points
    144
    Par défaut
    voici les resultats d'un benchmark (serieux AMHA) de juin 2007:



    resultats cumulatif:



    source

  3. #643
    Membre averti
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    361
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2006
    Messages : 361
    Points : 403
    Points
    403
    Par défaut
    Encore un test ridicule.

    Since Java compiler does not have any settings that could affect performance
    Le compilateur non ... le GC oui...

    De plus, il a repris les même conditions que le test précédent (qu'il a modifié): le temps de lancement de la JVM est prit en compte. Quel est l'intérêt de prendre ce temps en compte ? Une JVM en mode serveur, on la redémarre pas toutes les 5min...


    De plus, l'update 2 de Java est sortie, il faut donc refaire le test.

  4. #644
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 019
    Points
    3 019
    Par défaut
    Citation Envoyé par nicØB Voir le message
    Encore un test ridicule.
    Le test n'est pas ridicule, il montre qu'indéniablement, pour les calculs, C/C++ est plus performant. Et même que globalement, pour un peu toute sorte de choses, C++ est plus performant... si on travaille au niveau de la mémoire, c'est normal...

    Si on met de côté les quelques petites erreurs lors des tests (par exemple le test sur un StringBuffer pour la concaténation, au lieu d'un StringBuilder, bien plus performant, environ 4x plus rapide sur un petit test), et comme tu le dis le temps de lancement de la VM (ça c'est énorme par rapport à l'exécution du programme), on remarque que tout au plus, C++ n'est que 2x plus rapide que java, et pour des calculs purs... On n'est pas à un facteur 20 ni 10...

    Pour une application réelle, je pense que ce facteur tend vers 1... même si je pense qu'en benchmark C++ a (encore) un rien d'avance, Java a d'autres avantages...

  5. #645
    Membre averti
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    361
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2006
    Messages : 361
    Points : 403
    Points
    403
    Par défaut
    Oui c'est ridicule car fait par un gars loin d'être impartiable car il n'a pas connaissances requises pour l'être (ex avec la concaténation de string).
    Le C/C++ est plus rapide pour les calculs comme tu le dis, mais ça n'empeche pas qu'il faut faire les choses correctement.

    Quand tu vois que la JVM en mode serveur est souvent moins rapide que celle en mode client, on se doute bien que le temps de lancement de la JVM est loin d'être négligeable...
    Il me semble c'est dans les 10% de temps supplémentaire pour lancer la jvm en serveur plutot qu'en client, mais pour avoir du code plus performant. Si tu regardes bien le graphe, par moment la JVM serveur est vraiment à la traine: temps négligeable ? Je ne pense pas.

  6. #646
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 526
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 526
    Points : 29 983
    Points
    29 983
    Par défaut
    Citation Envoyé par la sagesse populaire
    Ne jamais faire confiance à un benchmark que l'on n'a pas truqué soi-même
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #647
    Membre averti
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    361
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2006
    Messages : 361
    Points : 403
    Points
    403
    Par défaut
    Oui c'est un peu ça.

  8. #648
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 273
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 273
    Points : 10 827
    Points
    10 827
    Par défaut
    Et en plus, le C++ est parti avec un handicap (GCC en termes de perf on connait bien mieux).

    Bref encore un bench qui a autant d'intérêt qu'un autre bench.


    Plus sérieux, je suis tombé sur cet article d'il y a quelques mois. Stroustrup y parle du C++ depuis sa génèse jusqu'au C++0x. En lui-même l'article est intéressant.
    Relativement au sujet de ce troll interminable, il y a une mini comparaison au Java qui traite aussi d'aspects non évoqués dans ces 40 pages si je me souviens bien.

    Bref, c'est par là, je vous laisse vous faire votre propre opinion, bonne lecture.
    http://www.research.att.com/~bs/hopl-almost-final.pdf
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  9. #649
    Membre habitué Avatar de 5:35pm
    Profil pro
    Inscrit en
    avril 2006
    Messages
    201
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 201
    Points : 144
    Points
    144
    Par défaut
    permettez moi de douter de bonne foie de ceux qui contestent la tendance de ce bench

    je ne me refererais qu'a cette simple verite:
    un langage de haut niveau ne peut pas etre plus performant qu'un langage de bas niveau.

  10. #650
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 019
    Points
    3 019
    Par défaut
    Citation Envoyé par 5:35pm Voir le message
    permettez moi de douter de bonne foie de ceux qui contestent la tendance de ce bench

    je ne me refererais qu'a cette simple verite:
    Cette phrase n'est pas forcément vraie... Dans un langage de haut niveau, tu peux faire des optimisations globales qu'il n'est pas possible de faire si tu programmes directement en bas niveau. Je prends l'exemple du C, ton programme que tu écris en C et que tu compiles avec l'option -O3 sera plus performant que le même programme que tu "essaierais" d'écrire directement en asm.

  11. #651
    Membre habitué Avatar de 5:35pm
    Profil pro
    Inscrit en
    avril 2006
    Messages
    201
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 201
    Points : 144
    Points
    144
    Par défaut
    oui, un bon compilo vaudra toujours mieux que de l'asm a la main, car ce n'est pas un langage permettant aux hommes de concevoir des algorythmes, meme simple.
    affirmer que java est (meme presque) aussi rapide, est une attitude negationiste.

    et donc en Java quels sont les optimisations? (mis a part le GC)

  12. #652
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 019
    Points
    3 019
    Par défaut
    Citation Envoyé par 5:35pm Voir le message
    et donc en Java quels sont les optimisations? (mis a part le GC)
    Il y a des optimisations non faisables à la compilation que java peut faire à l'exécution, comme l'inlining dynamique (qui dépend du contexte), et d'autres choses dans le même genre (je ne m'étendrais pas sur ce sujet, je n'y connais rien, mais ça existe ^^). Un petit détail sur Swing par exemple, plusieurs modifications successives d'un composant peuvent résulter en 1 seul recalcul de l'affichage... (bon, si on peut appeler ça de l'optimisation, ça n'a rien à voir avec le langage, c plutôt un détail de Swing).

    Inversement, il y a des optimisations que C++ peut faire à la compilation qu'il est inenvisageable de faire à l'exécution...

  13. #653
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 322
    Points : 18 478
    Points
    18 478
    Par défaut
    Citation Envoyé par ®om Voir le message
    Je prends l'exemple du C, ton programme que tu écris en C et que tu compiles avec l'option -O3 sera plus performant que le même programme que tu "essaierais" d'écrire directement en asm.


    ce n'est pas toujours vrai... surtout s'il existe une instruction asm qui fait le boulot d'un seul coup, mais qui est tellement complexe à utiliser que les compilateurs ne s'en servent pas (il faut savoir qu'un compilateur n'utilise qu'un sous-ensemble de l'asm possible )

    mais étant un fan des compilateurs et des optimisations de code, je dirais que cela arrive, mais que pour la majorité des cas ton affirmation est vraie
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  14. #654
    LLB
    LLB est déconnecté
    Membre expérimenté
    Inscrit en
    mars 2002
    Messages
    967
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 967
    Points : 1 339
    Points
    1 339
    Par défaut
    Citation Envoyé par 5:35pm Voir le message
    Un langage de haut niveau ne peut pas etre plus performant qu'un langage de bas niveau.
    Ce qu'il ne faut pas lire... Tu as jeté cette phrase juste pour nourrir le troll, ou tu la crois vraiment ?

    D'une part, tu peux trouver des milliers de contre-exemples, sur lesquels un langage de haut-niveau sera plus rapide qu'un langage de bas-niveau (abus de langage : on compare plutôt des compilateurs).

    D'autre part, grand nombre d'optimisations sont bien plus simples à effectuer sur un langage de haut-niveau, puisqu'il a "plus de recul". Typiquement, un langage fonctionnel peut effectuer certaines optimisations qu'un compilateur C pourra très difficilement effectuer. Par exemple, les compilateurs C ou C++ ne peuvent pas effectuer certaines optimisations, entre autres à cause des pointeurs et des effets de bords qui peuvent survenir n'importe quand. Dans un langage de haut-niveau, un compilateur a plus de connaissances sur le code que dans un langage de bas-niveau, et peut potentiellement optimiser
    plus.

    Par ailleurs, les langages bas-niveau étant plus verbeux, et les développeurs étant fainéants, il est fréquent de voir un développeur C utiliser une structure de données plus simple, juste par flemme. Utiliser un arbre, une table de hachage ou une map est bien plus simple dans un langage de haut-niveau qu'en C. De fait, il est fréquent de voir des dévelppeurs C utiliser un tableau là où une autre structure serait plus performante.

    Enfin, il existe des cas où une gestion automatique de la mémoire est plus performante que des appels à free et à malloc (ou new et delete).

    Citation Envoyé par 5:35pm
    un bon compilo vaudra toujours mieux que de l'asm a la main
    Puisque tu reconnais ça (avec un bémol, signalé par Gorgonite), pourquoi ne pas reconnaitre que, de la même façon, un langage de haut-niveau peut effectuer des optimisations qu'un langage de bas-niveau pourra difficilement faire ?

    Entre autres :
    Citation Envoyé par Wikipedia
    Because of the high level nature by which data structures are specified in functional languages such as Haskell, it is possible to combine several recursive functions which produce and consume some temporary data structure so that the data is passed directly without wasting time constructing the data structure.

  15. #655
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2006
    Messages
    1 335
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 1 335
    Points : 1 274
    Points
    1 274
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Bref, c'est par là, je vous laisse vous faire votre propre opinion, bonne lecture.
    http://www.research.att.com/~bs/hopl-almost-final.pdf
    vraiment super intéressant ! Merci

  16. #656
    Membre habitué Avatar de 5:35pm
    Profil pro
    Inscrit en
    avril 2006
    Messages
    201
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 201
    Points : 144
    Points
    144
    Par défaut
    Ce qu'il ne faut pas lire... Tu as jeté cette phrase juste pour nourrir le troll, ou tu la crois vraiment ?
    les deux

    les faits n'ont-ils pas prouve qu'un language de bas niveau est plus rapide que son equivallent de haut niveau?

    asm > c > c++ > Java/C# > python

    cette comparaison te parait fausse ?

    il est plus efficace de gerer la memoire sois meme que de laisser faire par un garbage collector; comme il est plus efficace d'optimiser sois meme un algorythme que de le laisser faire par un compilo; pour la simple et bonne raison qu'un humain sait pourquoi un algorythme est tel qu'il est et un compilo, bien qu'il puisse comprendre un algorythme, il ne saura jamais pourquoi. l'intelligence artificiel VS l'intelligence humaine, qu'est-ce qui les differencient? la machine "pense" plus vite, et sans erreur, mais ne peut raisonner au dela des notions qui lui ont ete inculque. L'homme pense plus lentement, peut faire des fautes, mais peut tout remettre en question, et peut ruser, il a l'immagination, il comprend le pourquoi (enfin la plupart du temp ).

    comment la machine peut elle optimiser en profondeur si elle comprend que le comment, et pas le pourquoi ?

  17. #657
    LLB
    LLB est déconnecté
    Membre expérimenté
    Inscrit en
    mars 2002
    Messages
    967
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 967
    Points : 1 339
    Points
    1 339
    Par défaut
    Citation Envoyé par 5:35pm Voir le message
    les faits n'ont-ils pas prouve qu'un language de bas niveau est plus rapide que son equivallent de haut niveau?

    asm > c > c++ > Java/C# > python

    cette comparaison te parait fausse ?
    Trop simpliste.

    En moyenne, du code C compilé avec un bon compilateur sera plus rapide que du code assembleur, sur les projets de taille raisonnable, sauf à y passer des heures à optimiser.

    De même la différence d'efficacité entre le C et le C++, puis entre C++ et C# tend à se réduire (voire s'inverser) quand on sort des cas d'école.

    Il existe même des exemples où :
    - Java peut être plus rapide que C++
    - Caml peut être plus rapide que C++
    - Lisp peut être aussi rapide que le C (cf http://www.lrde.epita.fr/dload/paper...a.06.imecs.pdf)
    - et tant d'autres !

    il est plus efficace de gerer la memoire sois meme que de laisser faire par un garbage collector;
    Pas toujours !
    http://en.wikipedia.org/wiki/Garbage...e_implications
    Et ce papier d'Andrew Appel (qui date un peu) :
    http://citeseer.ist.psu.edu/appel87garbage.html

    comme il est plus efficace d'optimiser sois meme un algorythme que de le laisser faire par un compilo;
    Euh, oui. Les compilateurs ne réécrivent pas (ou, pas encore ) les algos. Mais, en haut-niveau, les algorithmes courants sont souvent déjà implémentés. Et les algos des bibliothèques standards sont souvent très performants (souvent plus que si un utilisateur lambda le recodait), même s'ils peuvent parfois souffrir un peu de leur généricité (il peut être plus efficace de recoder une structure de données spécifique, plutôt que d'utiliser celle de la STL).

    pour la simple et bonne raison qu'un humain sait pourquoi un algorythme est tel qu'il est et un compilo, bien qu'il puisse comprendre un algorythme, il ne saura jamais pourquoi.
    Oui. Mais plus le compilateur a d'information (connaitre ce qui est constant, connaitre les fonctions qui font des effets de bords, etc.), plus il peut optimiser. Nombre d'optimisations sont plus faciles à implémenter sur un AST (arbre de syntaxe abstraite) de haut-niveau, que sur la représentation de bas-niveau.

    comment la machine peut elle optimiser en profondeur si elle comprend que le comment, et pas le pourquoi ?
    On ne demande pas à la machine d'optimiser les algos (encore que, parfois, elle arrive à réduire leur complexité). D'ailleurs, que tu l'écrives en C ou en Python, tu dois écrire ton algo. Le problème reste le même : c'est avant tout au programmeur de réfléchir et d'écrire correctement son algorithme (avec un i, par pitié !).

    Au cas où je n'ai pas été clair, mon propos est :
    un langage de haut-niveau n'est pas nécessairement plus lent qu'un langage de bas niveau, en moyenne. Et surtout avec les progrès des compilateurs, ils peuvent devenir (ou deviendront) plus performants, sur les projets de taille raisonnable.

    Et pour finir, comme tu t'amuses à comparer l'IA avec le cerveau humain, regarde ce qu'il passe. Dans pleins de problèmes, pourtant parfois considérés comme intelligent, l'ordinateur a dépassé l'humain (certains jeux : dames, échecs, othello, puissance 4...). Dans d'autres cas, ça n'est pas encore arrivé (go...), mais l'IA progresse plus vite que le cerveau humain. Pourquoi les problématiques d'optimisations ne pourraient-elles pas être résolues efficacement par la machine ?

    Bien sûr, ici, l'homme pourra toujours réussir à optimiser plus ou autant un code que la machine, mais à quel prix ? S'il était nécessaire de passer un an, à optimiser le code assembleur à la main, pour dépasser le résultat du compilateur, on pourrait alors raisonnablement penser que la machine se débrouille mieux, non ?

    PS : cette discussion est un peu hors-sujet, en fait. Peut-être serait-il préférable de continuer ailleurs (ou de déplacer la conversation) ?

  18. #658
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 062
    Points : 15 892
    Points
    15 892
    Par défaut
    1. Oui, du code compilé C/C++ est souvent plus rapide que du code compilé (JIT) Java.

    On peut toujours trouver des cas ou c'est l'inverse, mais inutile de se voiler la face. La force de Java est ailleurs que dans la performance pure.


    2. Si une partie de votre programme java est trop lente, recodez cette partie en C/C++ et appelez la depuis Java (JNI).

    C'est une grande force de Java. JNI est simple et tres puissant, pourquoi s'en priver ?


    3. Ca fait longtemps que les précompilateurs, les compilateurs et les processeurs optimisent le code.

    Vous ne battrez presque jamais un bon algo d'optimisation avec vos petites meninges. N'essayez pas d'optimiser vous meme en ecrivant ce que vous pensez etre une "amelioration" (souvent synonyme de ca-tient-tout-sur-une-ligne). Ecrivez du code clair et lisible, et laissez faire le compilo.

    Le code suivant:
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    int main(int argc, char** argv) {
      int MAX=10;
      int p, i;
      p=0;
      for (i=0 ; i<MAX ; ++i)
      {
        p+=2;
      }
      return p;
    }

    a été optimise automatiquement ainsi:
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    int main(int argc, char** argv) {
      return 20;
    }

    auriez-vous fait mieux ?

    (source: ici meme)
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  19. #659
    Membre actif Avatar de Kujara
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    262
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : décembre 2006
    Messages : 262
    Points : 296
    Points
    296
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    Vous ne battrez presque jamais un bon algo d'optimisation avec vos petites meninges.
    Ouch, tellement faux ...

    2 façons d'optimiser, algorithme, et implementation de l'algorithme.

    Pour l'algo lui meme, le compilateur ne fait rien.
    Pour l'implementation, le compilateur n'optimise que sur du court terme ( sur la longeur d'une fonction, par exemple).

    Pour n'importe que bout de code plus long que ton exemple, rien ne peut remplacer un cerveau humain .....

  20. #660
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    juin 2003
    Messages
    449
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : Afghanistan

    Informations forums :
    Inscription : juin 2003
    Messages : 449
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    Oui je suis d'accord pour l'instant les algo d'optimisations ne permettent pas de remplacer le cervaux humain mais je un jours ca sera possible ...

    sinon je trouve que l'absence de classe anonyme ou de closure en C++ en font un langage vieux et barbare pour l'écriture de code propre et concis.
    un langage qui n'implemente a minimun la notion de closure (classe anonyme ) est inférieur a java .

Discussions similaires

  1. [Débat] Technologie .NET vs JAVA
    Par neo.51 dans le forum Débats sur le développement - Le Best Of
    Réponses: 1047
    Dernier message: 14/01/2019, 17h15
  2. [Débat] .NET vs JAVA/J2EE
    Par tssi555 dans le forum VB.NET
    Réponses: 5
    Dernier message: 10/12/2008, 08h54

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