Discussion :

[grishka]

attendez, attendez, STOP.
On s'engage sur le terrain de l'optimisation des performances qui est le seul avantage du c++. Il est possible de faire tourner ton programme de calcul de surface plus rapidement que l'original en
-arretant de penser qu'on peut faire de l'allocation statique sur la pile en java : il n'y a pas de pile. D'ou l'utilité d'un cache. Donc gregy tu as raison, même si je ne vois pas pourquoi tu gardes les valeurs initiales...
++gib, en quoi utiliser un pool (ou cache) est bas-niveau? ou même une bidouille. Au contraire c'est une gestion de mémoire haut-niveau car utilisant un conteneur d'objets pré-instanciés (et pas uniquement des références). Pas étonnant que programmer en haut niveau releve de la bidouille dans ton cas Donc je le redis :
A partir du moment ou le java ne dispose pas d'allocation statique sur la pile comme le C++, la gestion de mémoire par cache accroit de 300%
la vitesse générale de l'appli. ET CE N'EST PAS DU BAS-NIVEAU
-en utilisant ArrayList et les méthodes get (gain de 100% pour le parcours par rapport à vector). Donc gregy, pas besoin de transformer en tableau car l'accès par get est optimisé par la jvm et est remplacé inline (comme toute les méthodes get qui ne font que retourner...) comme en C++.

Pas d'autre moyen de lire des données dans un fichier texte de structure simple ?

hmmm, c'est bon ++gib on passe souvent par StreamTokenizer voire StringTokenizer. C'est lourd certes, mais on peut faire plus de chose qu'un fscanf() du C...


Le but du débat n'est plus de prouver que c++ est plus performant que java pour le calcul, ca c'est certain (c'est ce que j'ai toujours dit, et je l'ai prouvé avec mes résultats à Scimark2), mais que NON, JAVA N'EST PAS 10 FOIS PLUS LENT QUE C++. En utilisant les bibliothèques java, on peut très bien se contenter d'une vitesse de calcul au pire 50% de celle du c++ pour des petits problèmes et COMPARABLES pour une taille des données importante (voir le test scimark). Ce sont des expert en calcul numérique qui ont fait les tests, et excuses-moi ++gib, ils font un peu plus que du calcul de surface. (FFT, decomposition LU, ...)

Si le langage JAVA est managé, ce n'est pas pour embêter les programmeurs, mais cela s'inscrit dans la logique d'application sécurisée. vous ne croyez quand même pas qu'avec tout ca, ca va être plus rapide que le c++?

Pour une application web distribuée, la plateforme java n'a aucun égal en performance. Vous croyez sérieusement pouvoir faire du distribué avec CORBA en c++ et être aussi performant que J2EE???, ou du c++ avec .NET ? ha ha ha. Des composants COM en c++? pfoua!
même les applis windows, il ne vaut mieux plus les faire en c++ ni avec MFC, ni avec la bibli de borland, mais plutot en DELPHI ou JAVA. (non pas VB quand mêmeuuuu...)


Nous sommes dans l'ere du service, du RAD, où les performances sont
importantes bien sur , mais sont SECONDAIRES.

Et puis les DirectBuffer sont un peu plus haut-niveau que les pointeurs avec leur arithmétique. Quant à la sécurité, il faudrait attendre les retour d'expérience.

Algo :

SI vous connaissez le C++ à 100%, la STL à 100%, que vous rêvez de performances toute la journée ET que votre appli n'est pas une appli de gestion, une appli distribuée d'entreprise, ALORS choisir C++ (si possible avec un compilo spécialisé intel C++ pour le SIMD)
SINON
SI vous programmez pour windows uniquement et que le java ca vous dit pas ALORS choisir DELPHI
SINON choisir JAVA

[++gib]

Non il vaut mieux lire directement le rapport officiel :
http://java.sun.com/pr/1999/12/pr991207-08.html

La voix de son maitre.

a bon, en c++ tu peux tout convertir en n'importe quoi. (un pointeur en entier, une référence en void *, des constantes en variables). Sans aucun warning!

Voila que tu remets ça !! Montre donc un code qui le fait.

byte i=0;
i = i+3L ne marche pas car le compilo voit que le calcul doit se faire en long sans perte de précision, mais l'affectation risque de provoquer une perte de précision. d'ou erreur.

Merci, j'avais compris le raisonnement du compilateur.
Si tu m'avais lu au lieu d'appliquer des "regles" tu aurais compris que ce raisonnement
est une anerie carabinée car
1) Le fait d'affecter un long a un int ne provoque pas forcement un débordement.
2) le fait d'affecter un int ne prouve pas que ce int est exact, puisqu'un débordement
a pu avoir lieu lors de son calcul. Ex
int i = 1 + Integer.MAX_VALUE ;
Cette politiique n'améliore donc pas la sécurité.
Relis avec soin mon intervention.

byte i=0;i+=128L; ca marche car on incrémente par une constante vue comme un octet avec la formule : (constante modulo 128) - 128. C'est circulaire si tu veux.

Très marrant, le coup du modulo 128. Sur un octet, ça s'appelle un débordement.

si
i = i + 128L ;
n'est pas sémantiquement equivalent à
i += 128L ;
ça signifie quoi ?

Le problème c'est que la première forme est refusée au nom du "dogme"
alors que la seconde forme est accepée, car la politique de gestion des
affectations de Java est incohérente.

Regle : les affectations de variables doivent être cohérentes en type. Les incrémentations, et autres opérations *=, /=, sont calculées au modulo prés. Comme ce que j'ai montré dans mon précédent exemple, pas de conversion implicite par affectation, donc plus strict que c++.

Encore la "règle"!!

Au lieu d'avoir un comportement d'ayatollah sert toi un peu de ta tête :
ce qui provoque les débordements, c'est l'ensemble des calculs que tu fais sur une donnée.
Si tu additionnes MAX_INT + MAX_INT , ça ne tient pas dans un int et le débordement
il est là !! Tu auras beau générer un résultat int et affecter ça à un int,
le résultat n'en sera pas moins faux !!
Ceci montre que ta "règle" ne sert à rien, sinon entretenir le client dans un
douce quiétude devant ce langage qui prend soin de lui.

Au même titre que l'addition de cet exemple, une affectation peut provoquer un débordement, mais ni plus, ni moins. l'affectation est un opérateur comme les autres.

Je trouve incroyable que tu prétendes qu'il est normal que += "admette les débordements"
avec ce que tu préconises pour = .
+= provoque bien une affectation non ?

J'ai non seulement démontré que la "règle" était inefficace, mais en plus que Java
n'était même pas fichu de l'appliquer de façon cohérente.
Ceci me renforce dans l'idée que cette rêgle est boîteuse.

C'est simplement une règle du compilo, ou est l'erreur la? Ca permet de calculer simplement des offsets dans un tableau en faisant des additions avec un modulo effectué gratuitement plutot que "le reste de la division entière de ....blablabla".

Bravo !
Voila un belle bidouille pour réaliser un adressage circulaire.
A condition que la taille du tableau soit un multiple de 2 puissance 8, 16 ou 32.
Je me rappelle avoir écrit en assembleur un compilateur FORTH pour Z80 ou
la pile était adressé avec un registe 8 bits.
Ainsi, pas de de risque qu'elle bave sur le reste du code grace à un adressage modulo 256 gratos. C'était à une autre époque.

L'approche Java des véritables problèmes est toujours la même :
circulez, rien à voir.

Simplicité => efficacité

Pas forcément. Trop simple et c'est la galère.
En outre, ce n'est pas en se mettant la tête dans le sable qu'on supprime les
vrais problèmes.

Le c++ permet de gérer plus finement les conversions (et offre la possibilité de faire n'importe quoi), d'ou une attention particulière de la part du programmeur.

Et bien oui, osons le dire : programmeur, c'est un métier.
Ca demande de l'attention, comme pilote d'avion ou chauffeur d'autobus.
Si tu crois que les bidouilleurs attendent les conversions pour faire n'importe quoi,
consulte mon post précédent. Tu verras qu'on peut faire du gratiné en Java.

Généralement, les simplifications proposées sont difficilement maintenable;

Et bien oui, si c'est la cas, c'est qu'on à trop simplifié. CQFD.

[++gib]

Merci ++gib, tu m'as ouvert les yeux, Java est un mauvais langage, une pâle copie du C++... Le tout puissant C++ a definitivement remporté la partie, d'ailleur je vais desuite corrigé mon pseudo :
++Clément Cunin
Incrémenté de la sorte, je cours préché la bonne parole :

- La programmation en environnement protégé n'apporte rien, La stabilité des application Java basé sur cet environnement protégé n'est que du vent.
- Les milliers de programmeurs Java sont tous des cons qui n'y comprenne rien.
- La technologie dotNet qui trouve ces fondement dans Java n'a pas plus d'interet...
- Programmeur rangez vos servlets, rangez vos JSP, le retoure à la programmation des CGI est une nécessité, retrouvez toute la puissance des l'operateurs "<<" et ">>" pour géré vos flux.
- Scientifique, industrielle reprogrammez vos applications en C++, c'est certe couteux, mais pensez à tous ces processeurs qui souffre d'être utilisé à presque 10% alors que le même programme C++ permeterait une utilisation de seulement 5% du processeur. ( C'est très important, un processeur qui travail moins, consomme moins, donc lute contre l'effet de serre...)

Vive le Segmentation fault, vive le coreDump, vive le C++...
Ce débat me fatigue, @+

Bon pas un seul argument dans ce post, juste de l'ironie facile.
Rien d'autre ?

[++gib]

attendez, attendez, STOP.
On s'engage sur le terrain de l'optimisation des performances qui est le seul avantage du c++. Il est possible de faire tourner ton programme de calcul de surface plus rapidement que l'original en
-arretant de penser qu'on peut faire de l'allocation statique sur la pile en java : il n'y a pas de pile. D'ou l'utilité d'un cache. Donc gregy tu as raison, même si je ne vois pas pourquoi tu gardes les valeurs initiales...
++gib, en quoi utiliser un pool (ou cache) est bas-niveau? ou même une bidouille. Au contraire c'est une gestion de mémoire haut-niveau car utilisant un conteneur d'objets pré-instanciés (et pas uniquement des références). Pas étonnant que programmer en haut niveau releve de la bidouille dans ton cas Donc je le redis :

Bien sur que c'est de bas niveau !!
A part un programmeur système, personne ne se préoccupe de ça et heureusement !
Pourquoi ne pas gérer le cache du processeur ou le swap de la machine dans la
classe polygone ?

Tu vois la complexité du code propose par gregy ?
J'ai du me pincer lorsque j'ai vu sa restauration des donnnées écrasées !

Tu as vu qu'il était buggé ?

Tu as vu qu'il interdisait toute utilisation de la classe polygone autre que
pour le calcul de l'aire ?

Tu as vu qu'après son "traitement" il n'y avait plus ni extensibilité ni
réutilisabilité des classes ?

Tu as vu que son truc c'est tout, sauf objet ?

Tu rigoles ou quoi ?

Je rappelle que mes mesures n'ont toujours pas été contredites
par aucun d'entre vous, et que jusqu'a preuve du contraire, un programme Java
est environ 15 fois plus lent que le programme C++ equivalent.
Le progremme de gregy ne fait absolument pas la même chose que le programme d'origine
et il ne génère même pas le même résultat.
Si vous n'êtes pas convaincus, affichez le polygone avant de sortir du main()

Sert toi de ta tête et tu verras que tes objets pré-instanciés n'ont d'intérêt que parceque
on fait le MEME calcul 10000000 fois, UNIQUEMENT pour travailler sur des durées
mesurables.
Dans la vie réelle, on se contente de faire le calcul UNE fois lorsque'on est normal.
Par conséquent, ce cache ne sert à RIEN et n'améliorerait en rien les performances
de aire() dans un programme REEL.
C'est donc un artifice permettant d'exhiber des performances totalement fausses
en évitant des instanciations.

Vous me faites une sacré bande de naifs.

Je rappelle pour terminer que le sujet est
la comparaison de performances de programmes equivalents écrits en C++ et Java

Et non
Comment modifier un programme Java pour qu'il soit le moins lent possible.

[Clement Cunin]

Bon pas un seul argument dans ce post, juste de l'ironie facile.
Rien d'autre ?

Non, pour les arguments c'est dans mes posts precedants.

Ton seul centre interet est de montré qu'un langage compilé en natif est plus rapide qu'un langage en environnement protégé sur un machine virtuel... Et si possible en prenant le point d'attacque le plus faible du langage et en lui imposant des truc inutil que tu sais rapide en C++...

TON programme java est 15 fois plus lent que TON programme C++
CQFD, ++gib n'a aucun interet dans se debat !

[grishka]

Très marrant, le coup du modulo 128. Sur un octet, ça s'appelle un débordement.

la différence entre circulaire et débordement.

débordement c'est :
255L : 11111111 correspond à -1 pour un octet signé

+1L

0L : 00000000 correspond à 0 avec une retenu positionnée à 1

circulaire:
127L : (01111111)
+1L
128L : (10000000) correspond à -128 pour un octet signé

mais je te l'accorde ca n'a rien à voir avec java et c++

i = i+1 et i+=1 ne sont sémantiquement pas la même chose. puisque dans un cas c'est une affectation, dans l'autre une incrémentation. Ca n'a pas le même sens. Et pour allez plus loin, en java pour incrémenté, tu est obligé d'avoir affecté une valeur avant. Ce qui est + strict sémentiquement.

bon allez débordement, circulaire, on s'en fout c pareil je justifie simplement ce que le compilateur fait c tout. Une règle n'est pas une erreur. Si tu écris un compilo, tu dois écrire des règle sémantiques.

en c++, on peut faire tout ca, pas en java :

char s;
int i = (int)&s;

float *pf;
int *pi = (int *)pf;

class A{};
A a;
void * p = &a;

const int a;
int *pa = &a //warning seulement
pa = const_cast<int *> &a //pas de warning

Allez moi je peux dire n'importe quoi comme ++gib, de toute facon plus personne ne lit ce forum. hahaha,
je me cite avant de partir

Algo :

SI vous connaissez le C++ à 100%, la STL à 100%, que vous rêvez de performances toute la journée ET que votre appli n'est pas une appli de gestion, une appli distribuée d'entreprise, ALORS choisir C++ (si possible avec un compilo spécialisé intel C++ pour le SIMD)
SINON
SI vous programmez pour windows uniquement et que le java ca vous dit pas ALORS choisir DELPHI
SINON choisir JAVA

Greg tu dis n'importe quoi là... et puis y'a même pas la preuve de terminaison pour prouver que ca marche

ce forum me gonfle!

[grishka]

environ 15 fois plus lent que le programme C++ equivalent

tiens ca vient d'augmenter en quelque jour là (tu disais 10 à un moment). pipotage à outrance nuit gravement à la santé.

Sert toi de ta tête et tu verras que tes objets pré-instanciés n'ont d'intérêt que parceque
on fait le MEME calcul 10000000 fois,

Dans le cas de ton exemple foireux, une seule instance suffit pour faire tous les calculs. Comme l'objet statiquement instancié sur la pile en c++......non?
L'algo des caches permet de s'approcher de O(1) en terme de gestion de ressources.
Et puis la gestion d'un cache ne relève pas du bas-niveau ou alors un serveur d'application est très bas niveau. C'est même un Design - pattern haut niveau !! gestion des pools BDD, préinstanciation des EJB pour le traitement des requetes client, passivation/activation par sérialisation, gestion des transactions.

Essaye de coder un cache en c++ qui fasse tout ca, et on en reparle.

[gregy]

Tu sais ++gib, tu n'étais pas obligé d'écrire un roman sur la bidouile, OUI c'est bien ce que j'ai dit, une bidouille!!!. Tu peux le décortiquer dans tous les sens, mais il y a une chose que tu comprends peut-être pas, c'est que le code de 'crotte' (pour ne pas te citer) était déjà là bien avant que je retouches une seule ligne. Enfin, je peux encore une fois remarquer ton objectivité suprême et visiblement tu n'as pas compris les premières phrases de mon post. Entre parenthèses je n'ai pas que ça à foutre non plus d'aller réécrire un code de polygone à la c**... Si j’ai dis que c’était une bidouille c’est pas pour rien…

Oui c'est une bidouille... Mais ne viens pas non plus avec un code qui est TRES TRES LOIN d'être optimisé... Si tu veux des idées y en a des tonnes... Une classe polygone... C'est très marrant, mais ta classe elle gère TRES mal les points. A part la méthode qui lit et qui fourre tout dans un Vector, retransformé 36000 fois en Enumeration etc ... je ne vois pas grand chose. Alors planche peut-être là dessus. Ta classe point? Elle réintancie sans cesse des objets points. Le fait de ne plus en faire c'est une bidouille( ?), c’est contourner le problème( ?), peut-être dans la façon dont je l'ai fait (et cela je l’ai dit depuis le début),mais sinon NON c'est optimiser un code! Alors ton objectivité à 2 sous tu peux la ranger! Enfin visiblement pour toi un langage objet c’est un langage où l’on instancie des objets de manière sauvage et non réfléchie, dans ce cas, effectivement Java n’est pas ton langage.

Pour écrire des programmes Java dont la vitesse soit acceptable vous devez:

1) Utiliser le moins d'objet possible ;
2) Utiliser les tableaux de préférence aux conteneurs évolués ;
3) Faire attention à ne pas saturer le GC (lu également dans une autre
contribution) ;
4) Vous prendre la tête pour imaginer les hacks les plus tordus.

