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
Il existe pas mal de look and feel, il suffit de trouver celui qui te correspond.
Ca n'a rien à voir avec le language. Tu peux faire du beau en Java et du très moche en C++ ou autre.je trouve juste que les interfaces Java sont naturellement moches en comparaison, par exemple, à ce que proposera .NET .
Envoyé par kpouer
très mauvais exemple... il faut
1) détailler les options d'optimisations pour gcc (car la jvm ne se privera pas d'en faire via JIT)
2) éviter des fonctions récursives dans les langages classiques... ce n'est pas fait pour
En plus, il faut au moins lancer plusieurs fois la fonction car java met un certain temps à lancer la JVM (donc s'il faut 1sec pour lancer la JVM, forcement avec un appel à une fonction rapide, ça va pas le faire).très mauvais exemple... il faut
1) détailler les options d'optimisations pour gcc (car la jvm ne se privera pas d'en faire via JIT)
2) éviter des fonctions récursives dans les langages classiques... ce n'est pas fait pour
Je ne répondrai à aucune question technique en privé
d'après ce que je vois, le temps sys, qui est le temps CPU système utilisé, est 18 fois plus petit en C++ qu'avec Java...
La différence dans l'autre sens est sur le temps utilisateur...
Donc j'aurais tendance à dire que pour ce qui est de la fonctionalité, C++ est dans ce cas 18 fois plus rapide que Java....
(et que la différence en temps utilisateur dépend d'un problème de config)
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Mais l'interface d'OpenOffice.org n'est pas en Java...
Quand au LnF par défaut de Java, je suis tout à fait d'accord avec toi sur le fait qu'il est vraiment vieillot et dépassé, mais on peut très bien utilisé le LnF système qui utilisera l'apparence du système hôte (cf mes pièces jointes, avec d'un coté le look metal par défaut, et de l'autre le look système sur Windows XP).
L'utilisation du LnF système se fait via une simple ligne de code...
Tout à fait : cette optimisation à l'exécution est une des forces de Java.
Un exemple flagrant vient des méthodes virtuelles, qui seront traitées comme des méthodes non-virtuelles tant qu'aucune des classes chargées en mémoire ne redéfinit pas la méthode
Cela permet de bonne performance (en évitant le coût du polymorphisme lorsqu'il est inutile) tout en conservant les avantages de la POO (on peut toujours redéfinir la méthode, en "subissant" alors le coût du polymorphisme)
a++
Du tout c'est les temps que passe le processus dans les différents modes. Le temps sys c'est en mode kernel donc des appels bas niveau et le temps user beh c'est en mode utilisateur c'est ton programme sans les appels système.
d'après ce que je vois, le temps sys, qui est le temps CPU système utilisé, est 18 fois plus petit en C++ qu'avec Java...
La différence dans l'autre sens est sur le temps utilisateur...
Donc j'aurais tendance à dire que pour ce qui est de la fonctionalité, C++ est dans ce cas 18 fois plus rapide que Java....
(et que la différence en temps utilisateur dépend d'un problème de config)
Java tape plus dans le kernel bizarre en tout cas c'est une façon d'optimisée les choses bien qu'en mode kernel c'est quand même plus critique.
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Effectivement je n'ai fait aucune option d'optimisation particulière (désolé je ne suis pas un grand expert du c++ en général et de ses optimisations je l'avoue), et oui le compilateur JIT doit en faire partout de son coté.très mauvais exemple... il faut
1) détailler les options d'optimisations pour gcc (car la jvm ne se privera pas d'en faire via JIT)
2) éviter des fonctions récursives dans les langages classiques... ce n'est pas fait pour
J'ai trouvé des articles suggérant d'utiliser ces paramètres de compilation
g++ -O2 -fomit-frame-pointer -finline-functions -o fibo.x fibo.cpp
ce que j'ai fait et dans ce cas j'obtiens sensiblement les mêmes temps en java qu'en c++.
Du coup ce qui me vient à l'esprit est qu'en compilant de manière basique java a des chances d'être plus rapide que le c++ dans certains domaines.
De plus ces options de compilations ne sont pas très intuitives et je pense que le type qui les a trouvé a du chercher et faire pas mal de tests pour choisir les bonnes.
Dans un véritable projet, est ce que les développeurs vont changer les options de compilations de chacun de leurs .cpp en fonction des cas pour en obtenir le meilleur (car ils ne peuvent pas les mettre partout je pense), et quelle perte de temps non ?
Dans mon idée mais je me trompe peut etre, les gens vont compiler normalement, et n'ayant pas d'élément comparatif vont se satisfaire du résultat obtenu. Qu'en dites vous ?
Bien sûr que l'on cherche les meilleures options de compilation pour un vrai projet (industriel en tous cas) !!!
C'est en tous cas ce qui se fait dans les projets "sérieux"...
(ce qui effectivement n'a pas l'air d'être le cas de la très grande majorité des applications Web-based, et d'un grand nombre d'applis commerciales mais non industrielles de ces temps-ci ...)
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
j'en pense qu'effectivement, tu n'as pas du faire beaucoup de projets C/C++ dans ta vie, ni même t'intéresser à recompiler certains utilitaires depuis leurs sources...
je laisse les experts C/C++ détailler comment cela se passe dans un vrai projet industriel "sérieux"
j'en pense qu'effectivement, tu n'as pas du faire beaucoup de projets C/C++ dans ta vie, ni même t'intéresser à recompiler certains utilitaires depuis leurs sources...
je laisse les experts C/C++ détailler comment cela se passe dans un vrai projet industriel "sérieux"
Je confirme et je viens ici me cultiver, voir ce qui se fait en c++ dans la nature
Sans être un expert C/C++, je peux juste dire que si j'ai besoin de réelles performances aujourd'hui dans une application, j'utilise CUDA et bien OpenCL.j'en pense qu'effectivement, tu n'as pas du faire beaucoup de projets C/C++ dans ta vie, ni même t'intéresser à recompiler certains utilitaires depuis leurs sources...
je laisse les experts C/C++ détailler comment cela se passe dans un vrai projet industriel "sérieux"
Globalement, je pense que ça apporte beaucoup plus que les options de compilation, même si celles-ci ont une grande importance en terme de performances.
D'ailleurs, par simple curiosité et éventuellement pour de futurs projets, j'aimerais savoir quelles sont les possibilités en terme de GPGPU du côté Java ? Ce n'est pas pour lancer un troll, mais juste parce qu'apparemment il y a beaucoup d'experts en la matière sur ce POST.
"Il est plus facile de décomposer un problème en ses éléments, forcément plus simples, que de le traiter en sa totalité." (R. Descartes)
Freelance iOS
il y a des bindings java opengl (jogl, ljgwl).
Là encore des bencharmarks (sur l'aspect GPGPU cela devrait se faire) restent encore ce qui est le plus accessibles dans ce genre de débat. Cependant on va se confronter au fait qu'en c++ il n'y a rien en GUI en standard alors qu'en Java oui.
Je pense qu'est c'est plus lié à une question de coûts parce qu'en voulant atteindre un objectif de performances en terme de rapidité ou d'occupation mémoire ou autre on devrait se débrouiller avec ce qui existe sur le marché, je connais surtout Qt et Swing.
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
je préciserai qu'avec des programmes C, en général -O2 comme option est très satisfaisante, -O3 si on peut (par exemple impossible avec du code MPEG ou des sockets asynchrones).
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Si on compare les calculs GPU en comparaison aux calculs CPU, il n'y a pas photo : le GPU est généralement au moins 2x plus rapide. (cf. TMPGEnc avec CUDA, Adobe CS4 avec CUDA et les promesses de MacOS X SnowLeopard avec OpenCL)
Ce qui m'intéresse, c'est de savoir dans quelle mesure on peut utiliser les technologies GPGPU en Java.
"Il est plus facile de décomposer un problème en ses éléments, forcément plus simples, que de le traiter en sa totalité." (R. Descartes)
Freelance iOS
Juste pour informations avant que cela ne dévie sur des problématiques de jeux-vidéo, il y a une discussion : Le langage est-il adapté pour les jeux-vidéos ici : http://www.developpez.net/forums/d55...te-jeux-video/
Je ne répondrai à aucune question technique en privé
-O2 -fomit-frame-pointer -finline-functions
Ce sont les options d'optimisation classiques en release sur gcc. A peu près tous les programmes les utilisent.
Le test de Fibonacci est fortement récursif. Java, et plus généralement les langages sur JVM et plus encore les langages fonctionnels, est assez doué pour ça (le Computer Language Shootout est un test relativement réaliste pour comparer les perfs de langages). En gros, ils manipulent parfaitement la pile. Or dans Fibonacci, TOUT est fait sur la pile. Pas étonnant dès lors que les perfs soient identiques que C++ sur ce test (d'ailleurs en testant ta routine sur un nombre suffisamment grand, tu devrais te prendre une StackOverflowException). Le problème est que dans les langages impératifs comme Java/C++, à part dans les collections implémentant des arbres équilibrés, on n'utilise pas si souvent que ça les algos récursifs.
Donc ton test n'a qu'une valeur assez limitée. Ceci étant, en faisant attention et en gardant à l'esprit ce que fait la JVM derrière son code, notamment en matière de gestion mémoire, il est possible d'obtenir des performances honorables en Java. Le Computer Language Shootout montre souvent un rapport 1/2 à 1/3 par rapport au C++. Et les programmes C++ sont plus souvent des implémentations très fortement optimisés plutôt que des implémentations basiques. La version #5 C++, non multithread mais qui utilise un pool d'objets Boost, est ~1,5x plus rapide que la version Java 6 (16 s contre 26s). Mais dans la simulation du problème à N corps, le Java est plus rapide que le C++ ! Dans ces tests, je dirais que le grand avantage de C++ / rapport à Java en ce qui concerne les perfs, c'est les possibilités offertes qu'offre C++ pour l'optimisation. Java offre peu ou prou de lattitude de ce coté-là, mais c'est un choix de design conscient de la part des auteurs.
Sauf que Java n'optimise pas la récursion terminale, contrairement à beaucoup de compilateurs. Il faut donc faire attention avec ça (évidemment, sur Fibonacci, ça ne se remarque pas). Pour le reste du message, je suis d'accord.
J'ajouterai aussi que le test en plus d'être récursif a un temps d'exécution exponentiel, alors qu'avec une implémentation non récursive par une boucle est incomparablement plus rapide que ce soit en java comme en c++ (plusieurs secondes dans les 2 langages pour faire un fibonacci de 40 alors qu'avec un algo avec une simple boucle ne prend que quelque millisecondes dans les 2 langages pour un fibonacci de 1000, a tel point qu'il devient difficile de comparer les 2 car augmenter le paramètre ne change presque plus rien)
Ou équivalent récursif terminal. Mais ce que tu dis n'est pas intéressant : Evidemment qu'avec une boucle en O(n) c'est plus rapide qu'avec un algorithme exponentiel (qu'il soit récursif ou non), c'est d'ailleurs nettement plus lent que les meilleurs algorithmes récursifs qui sont sublinéaires.
Ce benchmark est utilisé pour tester l'efficacité de la récursion classique dans un langage donné, pas pour vérifier à quelle vitesse un langage peut calculer Fibonacci ! C'est comme si on te montrait un marathon et tu demandais pourquoi les coureurs n'utilisaient pas plutôt une voiture...
--
Jedaï
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager