Citation:
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:
Citation:
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ù...
Citation:
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...
Citation:
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...
Citation:
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...
Citation:
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:
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 à
Citation:
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...