(1°)Evidemment quand on peut en utiliser 5/6 points3 (apres une ‘bidouille’ en plus j’utilise 6 objets Points3) au lieu 10^8 y a quoi se poser des questions(je sais pas lequel est le plus bidouille des 2, 6 ou 10^8 points?)… Et qui plus est, certainement dans exemple de traitement en boucle. Enfin quand on t’avance des arguments techniques tu n’y fait pas attention non plus, de toute façon c++ est mieux… (Messages de Grégory). Se prendre la tête ? Non ! Mais si ton objet de crotte est mal conçu dès le départ alors oui… Utiliser des tableaux ? C’est quoi le problème ?

Ce qui me fait un peu ‘rire’, c’est que tu critiques le code (je l’avais déjà fait au préalable)… Très bien,… Le polygone n’est plus la (en supposant que la classe/l’objet de base puisse un jour servir à quoi que ce soit d’intéressant…) ??? Peut tu me dire en quoi il n’existe plus ? Les points sont toujours là et réutilisables… Mais quand on réduit assez fortement ton fameux facteur de 12/15, alors la réponse c’est que de toute façon c++ est plus rapide, que 2 secondes c’en est peut-être 3, que quand on optimise un code c’est de la bidouille (certes, c’est que j’ai fait et y a moyen de faire beaucoup mieux…). Alors ton objectivité que tu as clamé haut et fort quelques post plus hauts, je ne peut en avoir que des doutes… Moi je te montres que tes test sont faux, je n’ai pas voulu faire un beau programme, au cas où c’était possible de faire quelque chose avec ce semblant de brol de polygone… ‘Moi au moins j’avance les preuves de ce que je dis ‘ ben, mon vieux, garde tes preuves pour toi…

Bravo, ton programme hyper-hacké et buggé reste 3 fois plus lent
qu'un programme rédigé proprement.
D'autre part pour t'apprendre ce qu'est une méthode scientifique, évalue
la précision relative d'une mesure de 2 secondes avec une résolution de
1 seconde.

Hacké ? Faudrait que tu prennes tu dico Anglais – Français, je crois que tu n’as pas du comprendre le sens du mot… Buggé ? Le programme tourne, il calcule 10^8/10^9/… fois l’aire de polygones à 4/8/… points. C’est pas ça le but ? Enfin si c’est pas ça le but faut m’expliquer alors (et OUI il y a moyen de réuitliser le polygone…, c’est pas pcq j’ai enlevé certaines méthodes ds Aire qu’il n’y a pas moyen de les réutiliser !!!). Pour ce qui est de la méthode scientifque, on ne fait que ‘concourir’ dans le même test. La méthode non ‘scientifique’, c’est toi qui la propose, alors ne craches peut-être pas dessus…D’autre part, ayant en partie une formation scientifique, propose moi des programmes qui permettent de faire ces calculs, car j’ai aucune envie de les programmer … En réumé,n’avance pas n’importe quoi…

A propos de Java
----------------
Je suis heureux que ce code m'offre l'occasion de montrer ce qui se
passe lorsqu'un langage est insuffisant pour l'usage auquel on l'emploie.
On passe des constructions de haut niveau à des constructions
de bas niveau, par exemple ici on abandonne les Vector au profit des
tableaux et les Point3 au profit d'une espèce de cache de 3 doubles
qui évite d'avoir à créer un Point3 supplémentaire.

Bravo ! Encore une fois relis ma première phrase du post ‘code’… Tu vas faire une comparaison d’un code bidouille avec un autre donc java est un mauvais langage…Ca c’est de la méthode scientifique!

Je voudrais également souligner la remarque sur le post de la longueur du code... Il faudrait peut-être apprendre à te relire!!!! C'est bien toi qui disais tout fier que le code c++ était plus court que celui de java. AH OUI, forcément quand on rajoute n'importe quoi dedans... Alors arrête de dire n'importe quoi... Ce n’était que ça le message !

Personne n'est naïf ici. Oui C++ est plus performant en exécution (il faudra quand que tu me montres où j’ai pu affirmer le contraire), et en exécution c'est TOUT. D'ailleurs y a que là dessus que tu argumentes. Oui C++ est plus performant pour la programmation système et de calculs. Mais le seul benchmark que tu propose c'est bizarre, c'est un programme de calcul (enfin ça y ressemble de loin...). Avec un code de crotte! Alors explique moi pourquoi tant de projets, qui sont bien plus ambitieux que de programmer un bête polygone qui sert à rien et autres que de la présentation ( !), sont fait en java. Visiblement les gens, d’après toi, sont tous devenus des imbéciles. Qu’on utilise java à tord et à travers ??? Moi je crois que ça avait été le cas, java serait à la poubelle depuis longtemps… Mais ce n’est pas la cas… Alors vient pas avec ton argument récurent qui est LA performance de C++ et 2-3 brols insignifiants… D’ailleurs s’il n’y avait que la rapidité d’exécution qui était importante, on programmerait tous en ASM… Petite question… Pourquoi tu ne programmes pas en ASM, tu peux avoir des performances bien plus grandes en ASM qu’en C++. Etant donné que c’est LE seul argument que tu sort entre C++/java, dis moi pourquoi tu ne programmes pas en ASM ???? (J’insiste !)

Au fait ? En tant que développeur( ?), dans quels types de projets tu travailles ?


Enfin en résumé, on peut t’avancer n’importe quel argument, tu vas le contrer avec (et surtout) des bétises. Je crois dès lors que ce débât ne vaut peut être plus la peine d’être continué ( ?) . Le mot de la fin étant de toute façon que C++ est mieux en TOUT point (bon allé peut être, et avec grande gentillesse de la part de ++gib, que java est quand même pas trop nulle pour les applis de ‘présentation’ (Merci ++gib, c’est trop gentil fallait pas, je suis sur que c++ ferait mieux))

[gregy]

Tu vois la complexité du code propose par gregy ?
J'ai du me pincer lorsque j'ai vu sa restauration des donnnées écrasées !

Oulala c'est complexe... Par contre, je me suis peté une bosse dans la facon dont ++gib restaure ses données… A croire que tu n’as que le mot new à la bouche

Tu as vu qu'il était buggé ?

Où ca, je vais réparer le bug ..

Tu as vu qu'il interdisait toute utilisation de la classe polygone autre que
pour le calcul de l'aire ?

Où ca, je vais réparer le bug .. Les points ne sont PAS ecrasés, alors dit moi où est le bug. Tu me dit dure comme fer que ca ne marche pas .. ben dit moi ou ??? tu veut que je restaure les donées en fin de parcour ??? ben si ce n’est que ca…

Tu as vu qu'après son "traitement" il n'y avait plus ni extensibilité ni
réutilisabilité des classes ?

ah bon ? donnes des exemples…

Tu as vu que son truc c'est tout, sauf objet ?

oui effectivement j’instancie moins d’objets que toi, en est-ce pour autant moins objet ?

Tu rigoles ou quoi ?

C’est toi qui fait rigoler à la longue avec tes propos…

Je rappelle que mes mesures n'ont toujours pas été contredites

Quelles mesures ? Qu’il failait au moins instancier 900000000 objets pour calculer ton aire qui n’en vaut pas la peine ?

par aucun d'entre vous, et que jusqu'a preuve du contraire, un programme Java
est environ 15 fois plus lent que le programme C++ equivalent.
Le progremme de gregy ne fait absolument pas la même chose que le programme d'origine
et il ne génère même pas le même résultat.

Dit moi les sois – disants bugs car sinon revois tes statistiques de 1 à 3-4 fois (pour le benchmark en question) … Le pgm ne fait pas la mê chose??? relit TON énoncé... Pgm qui calcule des aires de plygones en boucles POINT FINAL... Y a pas plus d'éxigences que ca... qui plus est c'esy fait sur base de TES classes donc je n'ai rien iventé..

Si vous n'êtes pas convaincus, affichez le polygone avant de sortir du main()

réinitilise les points avant de sortir de la boucle et t’auras tes valeurs… Je ne suis pas convaincu de ma solution, mes ton polygone est TOUJOURS la ... puisque de toute manière j'ai les valeurs initiales... Si c'est ca la BUG tu peut aller dormir... pfff j'arrete les discussion là alors...

Sert toi de ta tête et tu verras que tes objets pré-instanciés n'ont d'intérêt que parceque
on fait le MEME calcul 10000000 fois, UNIQUEMENT pour travailler sur des durées
mesurables.
Dans la vie réelle, on se contente de faire le calcul UNE fois lorsque'on est normal.
Par conséquent, ce cache ne sert à RIEN et n'améliorerait en rien les performances
de aire() dans un programme REEL.
C'est donc un artifice permettant d'exhiber des performances totalement fausses
en évitant des instanciations.

Avec un pool de Points3 et des méthodes permettant de changer les coordonnés des points on peut calculer avec un minimum de points énormément de polygones… C’est un artifice ? Non… Par contre on pourrait peut-être croire que de faire for(int i = 0 ; i < 100000000 ; i++){ new Point() ; new Point() ; new Point() ; new Point() ; new Point() ; new Point () ; new Point() ; new Point() ; Point()} pour rien, serait un artifice pour discréditer java

Vous me faites une sacré bande de naifs.

ben non C++ est mieux…

Je rappelle pour terminer que le sujet est
la comparaison de performances de programmes equivalents écrits en C++ et Java

Oui quand c’est bien écrit dans les 2 langages alors..

Et non
Comment modifier un programme Java pour qu'il soit le moins lent possible.

On rend un programme moins lent donc c’est pas bon… Il faut que la programme soit syntaxiquement le même pour respecter à tes règles ??? Il faudrait que tu écrives les règles du jeux…. Mais à part ca le programme fait la même chose à part quelques trucs que j'ai oublié, mais bon j'ai du mal lire l'enoncé du problème...(HUM)

[mat.M]

Lorsqu'on est chef de projet on ne peut se plier qu'aux exigences du Directeur Informatique.
Mais là où intervient le problème c'est quand les solutions technologiques ne sont pas adaptées , sont mal choisies ou bien alors qu'il faille se laisser berner par des effets de mode ( .NET , Java...).
Car avant de s'engager sur un projet informatique , on a intérêt à s'y prendre à 2 fois et même plus dans le choix des outils de développements et solutions technologiques.C'est s'engager sur une durée...
Si les entreprises ne veulent pas investir dans des projets informatiques ( donc gel des projets , baisse conséquent du CA des SSII ) c'est qu'elles se sont rendues compte qu'un projet développé par des développeurs lambda n'aura jamais la touche finale de progiciels comme MS-Office , Word , Access , Star-Office ou autres du commerce.
Vous développez une appli pour un utilisateur : celui-ci va exprimer son mécontentement car il aimerait avoir dans les mains un outil aussi riche que Word ou Outlook avec des raccourcis partout , des assistants , une correction auto etc...
Et je ne suis pas sûr que les ateliers logiciels comme Java .NET ou Visual Basic permettent cela.

[grishka]

Mais là où intervient le problème c'est quand les solutions technologiques ne sont pas adaptées , sont mal choisies ou bien alors qu'il faille se laisser berner par des effets de mode ( .NET , Java...).

pour une mode, java est assez persistante. La plateforme est devenue très mature est cohérente. Ne la compare pas à .NET qui doit encore prouver ce qu'il annonce sur le papier. En fait il est aussi facile de se laisser berner par la désinformation (provenant de microsoft entre autres, ou même sun parfois). A partir du moment où on ne prend pas assez de recul sur une techonologie, on peut croire tout et n'importe quoi. Comme penser que .NET a inventé la roue ou les web services sont une révolution. Forcément si une entreprise laisse tomber son développement pour s'adapter à tout prix à la dernière technologie...
Il est bcp plus risqué de se lancer dans .NET que java car le postulat est de faire confiance à Microsoft sur le long terme.

Et je ne suis pas sûr que les ateliers logiciels comme Java .NET ou Visual Basic permettent cela

un peu de précisions:
-java n'est pas un atelier de génie logiciel. Rational Rose oui.
-Visual Studio est l'AGL de .NET et Visual Basic est un langage faisant partie de .NET
-tu proposes donc de faire des applications avec MFC et c++?

[Elrond]

La question reste:

Vous développez une appli pour un utilisateur : celui-ci va exprimer son mécontentement car il aimerait avoir dans les mains un outil aussi riche que Word ou Outlook avec des raccourcis partout , des assistants , une correction auto etc...
Et je ne suis pas sûr que les langages comme Java .NET ou Visual Basic permettent cela.

Je ne pense pas que le simple fait de pouvoir ajouter des raccourcis soit une justification a l'utilisation de C++ et MFC. D'autant plus que ces fonctionalites sont comme le reste, si l'utilisateur les veut, il faudra les lui faire payer.

En plus, j'ai parfois l'impression que pas mal de ces ajouts (a part peut-etre la correction auto) servent surtout pour les informaticiens qui aiment pas mal tout faire avec le clavier (d'ou les raccourcis) et pouvoir tout configurer (d'ou les assistants), ... Pas mal d'utilisateurs preferent la simplicite.

Neanmoins, simplement pour l'info, est-ce que Java sait faire cela?

[grishka]

qu'un projet développé par des développeurs lambda n'aura jamais la touche finale de progiciels comme MS-Office , Word , Access , Star-Office ou autres du commerce

<joke> la touche finale ce sont les bugs? </joke>

Neanmoins, simplement pour l'info, est-ce que Java sait faire cela?

Bien sur, pourquoi cela ne serait possible qu'avec MFC et c++? la correction auto dans Word n'a rien à voir avec la bibliothèque ou le langage. C'est de l'algorithmique. Et puis histoire d'enfoncer définitivement le clou : Star Office est programmé en java.

[VisualCBien2]

Star Office est programmé en java

T'as oublié de fermer ta balise Joke...
Donc Star office en Java... C'est pour ca que sur le site de http://www.openoffice.org, il recommande d'avoir Microsoft Visual C++ comme compilo ?

The following should demonstrate in detail what steps have to be done to set up the environment:
Run the configure script according to the following example. We assume here that

- the source code is in C:\oo643B
- your STLport files are stored in C:\STLport-4.0 (only in case you use your own STLport installation. If you don't have this, or just don't care, the version provided in the source code will be build)

STL, la lib Java bien connue...

- JDK 1.3.1 is installed in C:\jdk1.3.1

En effet pour Java

- the Microsoft Compiler is located in C:\PROGRA~1\MICROS~3\VC98 (or C:\program files\microsoft visual studio\vc98)

VC++ le compilo Java donc...

- the Microsoft SDK is located in C:\PROGRA~1\MICROS~5 (only applies for 643B and later)

APIWin32 surement Java aussi...

Ca c'était l'install Windows. Allons sur l'install Linux voir ce qui s'y passe :

- glibc 2.1.x or higher

Je connais pas ca...

gcc: OpenOffice.org has been successfully build under Linux using the gcc versions 3.0.x, 3.1.1, and 3.2.1. Older versions were built with gcc 2.95.2. Version 2.96 does not work!

Tiens encore un fameux compilo Java... Gcc en l'occurence.

Je passe le reste des librairies ou on retrouve encore le SDK Java, biensur.

Voila c'était pour dire qu'un produit comme Staroffice entièrement écrit en Java, j'en rigole encore...

Ps : Pour ceux qui doutent -> http://www.openoffice.org/dev_docs/source/build.html

[++gib]

Tu vois la complexité du code propose par gregy ?
J'ai du me pincer lorsque j'ai vu sa restauration des donnnées écrasées !

Oulala c'est complexe... Par contre, je me suis peté une bosse dans la facon dont ++gib restaure ses données… A croire que tu n’as que le mot new à la bouche

Je ne restaure rien, puisque je n'ai rien écrasé.

Tu as vu qu'il était buggé ?

Où ca, je vais réparer le bug ..

C'est extêmement simple, voici ce qui se passe si on imprime le contenu
du polygone avant de sortir du programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Nb de points du polygone :4
0.0 0.0 0.0  0.0 10.0 0.0  0.0 10.0 10.0  0.0 0.0 10.0  ;
Nb d'iterations :10000000
Aire : 100.0
Temps ecoule : (10000000 iterations) 10 secondes
0.0 0.0 0.0  100.0 -0.0 0.0  100.0 -0.0 0.0  0.0 0.0 10.0  ;

Le première ligne, c'est le polygone originel
La dernière c'est ce qu'il en reste après le calcul d'aire.
Ce que fait la fonction aire() porte un nom en programmation :
c'est un effet de bord, et c'est reconnu comme étant une source de
bug redoutable lorsque c'est indésiré.
Maintenant, essaie de t'imaginer l'intérêt d'une fonction qui écrase
ses données d'entrée alors que ce n'est pas son rôle.
Par exemple que penserais-tu si println() écrabouillait ce que tu
imprimes ?
Ta vie ressemblerait à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
X x = new X() ;
X savx = new X(x) ; // je sauve x
System.out.println(x) ;
x = savx ; // je restaure

Maintenant, tu peux réparer.

Tu as vu qu'il interdisait toute utilisation de la classe polygone autre que
pour le calcul de l'aire ?

Où ca, je vais réparer le bug .. Les points ne sont PAS ecrasés, alors dit moi où est le bug. Tu me dit dure comme fer que ca ne marche pas .. ben dit moi ou ??? tu veut que je restaure les donées en fin de parcour ??? ben si ce n’est que ca…

Ben si, ils sont écrasés. Voir ci-dessus.
Mais ce n'est pas (seulement) pour ça que la classe est inutilisable.
Essaie quelque chose d'aussi trivial que ceci.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Polygone pol = new Polygone() ;
pol.readPolygone(fis) ; // fis est un FormattedIStream
pol.addPoint(new Point(0.,2.,3.) ); 
System.out.println("Aire=" + pol.aire()) ;

J'ai juste ajouté 1 point. Ce n'est pas une grosse manip.
addPoint() remet à jour le vecteur, mais pas le tableau de Point3.
Comme je l'avais prévu, il y a incohérence, le polygone a maintenant 5 points
mais aire() continue à calculer sur 4 !

Tu as vu qu'après son "traitement" il n'y avait plus ni extensibilité ni
réutilisabilité des classes ?

ah bon ? donnes des exemples…

Pas extensible car les données sont "private"
(et non "protected" ou "private protected")
Donc pas question d'étendre les fonctionnalités par héritage.
Comme en plus, l'interface est minimale, on est coincés.

Pas réutilisables car elle détruisent les données qu'on leur passe
qui voudrait réutiliser ça ?

Tu as vu que son truc c'est tout, sauf objet ?

oui effectivement j’instancie moins d’objets que toi, en est-ce pour autant moins objet ?

Remplacer des objets (Polygone,Point3) par des types prédéfinis
(tableau,double) , à l'évidence, ce n'est pas objet, c'est du BASIC.

par aucun d'entre vous, et que jusqu'a preuve du contraire, un programme Java
est environ 15 fois plus lent que le programme C++ equivalent.
Le progremme de gregy ne fait absolument pas la même chose que le programme d'origine
et il ne génère même pas le même résultat.

Dit moi les sois – disants bugs car sinon revois tes statistiques de 1 à 3-4 fois (pour le benchmark en question) … Le pgm ne fait pas la mê chose??? relit TON énoncé... Pgm qui calcule des aires de plygones en boucles POINT FINAL... Y a pas plus d'éxigences que ca... qui plus est c'esy fait sur base de TES classes donc je n'ai rien iventé..

Ben voila, c'est fait. Relis donc mes tableaux de chiffres.

Si vous n'êtes pas convaincus, affichez le polygone avant de sortir du main()

réinitilise les points avant de sortir de la boucle et t’auras tes valeurs… Je ne suis pas convaincu de ma solution, mes ton polygone est TOUJOURS la ... puisque de toute manière j'ai les valeurs initiales... Si c'est ca la BUG tu peut aller dormir... pfff j'arrete les discussion là alors...

Bon, donc il est bien cassé ce polygone ?

Sert toi de ta tête et tu verras que tes objets pré-instanciés n'ont d'intérêt que parceque
on fait le MEME calcul 10000000 fois, UNIQUEMENT pour travailler sur des durées
mesurables.
Dans la vie réelle, on se contente de faire le calcul UNE fois lorsque'on est normal.
Par conséquent, ce cache ne sert à RIEN et n'améliorerait en rien les performances
de aire() dans un programme REEL.
C'est donc un artifice permettant d'exhiber des performances totalement fausses
en évitant des instanciations.

Avec un pool de Points3 et des méthodes permettant de changer les coordonnés des points on peut
calculer avec un minimum de points énormément de polygones… C’est un artifice ?
Non… Par contre on pourrait peut-être croire que de faire
for(int i = 0 ; i < 100000000 ; i++){ new Point() ; new Point() ; new Point() ; new Point() ; new Point() ; new Point () ; new Point() ; new Point() ; Point()} pour rien, serait un artifice pour discréditer java

Bon, écoute, on se calme.
Sincérement, je pense que tu devrais revoir ta position et attendre 2 jours
pour répondre. Crois moi, je sais très bien de quoi je parle lorsque je te dis
que ton code, ça ne va pas du tout.
Tu comprends bien que le but du jeu, ce n'est pas de calculer 10000000 fois un polygone,
c'est de faire un benchmark. Pour que ça marche, on doit appliquer les mêmes
algo des deux cotés, avec les moyens disponibles.
Ce n'est pas le cas avec ce que tu proposes.
J'espère qu'il est évident pour tout le monde que ça ne sert à rien de chercher
à gratouiller en se rapprochant de la machine parceque :
1) on va tous finir à l'assembleur et on aura rien prouvé;
2) pour se rapprocher de la machine, il y a tout ce qui faut en C++ et
tu vas te faire étriller. De toute façon je ne le ferai pas.

Nous comparons deux langages à objets. Java clame même haut et fort qu'il est
plus objet que C++. Il me semble donc naturel de programmer avec des objets.
Les deux programmes en créé la même quantité. C++ les manipule beaucoup plus
efficacement, c'est tout.
Ce n'est tout de même pas de ma faute si le seul moyen de créer un objet
en Java est new() !!
Je ne cherche pas à discréditer Java, j'utilise Java
pour faire ce pour quoi il est -théoriquement- prévu : de l'objet.

Si j'avais voulu être déloyal, je n'aurais fait QUE de l'objet.
J'ai choisi au contraire de mettre une bonne dose de calcul sur des types
de base, or c'est précisément là que ce langage est le moins lent,
comme tu as du le remarquer.

Je vais maintenant essayer de te faire comprendre pourquoi, même si elle
était bien implémentée, ta solution n'a pas de sens.

Fondamentalement, ton optimisation est basée sur le principe suivant :
recopier les coordonnées de chaque Point3 vers 3 double pour mener le calcul
en ayant à créer un minimum de Point3.
Bon, ce n'est pas très objet, ça ne correspond plus à l'algo d'origine,
mais jusque là ça a un sens.
On pourrait faire ça localement dans la boucle de aire(), ce qui revient
à shunter les méthodes de calcul vectoriel de Point3 et à faire du
pseudo-procédural.
Là ou ça ne va pas, c'est que tu as essayé de stocker les doubles
(en les dupliquant dans les points du polygone eux-mêmes) pour les
réutiliser lors de l'appel suivant de polygone(). Plus exactement, tu stockes
des valeurs initiales, les valeurs courantes étant écrasées par le calcul.

Le point crucial est "pour les réutiliser lors de l'appel suivant de polygone()".
Or la fonction polygone() n'est jamais réutilisée pour le même polygone
(qui aurait l'idée de faire N fois le même calcul ?)
Nous le faisons 10000000 fois uniquement pour pouvoir mesurer un temps.
Par conséquent, dans la vraie vie, ton optimisation ne sert à rien.

Elle est même néfaste : elle multiplie la taille des données par x 2
et elle fait perdre du temps, puisque tu initialises une sauvegarde
qui ne te servira jamais.


Pour te faire comprendre l'absurdité de ta démarche, je vais te donner
une solution basée sur le même principe que la tienne, mais appliquée
à Polygone plutot qu'a Point3
Cette solution laisse loin derrière n'importe quel programme C++
et ne demande que 3 lignes de plus que mon code d'origine.

1) Dans la classe Polygone ajouter:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
private double monAire ;

2) Dans le constructeur ajouter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
monAire = -1.0;

3) En tête de la méthode aire(), ajouter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if(monAire != -1.0 ) return monAire ;

4) remplacer le return de aire par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
return (monAire = 0.5 * som.norme()) ;

C'est tout !!
Essaie, je te prédis des performances à décoiffer les chauves,
et un résultat exact, sans casser le polygone.
En outre, plus on fera d'itérations sur aire(), meilleur sera le résultat.

J'intitule mon procédé "Résultat pré calculé"
(comme objet pré-instancié) et je dépose un brevet.

Ce code est totalement stupide, mais il répond à ce que tu crois être le problème:
obtenir les meilleurs chiffres possibles sur un benchmark, sans se soucier de ce à
quoi sert le benchmark. Pour y parvenir, il utilise comme le tiens une technique de
cache (mais appliquée à un plus haut niveau).

On rend un programme moins lent donc c’est pas bon… Il faut que la programme soit syntaxiquement le même pour respecter à tes règles ??? Il faudrait que tu écrives les règles du jeux…. Mais à part ca le programme fait la même chose à part quelques trucs que j'ai oublié, mais bon j'ai du mal lire l'enoncé du problème...(HUM)

Ce n'est pas bon car il ne fait pas la même chose (rendant ainsi la comparaison impossible)
et AUSSI parceque la solution employée n'apporte rien en situation réelle (ie: hors benchmark)
Relis bien ce que j'ai écrit si tu n'est pas convaincu.
La syntaxe n'a rien à voir avec ça.

[grishka]

...</joke>

Je parlais de StarOffice développé par Sun et non d'openOffice basé sur le code source de staroffice... Mais autant pour moi qd même :
staroffice est effectivement programmé en c++ avec du java (plus de c++ que de java même). Bizarre pour un truc Sun mais bon, si tu te dis que java est trop lent, je te retorque que non car si tu veux une vraie appli en java : l'environnement de développement Eclipse. Bon la je suis sur, vu que l'utilise en ce moment

[gregy]

Bon, écoute, on se calme.
Sincérement, je pense que tu devrais revoir ta position et attendre 2 jours
pour répondre. Crois moi, je sais très bien de quoi je parle lorsque je te dis
que ton code, ça ne va pas du tout.
Tu comprends bien que le but du jeu, ce n'est pas de calculer 10000000 fois un polygone,
c'est de faire un benchmark. Pour que ça marche, on doit appliquer les mêmes
algo des deux cotés, avec les moyens disponibles.
Ce n'est pas le cas avec ce que tu proposes.
J'espère qu'il est évident pour tout le monde que ça ne sert à rien de chercher
à gratouiller en se rapprochant de la machine parceque :
1) on va tous finir à l'assembleur et on aura rien prouvé;
2) pour se rapprocher de la machine, il y a tout ce qui faut en C++ et
tu vas te faire étriller. De toute façon je ne le ferai pas.

Pour un peu se rafraîchir la mémoire:

Que fait le programme ?
-----------------------
Un calcul géométrique très courant en C.A.O. Il calcule répétitivement
l'aire d'un polygone plan (non croisé) défini dans l'espace par des points.

Alors si t'es pas convaincu, fait un autre benchmark, c'est toi qui le propose... et pour info, un tableau en java est un objet... alors se rapprocher plus de la machine je vois vraiment pas où...

Le point crucial est "pour les réutiliser lors de l'appel suivant de polygone()".
Or la fonction polygone() n'est jamais réutilisée pour le même polygone
(qui aurait l'idée de faire N fois le même calcul ?)
Nous le faisons 10000000 fois uniquement pour pouvoir mesurer un temps.
Par conséquent, dans la vraie vie, ton optimisation ne sert à rien

Qui te dis que pour autant tu devras reinstancier des objets??? J'ai adapté le pgm de TON benchmark... Je vais pas m'amuser à prévoir tous les cas, juste pour montrer que ton benchmark est faussé...Alors proposes autre chose et on verra...

Remplacer des objets (Polygone,Point3) par des types prédéfinis
(tableau,double) , à l'évidence, ce n'est pas objet, c'est du BASIC.

tableau pas type . tableau = objet. tableau = referenceS à objets. Comprends?
Je ne vois pas où j'ai pu remplacer polygone??? Explique moi...
Je ne vois pas où j'ai pu remplacer point, j'en utilise moins mais à part ca ... les méthodes sont à mon au moins 80% les mêmes, sauf qu'elles ne se terminent pas avec un new, qui pour toi est visiblement ta seule solution de programmation. Alors si ce n'est pas de la mauvaise foi de dire que Polygone et Point sont transformés en 'type prédéfinis' je ne comprends plus... Pour le Basic, faut croire que les classes étaient déjà écrites en basic...

Elle est même néfaste : elle multiplie la taille des données par x 2
et elle fait perdre du temps, puisque tu initialises une sauvegarde
qui ne te servira jamais.

Primo : La copie des donnée est utilisée, sinon effectivement les calculs seraient faux. Elle provoque une perte de temps??? Excuses moi,mais là tu as tout faux, c'est bien ces copie de données qui m'ont permis de restaurer les points sans devoir les reinstancier. Ce qui a valu une perte de temps de -7 secondes dans mon test...
Deuxio : Elle mulitplie * 2 le nombre de données? Ah bon? Depuis quand tu te soucie de la taille des données? Pourtant créer (n Itterations * 9 ) d'objets points ca ne te posait pas de problèmes... Il faudrait savoir...

Pour te faire comprendre l'absurdité de ta démarche, je vais te donner
une solution basée sur le même principe que la tienne, mais appliquée
à Polygone plutot qu'a Point3
Cette solution laisse loin derrière n'importe quel programme C++
et ne demande que 3 lignes de plus que mon code d'origine.

1) Dans la classe Polygone ajouter:
Code:

private double monAire ;


2) Dans le constructeur ajouter
Code:

monAire = -1.0;


3) En tête de la méthode aire(), ajouter
Code:

if(monAire != -1.0 ) return monAire ;


4) remplacer le return de aire par
Code:

return (monAire = 0.5 * som.norme()) ;



C'est tout !!
Essaie, je te prédis des performances à décoiffer les chauves,
et un résultat exact, sans casser le polygone.
En outre, plus on fera d'itérations sur aire(), meilleur sera le résultat.

J'intitule mon procédé "Résultat pré calculé"
(comme objet pré-instancié) et je dépose un brevet.

Ce code est totalement stupide, mais il répond à ce que tu crois être le problème:
obtenir les meilleurs chiffres possibles sur un benchmark, sans se soucier de ce à
quoi sert le benchmark. Pour y parvenir, il utilise comme le tiens une technique de
cache (mais appliquée à un plus haut niveau .... etc etc etc

Tu sais y a encore moyen de tourner ton test encore de facon plus ridule... on peut p.ex. prendre le cas d'un carré de 10 de long de chaque côté.. comme ca y a plus de probleme ....

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5

public static double aire(){
  return 100.0d;
}

La performance en sera encore plus grande... La seule chose que t'oublie c'est que je fait les calculs, les points sont peut-être écrasés à la fin (Voir LE bug), mais possibilté de restaurer les valeurs ou utilise les valeurs initiales dans toString de point, sans doute encore une bidouille, mais ce serait déjà plus logique et ca resoud ton fameux probleme)... d'autres bugs?? sans aucun doute, comme déjà dit mainte fois, mon but était d'accelérer le calcul et que forcément je ne suis pas passé partout donc forcément y a des fonctionnalités qui ne marche plus (jusqu'à présent une réelle qui est addPoint, car j'insiste ton polygone n'est pas cassé car je l'utilise tout de meme 10^8 fois)... Je me suis basé sur le fond du benchmark qui quand même était le calcul de l'aire... Si mon amélioration, n'est pas 'utilisable' en réel, il faut croire que ce benchmark en général n'est pas du tout repésentatif... De toute mnaière il ne l'est certainement pas(...)

Pour revenir au problème de tes principes de benchmark et je suppose que tu fais allusion à

Grands principes
----------------
Les deux codes sont écrits selon les mêmes principes, avec les éléments
que les langages proposent. Le modèle objet est exactement le même
et j'ai essayé d'être loyal (par exemple, j'ai essayé de limiter le
nombre de variables intermédiaires au minimim dans les deux cas)
Si quelque chose ne vous parait pas conforme à ce principe, signalez-le.

et que personne ne t'as fait de remarque... Très bien! Mais qui t'as dit qu'on programmait de la même manière en C++ et java??? Etant donné que ces langages sont techniquement fort différent (voir messages de Grégory), qu'est-ce te permet dire que de préserver "le modèle objet" n'est pas déloyal? Désolé mais en java tu ne fais pas des new sans cesse dans une boucle comme illustré dans ton exemple. En java si tu as besoin de ressources tu les prévois (pools, caches etc) que l'on ne voit nulle part dans ton code.Alors oui ton code départ en java est l'illustration du programmeur c++ qui essaie de faire quelque chose en java, mais dans la "réalité", comme tu le dis si bien, on écrit pas comme ca....

Pour les autres remarques, je te laisses à ton ironie à 2 balles et ta subjectivité légendaire...

[mat.M]

Donc Star office en Java... C'est pour ca que sur le site de http://www.openoffice.org, il recommande d'avoir Microsoft Visual C++ comme compilo ?

Merci beaucoup pour cette précision VisualCBien2 ( je vais pouvoir critiquer Java encore plus )!!
Java et les autres outils associés c'est très bien.....très bien...s'il faut un compilateur C++ pour pouvoir en tirer profit..!
A titre de comparaison , c'est comme si on achetait une voiture et qu'il faudrait une autre voiture pour piéces pour pouvoir rouler avec la première !

-java n'est pas un atelier de génie logiciel. Rational Rose oui.
-Visual Studio est l'AGL de .NET et Visual Basic est un langage faisant partie de .NET
-tu proposes donc de faire des applications avec MFC et c++?

On est libre d'utiliser l'environnement de développement de son choix....

D'autant plus que ces fonctionalites sont comme le reste, si l'utilisateur les veut, il faudra les lui faire payer.

Personne n'a compris ce que je voulais dire ...je me suis peut-être mal exprimé.
Qu'importe l'environnement de développement que vous utilisez mais l'impression générale des travaux informatiques sur mesure donc prestations fournies par une société de service informatiques n'équivaut pas la touche des logiciels du commerce.
D'où la question : quel intérêt et quelle pertinence de développer un outil logiciel sur mesure pour une société ??

[++gib]

Très bien! Mais qui t'as dit qu'on programmait de la même manière en C++ et java??? Etant donné que ces langages sont techniquement fort différent (voir messages de Grégory), qu'est-ce te permet dire que de préserver "le modèle objet" n'est pas déloyal? Désolé mais en java tu ne fais pas des new sans cesse dans une boucle comme illustré dans ton exemple. En java si tu as besoin de ressources tu les prévois (pools, caches etc) que l'on ne voit nulle part dans ton code.Alors oui ton code départ en java est l'illustration du programmeur c++ qui essaie de faire quelque chose en java, mais dans la "réalité", comme tu le dis si bien, on écrit pas comme ca....

Tu ferais mieux d'arrêter, tu es en train de dire à tout le monde que:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
POUR OBTENIR DES PERFORMANCES CORRECTES EN JAVA
-On ne doit surtout  pas programmer en objet
-On doit gérer un maximum de ressources  (pools, caches etc)
 soi-même à la main.

Je suis assez d'accord avec ce point de vue,
mais ça semble assez contre-productif pour Java.

[++gib]

Le parcours d'un Vector avec Enumeration est plus rapide que celui d'un Arraylist avec Iterator (cf message précédent)

En voila la preuve :

Et bien, je suis content pour lui.
En C++ on ne se pose pas ce genre de question, mais je
te rappelle que le sujet c'était la comparaison C++ Java.
Utilise le conteneur que tu veux, mais montre moi un code STP.