[D�bat] C++ vs Java

Ca tient du dialogue de sourd la!

Pas tant que �a. ++gib affirme avoir d�crit un de ces benchmark, ainsi qu'une d�monstration. A part celle de l'asm, je n'en voit pas d'autre, j'ai peut-�tre rat� un post ou mal compris qq chose, dans ce cas je pr�sentes mes plus plattes excuses... Enfin soit, mon message allait plus dans le sens qu'il manquait un vrai benchmark...

Je pense pour ma part que la rapidit� d'execution sera de moins en moins un probl�me, (avec la puissance croissante des ordinateurs et les am�liorations nombreuses apport�es au JRE et au langage lui m�me).

Aujourd'hui il plus d'actualit� de confronter JAVA � C# par exemple, puisque le fond de commerce des deux est l'informatique distribu�e et les services Web.

Pour les applications classiques, pas de probl�me il faut apprendre le C/C++ car des jeux, applications multimedia en JAVA ce n'est surement pas pour demain.

Envoy� par Gr�gory Picavet

comme tu viens de le d�montrer, java est plus fortement typ� que le c++ dans le sens ou il produit une erreur et pas un warning.
La relation "est un" est � prendre au sens objet, c'est � dire "peut se substituer �". En java, il faut effectuer un dynamic cast : int i = (int) 0.5f par ex, car c'est vu comme un transtypage (au sens objet), donc le typage java est plus strict.

Bonjour Gr�gory
Ce n'est pas cool de pinailler. Le fait qu'une probl�me soit report� comme
une erreur ou un avertissement depend simplement des options de compilation,
c-a-d des souhaits de l'utilisateur. On peut transformer le warning
gcc en erreur baveuse (option -pedantic-errors la bien nomm�e),
ou m�me n'avoir aucun rapport d'erreur si on le d�sire.
Ca n'a pas grand chose � voir avec le langage.
Ce qui est important c'est que la s�mantique du langage fasse que le compilateur
puisse d�tecter un probl�me.
javac dit "probl�me potentiel" (il a raison, ce n'est pas
forc�ment un probl�me)
et gcc dit "attention, assignation d'un double � un int",
apr�s c'est au programmeur de prendre ses responsabilit�s.

Pour la suite de ton intervention, je suis perplexe car
int i = (int) 0.5f ; est exactement ce qu'on *pourrait* �crire
aussi en C++ pour �tre clean avec le compilo.
Pour cet exemple pr�cis, je parlerais d'ailleurs plut�t de conversion, car
un "int" n'est pas un objet en Java(1)(2) (pas plus qu'en C++ d'ailleurs).
On ne peut donc pas parler de relation "est-un" (qui est mod�lis� par
l'h�ritage en programmation objet).
On a plut�t une relation "peut-etre-converti-en" dans les deux langages
avec des garde-fous pour �viter de convertir n'importe quoi
en n'importe quoi.
C++ propose d'ailleurs la conversion
static_cast<Type_cible>(expression) servant (je cite) aux
"conversions bien d�finies, mais non-s�res".
Comme nous sommes en plein dans ce cas, ton exemple s'�crirait proprement
int i = static_cast<int>( 0.5f ) ;
en C++, ce qui est plus pr�cis que la version Java.

On dispose aussi de reinterpret_cast, const_cast et dynamic_cast
pour pr�ciser explicitement ses intentions lors d'un conversion.

Donc, cher contradicteur, je me permet de nuancer vos affirmations.

(1) Ceci montre d'ailleurs que la r�clame
"Java est 100% objet" n'engage que ceux qui la croient.
(2) J'irai plus loin : un String n'est pas un objet non plus, c'est un
�tre hybride qui a certaines propri�t�s des objets et des types natifs.
------

arithm�tique des pointeurs ca veut bien dire : si p1, p2 sont des pointeurs alors p1+p2 aussi, p1-p2, p1+1, etc... et donc permettent d'acc�der � la m�moire un peu n'importe comment. En java, �videmment, ca n'a aucun sens. l'acc�s � la m�moire se fait par conteneur (avec get/set). D'ou un accroissement de la s�curit�. De plus on peut convertir un tableau de type primitif en son �quivalent DirectBuffer (et inversement) dans l'ordre natif des octets de la machine, de mani�re transparente.

Oui, etc.. Sauf que :
1) p1+p2 n'a pas de sens physique (somme de 2 adresses) et ne compile
m�me pas.
2) p1-p2 a un sens mais n'est pas un pointeur, c'est un entier
(nombre d'�l�ments entre les deux adresses)
3) seul, p1+1 est bien un pointeur.
Dans ces conditions on comprend pourquoi la m�moire est acc�d�e n'importe
comment.

Je pr�dis un "brillant" avenir � ce paquetage. Il est en contradiction
avec la philosophie de Java.

est-ce donc que tu reconnais que la philosophie de java est bonne est que le c++ n'a pas de brillant avenir? .Bon �videment c'est pas aussi simple. De plus, les buffer � acc�s direct ne sont qu'un cas particulier de ce package. Les entr�s-sorties �taient le point faible de java. Le package nio permet de r�aliser enfin des applications tr�s performantes, capable de monter en charge. Le package io permet de g�rer simplement la m�moire avec des performances qui sont bien connues (� cause du blocage avec les threads entre autres)...Le package nio, un peu plus complexe permet de g�rer pr�cisement les buffers sans blocage. Les domaines de pr�dilection de ce package, d'apr�s les cas d'utilisation que l'on peut trouver dans les entreprises, sont les serveurs, le chargement des donn�es en m�moire, etc...
Quant � la s�curit�, je ne sais pas si elle est toujours garantie par rapport aux tiers, chose importante quand on travaille dans une architecture distribu�e.

Bonne dans l'absolu ne signifie pas grand chose (bonne pour quoi ?)
je veux simplement dire que

- c'est une porte ouverte � la bidouille
- sa pr�sence t�moigne de la volont� de combler des faiblesses.

Je pense que Sun devrait s'abstenir de ce genre de chose
qui ne peut que les d�cr�dibiliser, mais je n'ai
pas �tudi� le package d'assez pr�s pour �tre cat�gorique.
Je constate que, toi aussi, tu as un doute sur la s�curit� de la chose.
------

En fait le code d'un template n'est compil� que si on r�alise une instance de ce template. C'est un peu le point faible car tant qu'aucune instanciation n'est faite, il n'y a aucun moyen de v�rifier le type (� chaque techno son inconv�nient bien sur).

Evidemment, puisque les types sont fix�s � l'instanciation !
De toute fa�on, un code g�n�rique non instanci� ne risque pas
plus de g�n�rer un erreur d'ex�cution qu'un programme pas encore �crit.

pour ceux qui s'int�ressent aux templates en java, il existe des projets en cours. http://igm.univ-mlv.fr/~forax/java/jlx/template/paper/Je crois que Sun, si ce n'est pas d�j� fait, devrait s'inspirer de ces travaux de recherche qui sont tr�s prometteurs.

Et bien voila, on y vient! Je me souviens d'une argumentation de pro-Java
il y a quelques ann�es qui proclamait haut et fort que les templates ne servaient
� rien en java puisqu'on pouvait fourrer n'importe quel objet dans un conteneur.

Ceci montre que la v�ritable puissance d'un langage est avant tout d'�tre extensible.

A bon tu connais bcp de langage qui ne sont pas extensibles?
Tu vois qu'il n'y a pas que les performances dans la vie.

Plein !!!! (dont un dont le nom commence par J et finit par a).
Un langage extensible est un langage dans lequel ce que tu d�veloppes ne peut
pas �tre distingu� de ce qui existait avant.
Un exemple frappant est FORTH : tu peux tout red�finir (m�me les structures de contr�le
en �tant habile), et tout ce que tu as d�velopp� s'utilise comme du natif. LISP est un
autre exemple, mais ces deux langages ont en commun une syntaxe extr�mement frustre,
et d'autres caract�ristiques ce qui en limitent l'usage.

En ce qui concerne C++, les types que tu peux d�finir s'utilisent exactement
comme les types natifs (m�me syntaxe, m�me fa�on de les passer en param�tres,
interface pouvant �tre bas�e sur des op�rateurs, etc.)
Leurs performances sont �galement tr�s proches (tu vois que les perf, dans la vie,
�a sert, m�me si il n'y a pas que �a -effectivement-)
C++ permet �galement de d�finir des op�rateurs de conversion, etc.
Tout ceci fait que les types que tu d�finis sont absolument indiscernables des types
natifs.
L'extensibilit� c'est �a, et Java ne le fait pas.

L'extensibilit�, c'est aussi de pouvoir impl�menter facilement des
fonctionalit�s qui n�cessiteraient autrement une modification des structure
de contr�le du langage.
Par exemple, C++ utilise un concept tout simple, mais tr�s utile : le destructeur.
Regardes de pr�s Jthreads++ et tu verra qu'il est utilis� pour impl�menter les
sections critiques (synchronized en Java).
Voila un concept qui a �t� �cart� dans la conception de Java, et qui pourtant
remplace a lui seul synchronized, finalize() et finally.
Pas mal pour un truc qui ne sert a rien.
(Voir dans les post ant�rieurs mes interventions � ce sujet).
L'extensibilit�, c'est �a et Java ne le permet pas.

L'extensibilit�, c'est aussi que les extensions n'�puisent pas le programmeur
qui les utilise et la machine qui les ex�cute.
Lorque je vois les sinistres bidouilles qu'il faut faire pour
donner � un "int" une tr�s vague s�mantique objet, je pleure :
conversion en int->Integer, puis Integer->int pour la moindre op�ration,
puis retour en Integer, et vlan, la JVM p�dale � chaque conversion !
L'extensibilit�, c'est �a et Java ne l'offre pas.

En plus sans java, JThread n'existerait pas, on peut donc reconnaitre que java propose de bonne id�es en programmation.

J'esp�re que tu ne veux pas dire que les concepteurs de Java ont invent� les threads ?
Il s'agit de mise en oeuvre d'un concept qui existaient et avait �t� impl�ment� bien avant.
Le nom Jthreads++ est un nom "commercial" qui rappelle que les fontionnalit�s sont identiques
et c'est tout. J'ai fait pendant longtemps des threads en C (pas C++) : c'�tait beaucoup moins
commode qu'en Java, mais �a marchait. Il se trouve qu'en C++, c'est aussi commode et qu'il
n'y a pas eu besoin pour cela de modifier le langage.

J'affirme qu'en moyenne, on peut s'attendre � obtenir 80 � 100% des performances du c++ optimis�. Maintenant dans l'application que je d�veloppe, je ne vais pas m'amuser � la faire en c++ pour le plaisir de faire du benchmark, je m'en fous.

Ben .. d'accord, mettons que je m'en fiche aussi,
mais d'ou sortent les 80 � 100% si tu n'as pas essay� ?
De toute fa�on le probl�me r�el est ci-dessous.

Il est notoire que les calculs 3D co�tent cher et doivent
donc repr�senter une part importantes des temps d'ex�cution.
Je me demande donc si vous n'avez pas mesur� les performance d'open GL
(qui ne doit pas �tre �crit en Java, et peut d'ailleurs largement reposer
sur le mat�riel) au lieu de celle de votre code.
Avez vous profil� l'appli pour voir ou se passe le temps d'ex�cution ?

Evidemment la librairie opengl pour java est r�alis�e avec jni. Lors de l'ex�cution, le JIT optimise les acc�s comme si ils �taient en natif. Donc les appels de m�thodes opengl se font � la m�me vitesse qu'en c++. Maintenant la perte de performance se fait dans la gestion de la m�moire, d'ou les optimisation que je donne. De plus, il est possible d'am�liorer le syst�me de chargement des textures avec nio.
Quant au profilage, ma foi, il est �vident que le goulot d'�tranglement est ici la capacit� de la carte graphique. TOUS les calculs sont effectu�s par opengl, donc en natif.
Si je veux distribuer mon appli, il faut que je fournisse une dll pour windows, une librairie pour linux, pour beos, etc.. qui sont fournies

Le librairie open GL est *appel�e* au travers de JNI (interface avec du code natif)
elle n'est pas r�alis�e *avec* JNI; c'est plus qu'une nuance, �a n'a rien � voir.
Ce que je supposais se v�rifie donc, ton appli ex�cute du code natif (en
proportion inconnue).

Le temps que tu as mesur� ne concerne donc pas du code Java mais du code C ou C++
encapsul� par une surchouche Java. En fait, c'est m�me peut-�tre plus compliqu�
si des op�rations sont faites par hardware.
Je trouve assez fort, et carr�ment non scientifique de pr�tendre mesurer la rapidit�
d'un langage de cette mani�re (c-a-d en ex�cutant du code �crit dans un autre langage)

Par exemple: (et ce n'est qu'un exemple car je ne connais pas les chiffres r�els)

Supposons que dans une appli C++ utilisant OpenGL, 90% du temps soit consomm�
par openGL et 10% ailleurs (�a me semble �tre une hypoth�se minimale puisque
tu dis que TOUS les calculs sont faits par openGL.)

Sur 100s on passe donc
90s en OpenGL 10s ailleurs.
Recodons la partie non openGL en Java et *supposons* que celle ci soit 5 fois plus lente
on obtient donc
90s en OpenGL 50s ailleurs, soit 140s c-a-d seulement 1,4 fois le temps initial
ce qui est en contradiction avec notre hypoth�se de d�part (5 fois).
Ce type de test ne mesure donc absolument pas les perf du langage.

On va me r�torquer qu'on en a rien � faire puisque, de toute fa�on on r�cup�re bien 80�90%
des perf du C++ pur. Manque de pot, on � perdu au passage tout ce qui fait l'int�r�t de Java
a) la simplicit� puisqu'on est oblig� de se prendre la t�te avec des optimisations,
des acc�s direct � je ne sais quoi, des transformations de tables Java en tables natives, etc.
b) le programme n'a plus l'universalit� que devrait fournir la JVM, puisque tu dois fournir
les bibli openGL (DLL ou .so) pour qu'il tourne. Il se trouve exactement dans la m�me
situation que n'importe quel programme compil�, en C++ ou autre, ce qui fait s'effondrer
tout le mod�le java.

Vrai ou faux ?


Je crois qu'il ne faut pas avancer comme cela des chiffres qui, si ils
ne sont pas faux en eux m�mes, ne repr�sentent pas ce qu'ils sont cens�s
repr�senter. Je pense sinc�rement qu'ils ont �t� pris pour argent comptant
et contribuent � alimenter la rumeur.

C++

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
void f(int a, float b) {
}
int main(int, char **)
{
    f(0, 0.5);
}

compil� avec gcc : aucun warning

JAVA

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
class Test {
    public static void f(int a, float b) {
    }
    
    public static void main(String[] args) {
        f(0,0.5);    
    }
}

test.java:7: f(int,float) in Test cannot be applied to (int,double)
f(0,0.5);
^
1 error

option -pedantic-errors la bien nomm�e

si bien nomm�e que TOUS les warnings deviennent des erreurs...tip-top!

Ca n'a pas grand chose � voir avec le langage

ca a � voir si le langage est strict ou pas

il a raison, ce n'est pas
forc�ment un probl�me

Va dire ca aux programmeurs qui font un peu de calcul scientifique.

apr�s c'est au programmeur de prendre ses responsabilit�s.

c'est la philosophie du c++, en effet. Y'a rien � dire de plus

On ne peut donc pas parler de relation "est-un" (qui est mod�lis� par
l'h�ritage en programmation objet).

Et alors qui m'empeche de r�fl�chir en objet, m�me si je doit coder en proc�dural apr�s? la m�thode d'analyse n'a rien � voir avec l'impl�mentation, c'est un processus d'abstraction que je trouve �l�gant et juste d'appliquer � java, m�me pour le transtypage (OK c'est un peu os�)

en C++, ce qui est plus pr�cis que la version Java

oui et qui est inutile en java, car tout est dynamique.
D'ailleurs puisque qu'on en viens aux cast du c++, bravo on peut par faire de programmation plus d�gueulase que ca (transformer des constantes en variables, etC...

On dispose aussi de reinterpret_cast, const_cast et dynamic_cast
pour pr�ciser explicitement ses intentions lors d'un conversion.

bravo, et je suis s�r que comme moi tu sais t'en servir. Mais en java, on s'en fout car tout est dynamique, tout est portable, tout est simple.

Donc, cher contradicteur, je me permet de nuancer vos affirmations.

je te permet aussi de prouver les tiennes

Mais si seulement ca s'arr�tait la, mais non! c++ dispose des op�rateurs conversion implicite (avec les constructeurs), Ce qui repr�sente un source de bug perfide pour le non initi� puisque le compilateur effectue les transtypage dans votre dos!! OK la parade est d'utiliser le mot-cl� "explicit". (Voir le cours c++ pour les pros par Bruno Garcia sur ce site)
Bref C++ permet bcp de chose par d�faut et la seule solution est de connaitre � 100% le langage pour �viter les conneries. Et pour la maintenance d'un programme, prions pour que le programmeur suivant sache aussi bien manipuler le langage.

"Java est 100% objet" n'engage que ceux qui la croient

ouaou, mais qui � os� affirmer cette chose ici? personne mon vieux. Tout le monde sait qu'au m�me titre que c++, c'est un langage ORIENTE objet. Ne reproche pas au gens ce qu'ils n'ont pas dit! c'est facile. Par contre en c++ rien ne t'empeche de faire du proc�dural (de faire du C quoi), c'est un fait.

(2) J'irai plus loin : un String n'est pas un objet non plus, c'est un
�tre hybride qui a certaines propri�t�s des objets et des types natifs.

<mode-provoc>Absolument n'importe quoi, tu baisses dans mon estime. Va revoir tes cours de java, si jamais t'en a d�j� eu</mode-provoc>.
Moi j'en connais un d'�tre hybride, c'est le c++ TOUT ENTIER.
Et puis ne dit pas type natif en java, on va te lancer des pierres... dit plutot type primitif car contrairement � c++, les types ne sont pas natifs mais portables (char c'est de l'unicode 16 bit par ex, int c'est 32bits tt le temps, etc...)

- c'est une porte ouverte � la bidouille

non, non, au performances.

- sa pr�sence t�moigne de la volont� de combler des faiblesses

oui, ou est le mal?

Je pense que Sun devrait s'abstenir de ce genre de chose
qui ne peut que les d�cr�dibiliser, mais je n'ai
pas �tudi� le package d'assez pr�s pour �tre cat�gorique

bravo la c'est toi qui te d�cr�dibilise.

Je constate que, toi aussi, tu as un doute sur la s�curit� de la chose.

Principe de pr�caution, esprit cart�sien....

Evidemment, puisque les types sont fix�s � l'instanciation !

Oui et bien justement!
"Ceci est en contradiction avec le typage statique fort qui garantit la suret� du code en Java"

Et bien voila, on y vient! Je me souviens d'une argumentation de pro-Java
il y a quelques ann�es qui proclamait haut et fort que les templates ne servaient
� rien en java puisqu'on pouvait fourrer n'importe quel objet dans un conteneur.

moi, je suis pro-java et pro-c++ suivant le contexte de mon application.
Autant partager au b�n�fice de chacun. Ce que je vois, c'est que les templates sont une bonne chose. point barre, on va pas tergiverser la dessus plus longtemps.

Un langage extensible est un langage dans lequel ce que tu d�veloppes ne peut
pas �tre distingu� de ce qui existait avant

Ton affirmation est fausse. C++ est param�trable (red�finition les op�rateurs, des types) par rapport � java. Ce qui apporte une difficult� suppl�mentaire � la maintenance d'un programme, � sa lisibilit�, crit�res parfois aussi important...Mais comment peux-tu affirmer que java n'est pas extensible, toi qui connait si bien le langage? une librairie n'est-elle pas l'extension d'un langage en cela qu'elle apporte des fonctionnalit�s de plus haut niveau? quand j'utilise swing, jdbc, hop j'arrete de faire du java . Bref Java n'est pas moins bien, ill est DIFFERENT DANS SA PHILOSOPHIE. Je pense que les programmeurs du langages sont aussi talentueux que ceux du c++, et imposer des contraintes c'est pas pour faire ch.... les programmeurs. C'est pour r�fl�chir autrement.

L'extensibilit� c'est �a, et Java ne le fait pas.

Et bien non, c'est pas ca, et java est extensible. C'est pour ca qu'il marche aussi bien.

sections critiques (synchronized en Java).
Voila un concept qui a �t� �cart� dans la conception de Java, et qui pourtant
remplace a lui seul synchronized, finalize() et finally.

comprends rien, mais vas-y explique moi ce qu'est une section critique est dit moi en quoi c'est pas bien impl�ment� en java (java c'est nul c bien connu, y'a pas de destructeurs)

Pas mal pour un truc qui ne sert a rien.

oulala, en c++ pas de doute un destructeur ca sert, mais en java? non

J'esp�re que tu ne veux pas dire que les concepteurs de Java ont invent� les threads

ben non si tu lis bien
La facon dont Jthreads++ g�re les threads est une r�plique de java : synchronized comme moniteur, wait, notify pour la communication entre threads. D'ou l'influence positive de java sur cette librairie.

mais d'ou sortent les 80 � 100% si tu n'as pas essay� ?

80�100% c'est ce que J'AI ESSAYE en comparant les tutoriaux �crit en c++ et ceux �crit en java. Pour mon application, je n'ai pas fait de comparaison, �videmment, je n'ai pas le temps. Et je m'attends � ne pas avoir la m�me vitesse (quoique). Au final il faut tenir compte de tout les modules du jeu qui s'exc�tent de mani�re concurrente � openGL.

Le librairie open GL est *appel�e* au travers de JNI (interface avec du code natif)
elle n'est pas r�alis�e *avec* JNI

l'interface est en java, l'impl�mentation en c/c++, la liaison avec JNI. Pardon pour ce manque de nuance qui n'a aucun impact. Je ne vois pas comment �crire un drivers opengl autrement qu'en natif, mister. D'ou l'utilit� du binding. Et puis la surcouche n'est qu'apparente puisque le binding avec le natif est fait � la vol�e par le JIT compiler.
Tu voudrais r��crire opengl en java? r�fl�chit ca n'a aucun sens. A moins que les cartes graphiques embarque un machine virtuelle. argh!

a) la simplicit� puisqu'on est oblig� de se prendre la t�te avec des optimisations,
des acc�s direct � je ne sais quoi, des transformations de tables Java en tables natives, etc.

La librairie opengl est d'une simplicit� � pleurer de bonheur, et s'integre parfaitement � un programme java.

b) le programme n'a plus l'universalit� que devrait fournir la JVM, puisque tu dois fournir
les bibli openGL (DLL ou .so) pour qu'il tourne. Il se trouve exactement dans la m�me
situation que n'importe quel programme compil�, en C++ ou autre, ce qui fait s'effondrer
tout le mod�le java

La diff�rence est que le code, lui est portable. Je n'ai pas � jouer avec le pr�processeur pour m'en sortir (cr�ation d'une fen�tre, basculement plein �cran, cr�ation des buffers, alignement et ordres des octets, utilisations de librairies de chargement d'images, gestion des E/S, threads lol, etc....)

Vrai ou faux ?

devines....

Je crois qu'il ne faut pas avancer comme cela des chiffres qui, si ils
ne sont pas faux en eux m�mes, ne repr�sentent pas ce qu'ils sont cens�s
repr�senter

pur d�sinformation car j'ai pr�cis� je ne sais combien de fois : ce sont des tests dans le domaines tr�s particulier des jeux vid�os. tu saisies maintenant. Alors c'est pas scientifique?
En plus je te signale que dans une appli graphique, on mesure le temps de calcul par frame. Opengl travaille en parall�le avec ton application. Pdt qu'opengl se d�brouille avec les polygones, toi tu peux faire des calculs d'IA, etc... Au final ca sert � quoi le c++? � avoir plus de temps libre pour ne rien faire?

Enfin, tout ce qu'on peut dire sur java n'est qu'une accumulation de pinaillage hein, donc j'arr�te la, et j'invite les personnes � lire l'excellente FAQ java disponible sur ce site, de m�me que les cours sur c++ et java (dont certains sous �crits par Ours Blanc Des carpathes alias Bruno Garcia, professeur fabuleux � l'isima, paix � son �me).

Pas tant que �a. ++gib affirme avoir d�crit un de ces benchmark, ainsi qu'une d�monstration. A part celle de l'asm, je n'en voit pas d'autre, j'ai peut-�tre rat� un post ou mal compris qq chose, dans ce cas je pr�sentes mes plus plattes excuses... Enfin soit, mon message allait plus dans le sens qu'il manquait un vrai benchmark..

J'ai du exhumer mon code du fond d'un r�pertoire, et le toiletter car un certain nombre
de choses �taient devenues "deprecated". Mais enfin, voici:

Comme certains ont l'air int�ress�s, et comme propos�,
voici un petit code qui permet de v�rifier ce que j'avance � propos
des vitesses respectives de Java et C++.

Pr�ambule
---------
Ce code ne fait appel aucune bibli (graphique ou autres) qui perturberait
la mesure car r�dig�e dans un autre langage.
Je me suis longuement expliqu� sur ceci dans mon dernier post.

J'ai essay� de r�aliser un �quilibre en mettant en oeuvre
- des types natifs (int, double)
- des types d�finis par l'utilisateur (on y trouve 2 classes)
- des conteneurs livr�s avec le langage (vector/Vector est le plus courant)

Conditions exp�rimentales
-------------------------
-J'ai sur mon bureau un P3 1GHz, sous Linux (Mandrake 9) 256Mb de ram
-Le compilateur Java est celui du JDK 1.3 de Sun,
la JVM est aussi celle du JDK.
-Le compilateur C++ est gcc version 3.2 livr� avec la distrib Mandrake 9.0

Les options de compilation sont:
java : aucune (celles que j'ai essay� n'am�liorent pas les perf)
gcc : -Wall -O1
-Wall sert juste � demander tous les warnings, et -O1 correspond �
une optimisation "standard". Elle fait toutefois un boulot �norme
et sa pr�sence est capitale.

Ces deux outils ne sont pas les plus performants dans leurs cr�neaux
respectifs, mais ils sont s�rieux et font r�f�rence.
(En ce qui concerne Java qui n'est pas normalis�, l'impl�mentation
de Sun est d'ailleurs la seule r�f�rence possible).


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.

Sommairement d�crit, cet algo fait une somme de produits vectoriels.
Les vecteurs utilis�s sont calcul�s � partir des sommets du polygone,
et on les obtient (en gros) en faisant la diff�rences des vecteurs de
position des sommets.
Le r�sultat cherch� (aire) est la moiti� de norme du vecteur somme.

On fait donc d'un point de vue purement calculatoire
-des soustraction / additions de doubles (calcul de vecteurs)
-des produits de doubles (produit vectoriels)
-une racine carr�e.

Les donn�es d'entr�e sont lues dans un fichier (essai.pol)
et les r�sultat sont affich�s � l'�cran. Le programme g�re
lui-m�me son chronometrage.

Le chronom�trage commence apr�s la lecture du fichier de donn�es et
s'ach�ve � l'affichage des r�sultats.

Le chronom�trage ne commence qu'apr�s le lancement du programme,
ce qui est � priori favorable au programme Java, car on �limine ainsi le
temps de chargement et de mise en route de la JVM, qui ne sont donc pas
pris en compte.

Mod�lisation objet
------------------
L'identification des concepts indique que l'on manipule

-des points dans l'espace (plus exactement des vecteurs de position)
-des polygones

Les classes d�velopp�es correspondent exactement � cette analyse.
Une classe annexe "application" a �t� developp�e en C++ pour �tre
conforme � l'esprit objet et une classe "FormattedIStream" en Java
pour faciliter la lecture du fichier de donn�es.
******
Je r�clame aux sp�cialistes de Java une solution permettant de se passer
de cette classe.
******
Aucune de ces deux classes ne participe ni n'influe de mani�re perceptible
sur les performances.

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.

En outre, j'ai essay� de trouver la programmation la plus performante,
sans c�der � la bidouille. Vous verrez que la m�thode Polygone.aire
comporte un code en commentaire qui est significativement moins
performant que celui qui a �t� retenu (mais plus facile � comprendre).

Le code Java est r�parti en 4 fichiers, le code C++ est dans un seul
fichier. L'appli est suffisamment petite pour que ce soit plus
simple comme �a, et ca vous permettra de compiler/linker en une seule
commande. Je recommande sous linux.
gcc -o aire -O1 -Wall aire.cpp -lstdc++

Pour java
javac *.java
java aire
devrait le faire.

====================CODE JAVA========================================

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
// fichier FormattedIStream.java
import java.io.* ;

// Flot d'entree formatte
//
// Je sollicite une solution pour lire le fichier de test
// sans utiliser  cette classe
//
class FormattedIStream extends StreamTokenizer
{
    private InputStreamReader ist ; 

    FormattedIStream( InputStreamReader is)
    {
        super(is) ;
        ist = is ;
        // Valide les "double" comme tokens
        parseNumbers() ; 
    }
    // Renvoie un double si il existe,
    // ou lance une exception
    double readDouble() throws IOException
    {

        if( nextToken()== TT_NUMBER )
            return nval ;
        else
        {
            pushBack() ;
            throw new IOException("No number on stream.") ;
        }

    }
    // Renvoie un int si il existe,
    // ou lance une exception
    int readInt() throws IOException
    {

        if( nextToken() == TT_NUMBER )
            return (int)nval ;
        else
        {
            pushBack() ;
            throw new IOException("No number on stream.") ;
        }

    }
    // Renvoie le prochain "mot"
    //
    // Exception si rien � lire ou pas de mot
    String readWord() throws IOException
    {
        if(nextToken() == TT_WORD )
            return  sval;
        else
            throw new IOException("No word on stream.") ;
    }
    //
    // Renvoie la prochaine ligne
    // Exception si rien � lire
    String readLine() throws IOException
    {
        int car ;
        StringBuffer b = new StringBuffer();

        while( (car = ist.read() ) != -1 && ( car != '\n'))
            b.append((char)car) ;

        return b.toString() ;
    }
    // 
    // V�rifie la pr�sence du caract�re code
    // le caractere est consomme si il est present
    // tout autre caractere est laisse sur le flot
    // retour : vrai si caractere present
    // Exception si rien � lire
    boolean testChar(int code)  throws IOException
    {
    	boolean yes ;
        if( nextToken() == code)
            yes =  true;
        else
        {
        	pushBack() ;
            yes =  false ;
        }
        return yes ;
    }
   
}
// ----------------------------------------------------------
// fichier Point3.java
import FormattedIStream ;   // Gib made.
import java.io.* ;       


// Classe Point3, et ses operateurs
class Point3
{
    private double x,y,z ;

    public Point3()
    {
        x = y = z = 0.0 ;
    }
    public Point3(double xx, double yy, double zz)
    {
        x = xx ; y = yy ; z = zz ;
    }

    public String toString()
    {
        return x + " " + y + " " + z ;
    }

    public void readPoint3(FormattedIStream f) throws IOException
    {
        x = f.readDouble() ;
        y = f.readDouble() ;
        z = f.readDouble() ;
    }

    public void writePoint3(OutputStreamWriter os) throws IOException
    {
        String s = toString() ;

        os.write(s,0,s.length()) ;
    }

    public Point3 somme( Point3 p2)
    {
        return new Point3(x+p2.x, y+p2.y, z+p2.z) ;
    }

    public Point3 diff( Point3 p2)
    {
        return new Point3(x-p2.x, y-p2.y, z-p2.z) ;
    }

    public Point3 pvect( Point3 p2)
    {
        Point3 p = new Point3() ;

        p.x = y*p2.z - z*p2.y ;
        p.y = -(x*p2.z - z*p2.x) ;
        p.z = x*p2.y - y*p2.x ;

        return p ;
    }
    public double norme()
    {
        return Math.sqrt(x*x + y*y + z*z) ;
    }

    public Point3 dup()
    {
        return new Point3(x, y, z) ;
    }

}
// ---------------------------------------------------------------
// fichier polygone.java
//
// Representation d'un polygone 
// Cette version utilise le conteneur  Vector
// 
import Point3 ;
import java.io.* ;
import java.util.* ;

class Polygone extends Vector
{

    Polygone(int n)
    {
		super(5) ;	
    }

    public boolean addPoint3(Point3 p)
    {
        addElement(p.dup()) ; // dup evite les donnees partagees
        return true ;
    }
	//
    // Il y a ici un mystere : d'apres la doc du JDK, elementAt() 
    // est cense lancer ArrayIndexOutOfBoundsException.
    // comme at() ne traite pas l'exception et qu'elle
    // ne la transmet pas non plus, elle ne devrait pas compiler ..
    // Or, elle compile tres bien avec le compilo de Sun
    // J'ai du rater une marche quelque part
    //
    public Point3 at(int i)
    {
            return (Point3)elementAt(i) ;
    }

    public void readPolygone(FormattedIStream f) throws IOException
    {            
    	f.ordinaryChar((int)';') ; // ; est un token pour ce flot

        removeAllElements();
    
        Point3 p = new Point3() ;
        try
        {
            for( ; ;)
            {
                p.readPoint3(f) ; addPoint3(p) ;
            }
        }

        catch(IOException e)
        {
            // on arrive ici si on ne peut plus lire
            // en fait, il n'y a rien de special a faire.
        }

        if( ! f.testChar((int)';') )
            throw new IOException("Polygone: ';' not found or syntax error in coordinates.") ;

    }

    public void writePolygone(OutputStreamWriter os) throws IOException
    {
        int i ;

        for&#40;i = 0 ; i < size&#40;&#41; ; ++i&#41;
        &#123;
            at&#40;i&#41;.writePoint3&#40;os&#41; ;
            os.write&#40;"  ",0,2&#41; ;
        &#125;
        os.write&#40;";",0,1&#41; ;
        os.flush&#40;&#41; ;
    &#125;

    public double aire&#40;&#41;
    &#123;
        Point3 som = new Point3&#40;&#41; , p0, p1, p2 ;

        if&#40; size&#40;&#41; > 2&#41;
	    &#123;
        /*  // acces par index, grace � la methode at&#40;int&#41;
	        p0 = at&#40;0&#41; ;
		    for&#40;int i = 1 ; i < size&#40;&#41;-1 ; ++i&#41;
		    &#123;
			    som = 
                som.somme&#40; &#40;&#40;at&#40;i&#41;.diff&#40; p0&#41;&#41;.pvect&#40;&#40;at&#40;i+1&#41;.diff&#40; p0&#41;&#41; &#41;&#41; &#41;;
		    &#125;
        */
        
        	// acces par iterateur
        	Enumeration e = elements&#40;&#41; ;
            p0 = &#40;Point3&#41;e.nextElement&#40;&#41; ;
            p1 = &#40;Point3&#41;e.nextElement&#40;&#41; ;
            for&#40; ; e.hasMoreElements&#40;&#41; ; &#41;
            &#123;
            	p2 = &#40;Point3&#41;e.nextElement&#40;&#41; ;
			    som = 
                som.somme&#40; &#40;p1.diff&#40; p0&#41;&#41;.pvect&#40;p2.diff&#40;p0&#41; &#41; &#41; ;
                p1 = p2 ;
		    &#125;
                
		&#125;
	    return 0.5 * som.norme&#40;&#41; ;
	&#125;
&#125;
// ---------------------------------------------------------------
// fichier aire.java
import java.io.* ;
import FormattedIStream ;
import java.util.* ;

class aire
&#123;
    static public void main&#40;String args&#91;&#93;&#41;
    &#123;
        double x = -1;
        long i = -1 , imax = 10000000L ;


        try
        &#123;
            InputStreamReader f = 
            	new InputStreamReader&#40;new FileInputStream&#40;"essai.pol"&#41;&#41; ;
            FormattedIStream fis = new FormattedIStream&#40;f&#41; ;

            double a = 0;

            Polygone pol = new Polygone&#40;1000&#41; ;

            pol.readPolygone&#40;fis&#41; ;

            Date date = new Date&#40;&#41; ; // top chrono ..
			OutputStreamWriter os = new OutputStreamWriter&#40;System.out&#41; ;
            
            System.out.println&#40; "\nNb de points du polygone &#58;" + pol.size&#40;&#41; &#41; ;              pol.writePolygone&#40;os&#41; ;

            for&#40; i = 0 ; i < imax ; ++i&#41;
                a = pol.aire&#40;&#41; ;
            System.out.println&#40; "\nNb d'iterations &#58;" + imax &#41; ;
            System.out.println&#40; "Aire &#58; " + a &#41; ;
            System.out.println&#40; "Temps ecoule &#58; &#40;" + imax + " iterations&#41; " +
                + &#40;new Date&#40;&#41;.getTime&#40;&#41;-date.getTime&#40;&#41;&#41;/1000 + " secondes"&#41; ;
            System.out.flush&#40;&#41; ;
        &#125;
							
 
        catch&#40;Exception e&#41;
        &#123;
                System.out.println&#40;"Exception&#58; " + e.toString&#40;&#41;
                        + "\n" &#41; ;
        &#125;
    &#125;
&#125;

================================================================== =
CODE C++

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
//
// Calcul de l'aire d'un polygone plan
// dans l'espace -  Sept 97
//
// =============================================
//
#include <stdexcept>
#include <string>
#include <iostream>
#include <fstream>	
#include <math.h>	// pour sqrt()
#include <time.h>	// pour time()
#include <vector>

using  namespace std ;

// Definition d'une exception "maison"
class read_error : public runtime_error
{
public:
    read_error(string s) : runtime_error(s) {}
} ;
// =============================================
// Representation d'un point
// (comme etant un vecteur de position)
// Seuls les operateurs utiles a notre application
// ont ete implantes.
class point3
{
private:
    double x,y,z ;
    void copy(const point3& pp) // fct de service
    { x = pp.x ; y = pp.y ; z = pp.z ; }
public:
        
    point3(double xx=0, double yy= 0, double zz=0) 
	{
        x = xx ; y = yy ; z = zz ;
    }

    // contructeur de clonage (inutile)
    point3(const point3& pp) { copy(pp) ; }
    // destructeur (inutile)
    ~point3() {}

    // operateur d'affectation (inutile)
    point3& operator=(const point3& pp) { copy(pp) ; return *this ; }
    
    // addition de vecteurs
    point3 operator+(const point3& pp) const
    {
        return point3(x+pp.x, y+pp.y, z+pp.z) ;
    }
    // soustraction de vecteurs
    point3 operator-(const point3& pp) const
    {
        return point3(x-pp.x, y-pp.y, z-pp.z);
    }
    // produit vectoriel
    point3 operator^(const point3& pp) const
    {
        double xx,yy,zz ;

        xx = y*pp.z - z*pp.y ;
        yy = -(x*pp.z - z*pp.x );
        zz = x*pp.y - y*pp.x ;

        return point3(xx,yy,zz) ;
    }
    // norme d'un vecteur
    double norme() const
    {
        return sqrt( x*x + y*y + z*z) ;
    }
    // operateurs d'entrees/sorties (ce sont des fct amies)
    friend ostream& operator<<(ostream& o, const point3& pp) ;
    friend istream& operator>>(istream& i,  point3& pp) ;
} ;
//
// ___________________________________________________________
// Les methodes de point3 etant toutes "inline"
// l'implementation se reduit aux 2 fct amies d'E/S
//
ostream& operator<<(ostream& o, const point3& pp)
{
    return o <<  pp.x << ' ' << pp.y << ' ' << pp.z   ;
}
// ___________________________________________________________
// Les points sont supposes etre formattes
// sous la forme :     x y z
// (avec des blancs ou des tab ou des newline entre les coord.)
istream& operator>>(istream& i, point3& pp)
{
    double xx,yy,zz ;

    if(	(i>>xx) && (i>>yy) && (i>>zz) )
    {
        pp.x = xx ; pp.y = yy ; pp.z = zz ;
    }
    return i  ;
}

// ==========================================================
// Representation d'un polygone
//
// C'est un ensemble FINI, ORDONNE de points
// construit par derivation d'un conteneur standard de la stl
// (vector ou list)
//
class polygone : public vector<point3>
{
public:
    double aire() const ;
    friend ostream& operator<<(ostream& o , polygone& pp) ;
    friend istream& operator>>(istream& i, polygone& pp) throw (read_error);

} ;


ostream& operator<<(ostream& o , polygone& pp)
{
    polygone::iterator i ;

    for(i = pp.begin() ; i != pp.end() ; ++i)
        o << *i << "  "  ;
    return o << ";" << flush ;
}

// ___________________________________________________________
// Operateur d'entree: Un polygone est suppose etre
// formatte sous la forme
// x0 y0 z0 x1 y1 z1 .... xn yn zn ;
// (le ; est obligatoire)
istream& operator>>(istream& i, polygone& pp) throw (read_error)
{
    point3 p ;

    pp.clear() ;	// vide le polygone
    for(  ; (i >> p)  ; )
    {
        pp.insert(pp.end(), p)  ;
    }
    // remettre le flot dans l'etat good
    i.clear() ;
    // lire le separateur ;
    // si il n'est pas present,
    // on met le flot en erreur
    char c = 0;
    if( !(i >> c))
    {   // pas de delimiteur
        throw read_error("Lecture polygone : "
                         "delimiteur  absent") ;
    }
    else if(c != ';') 
    {   // mauvais d�limiteur
        i.putback(c) ;
        i.clear(ios::failbit) ; // mettre le flot en etat fail
        throw read_error("Lecture polygone : "
                         "delimiteur incorrect") ;
    }
    return i ;
}
//
// ___________________________________________________________
// calcul de l'aire d'un polygone
// il s'agit d'une traduction directe de la
// formule mathematique
//
double polygone::aire() const
{
    point3 som  ;

    if( size() > 2)
    {
    
        const_iterator i = begin(), ip1  ;
        const point3 &first = *i ;

        for( ++i, ip1 = i+1 ; ip1 != end() ; ++i, ++ip1)
        {
            som = som + ((*i - first) ^ (*ip1 - first)) ;
        }
    }
    return 0.5 * som.norme() ;
}

// ================================================================
// Voici notre application
//
class appli
{
public:
    // test sur donnees lues dans un fichier, avec chrono
    void start() ;
} ;


// ___________________________________________________________
void appli::start()
{
    polygone p  ;
    ifstream f("essai.pol") ;	// ouvrir fichier "essai.pol"
    time_t t ;					// heure, en secondes
    double a ;
    long imax = 100000000 ;

    try
    {

        if( f.is_open() )
        {	// ouverture reussie
            f >> p ; // lire polygone
            
            t = time(NULL) ; // depart chrono

            cout	<< "\nNb de points du polygone : "
            << p.size() << endl << p <<  "\naire : "
            << flush ;
            // beaucoup de calculs, pour que
            // le temps soit mesurable
            for( long i = 0 ; i < imax ; ++i)
                a=p.aire() ;

            cout << a << flush ;

            cout << "\nTemps ecoule: (" << imax << " iterations) " 
            << time(NULL) - t
            << " secondes.\n"  << flush ; // arret chrono et affichage
        }
        else
            cout << "\nPb ouverture fichier de test" << flush ;
    }

    catch(exception& e)
    {
        cout << "Exception  ("
        << e.what() << ")" << endl << flush ;
    }

}

// ___________________________________________________________
// main ne sert qu'a lancer l'application
int main()
{
    appli benchmark ;

    benchmark.start() ;

    return 0 ;
}

Le fichier de donn�es essai.pol (c'est un carr� de cot� 10 unit�s,
donc on doit obtenir une aire de 100 unit�s-carr�.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
0 0 0
0 10 0
0 10 10
0 0 10  ;

Remarques sur le code
---------------------
Le code C++ est beaucoup plus court (250 lignes contre 315), en partie
� cause de la classe FormattedIStream.
Je n'ai pratiquement pas mis de commentaires dans le code Java, un peu dans
le code C++. Je pense qu'ils sont tous les deux faciles � comprendre,
mais le code C++ est plus �l�gant gr�ce � l'usage d'op�rateurs.
(Voir par exemple la fonction qui calcule l'aire)

Bien que ceci ne soit pas un soft de production mais juste de d�monstration
j'ai envie qu'il soit correct.
Vous �tes donc invit�s � me signaler d'�ventuels bugs ou maladresses.

Les E/S ont �t� �crites assez rapidement, et utilisent davantage les exceptions
en Java qu'en C++. Ceci est du au fait qu'il est traditionnel de
r�cuperer les erreur de lecture en C++ sans exceptions, alors que c'est le
contraire en Java. Pour montrer que �a ne pose pas de probl�me, la classe
C++ polygone lance une erreur de lecture si la lecture du polygone echoue.
Je ne me suis pas concentr� sur ce point, qui est pour l'instant hors-sujet.

Le programme C++ fonctionne � l'identique en rempla�ant vector par list,
gr�ce � l'utilisation des it�rateurs. Je suppose qu'il en va de m�me en Java
mais je n'ai pas v�rifi�. Qui veut le faire ?


R�sultats
---------
Java:
10000000 (10 puissance 7 ) polygones � 4 sommets en 24 secondes

C++:
100000000 (10 puissance 8 ) polygones � 4 sommets en 20 secondes
(J'ai �t� oblig� de multiplier le nb d'it�rations par 10 pour avoir plus de
pr�cision).

On � donc un rapport de 24/2 = 12

Ceci est conforme (et au del�) � ce que j'avais annonc�,
puisque j'ai parl� d'un rapport 10. Je suis conscient que selon
les outils, on peut avoir des r�sultats diff�rents, mais ils
devraient rester du m�me ordre.

Je me suis �galement int�ress� au comportement du programme
lorsque le nombre de points du polygone augmente.
Voici le r�sultat en secondes.
(j'ai ramen� a 10000000 it�rations par division les perf du C++):

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
Points   C++       Java      Rapport
------------------------------------
4        2.0       24        12
8        3.9       60        15.38
16       7.7       140       18.18
32       15.1      277       18.34
64       30.1      570       18.93

Il est � remarquer que
- le comportement du C++ est lin�aire par rapport au nb de points.
(il a m�me tendence � s'am�liorer lorsque le nb de points augmente)
- � l'inverse, le comportement du prgm Java se d�grade et tend
apparemment vers un rapport 19

Mon interpr�tation est bas�e sur le fait que l'augmentation du nb de points
a tendance � faire diminuer l'influence relative de la boucle principale
sur l'ensemble du temps. Or cette boucle manipule essenciellement un int
donc une donn�e native. Ce genre de manipulation est le plus rapide car il
n'y a pas de mod�le objet � g�rer (juste le co�t d'interpr�tation
du byte-code).
Lorsque le programme manipule des objets
les performances se d�gradent, ce qui me semble logique, mais
est facheux pour un langage � objets.
Ceci n'est toutefois qu'une id�e, et demanderai � �tre �tudi� plus finement.

En C++, le surco�t de l'objet est presque nul, ce qui explique un
comportement plus lin�aire.

Voila, j'ai essay� d'�tre complet,
j'attends vos remarques, qui ne devraient pas tarder � pleuvoir.

Merci de m'avoir lu.

(En ce qui concerne Java qui n'est pas normalis�, l'impl�mentation
de Sun est d'ailleurs la seule r�f�rence possible).

? QUOI ?
Voila tout ce que tu dois savoir pour ecrire un compilateur ou une machine virtuel : http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html
Si tu veux des infos sur l'api, il faut matter le javadoc.

// Il y a ici un mystere : d'apres la doc du JDK, elementAt()
// est cense lancer ArrayIndexOutOfBoundsException.
// comme at() ne traite pas l'exception et qu'elle
// ne la transmet pas non plus, elle ne devrait pas compiler ..
// Or, elle compile tres bien avec le compilo de Sun
// J'ai du rater une marche quelque part

Rien de plus normale... La reponse a ce mist�re est expliquer dans le ... Javadoc evidement !
http://java.sun.com/j2se/1.4/docs/api/java/lang/RuntimeException.html
Tu voudrais quand meme pas qu'on soit obliger de tagger toutes les classes comme pouvant produire un NullPointerException ?


Tu n'est pas programmeur C++ pour rien... Je ne vois pas trop l'interet d'h�rit� de la classe Vector. L'utilisation de Vector est a r�serv� exclusivement pour de l'acces Multi-Thread, ce n'est pas le cas, donc on utilise ArrayList. Et pour une structure de donn�e de taille fixe, preferrera utiliser un tableau...


La difference de 2 points dans l'espace donne ... un point dans l'espace... Bof !
Perso je recoderais la fonction pvect pour prendre 4 points et faire le calcul, on economise la construction 2 object intermediaire et on a un object qui ressemble a quelque chose.

A la place de la salle fonction dup, je ferais plutot un constructeur de recopie, c'est quand meme plus �l�gant.


Tu voulais des exemples d'application Java, voila ceux qui tourne tout le temps sur mon PC :
-> Eclipse, Ide Java open source ( projet initi� par IBM )
-> Jext, un editeur de texte open source
-> Une interface graphique pour un client p2p.
-> Un jeu d'echec
...

D'autre gros projet :
->JBuilder, IDE java de Borland
-> NetBeans, IDE java open source (de Sun)
Je sais, il y a beaucoup d'IDE, mais Java est surtout utilis� pour le developpement des logiciel interne au entreprise, pas trop pour les application a destination des client.

Autre example concret :
L'application de gestion de la securit� sociale Br�silienne, c'est du 100% Java, toute la chaine en partant de la carte a puce (equivalent de la carte vital) jusqu'au serveur d'application, en passant par les logiciel de traitement des medessin... 12 Millions de personnes.
On estime aussi a 35 Millions le nombre de telephone portable bas� sur J2ME.
(source Login

ORACLE (qui n'est tout de m�me pas un petit novice), �crit �galement ses interfaces en java (en tout cas celles que j'ai pu voir, ptet pas celles d'y a quelques ann�es)... Mais je crois que ca ne vaut pas la peine d'en rajouter car de toute mani�re la discussion a d�j� �t� ferm�e avant qu'elle puisse commencer avec la phrase ([quote]Alors je poserai la question : en quoi est �crit le moteur qui anime tout �a ?
)

Je voudrais �galment rajouter � propos du code, que j'essaie de d�cortiquer (du code c++ �crit en java) pour l'instant, comporte �galement quelques m�thodes totalement inutilis�es (il y a m�me des m�thodes qui �taient d�j� en remarque...) ce qui r�duit d�j� grandement la diff�rence de nombre de lignes de code... (soit une 50ene de lignes pour l'instant soit plus de la moiti� de la diff�rence, je n'ai pas compt� les remarques personelles, qui concernant java, et non le code la dedans...).

En r�ponse � la longueur du code + quelques critiques en passant...
Pour les m�thodes :
-------------------------------------------------------------------

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Renvoie un int si il existe,
    // ou lance une exception
    /*
    int readInt() throws IOException
    {
        if( nextToken() == TT_NUMBER )
            return (int)nval ;
        else
        {
            pushBack() ;
            throw new IOException("No number on stream.") ;
        }

    }

et -------------------------------------------------------------------

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
//
    // Renvoie la prochaine ligne
    // Exception si rien � lire
    /*
    String readLine() throws IOException
    {
        int car ;
        StringBuffer b = new StringBuffer();

        while( (car = ist.read() ) != -1 && ( car != '\n'))
            b.append((char)car) ;

        return b.toString() ;
    }
    */

C'est bien de pr�voir mais quand on fait des remarques p/r � la longueur du code....
-------------------------------------------------------------------

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
/*  // acces par index, grace � la methode at(int)
           p0 = at(0) ;
          for(int i = 1 ; i < size()-1 ; ++i)
          {
             som =
                som.somme( ((at(i).diff( p0)).pvect((at(i+1).diff( p0)) )) );
          }
        */

Remarques ??? ou oubli???
------------------------------

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
   
public /*boolean*/void addPoint3(Point3 p){
        buffer.addElement(p.dub()) ; // dup evite les donnees partagees
//        return true ;
    }

Evidemment on peut rajouter des trucs mais si ca ne vaut pas la peine ...
---------------------

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 try
        {
            for( ; ;){
                p.readPoint3(stream) ;
                addPoint3(p) ;
            }
        }

        catch(IOException e)
        {
            // on arrive ici si on ne peut plus lire
            // en fait, il n'y a rien de special a faire.
        }

Personellement je ne programme pas avec des for( ; ; ) qui lancent des exceptions � l'int�rieur du bloc... Sans doute une pratique c++sienne. Mais ce code se r�sume � 3- 4 lignes si c'est bien cod�... Sans doute que java n'a pas encore permis d'uitliser le goto, alors il faut utilser des rustines...

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
double x = -1;

...Dans la methode main .. j'ai pas compris � quoi ca servait

Les remarques personelles ne concernant pas le code :

// Il y a ici un mystere : d'apres la doc du JDK, elementAt()
// est cense lancer ArrayIndexOutOfBoundsException.
// comme at() ne traite pas l'exception et qu'elle
// ne la transmet pas non plus, elle ne devrait pas compiler ..
// Or, elle compile tres bien avec le compilo de Sun
// J'ai du rater une marche quelque part
//


Concernant le code lui-m�me, d�j� une am�lioration � faire... Dans une de tes boucles dans la classe Polygone tu cr�e sans cesse Enumeration (m�thode aire)... En remplacant ca par un tableau que tu cr�es une fois pour toute dans ta m�thode readPolygone, ca reduit d�j� le temps d'ex�cution. Donc autrement dit pas besoin d'h�riter de Vector, qui pour moi n'est pas une tres bonne id�e dans ce cas... suite peut etre dans un prochain �pisode

Pour le programme java :
sur ma machine (XP2200,512meg)ca prend 9 secondes

Apr�s avoir bidouill� un peu dans le code java, j'ai pu constat� que la lenteur de ton programme ne provient m�me pas des calculs. Bizarre non? Effectivement, j'ai �limin� tous les calculs du programme et c'�tait toujours aussi lent... En cherchant un peu j'ai remarqu� que dans ta classe point3, et cela � peu pr�s dans toutes ses m�thodes, tu recr�ais un objet point3. J'ai remani� un peu le code et en ne cr�ant plus de Point3 � chaque m�thode je tombe � 2 secondes (avec le retrait de l'Enumeration qui tu utilisait dans la classe Polygone). Comme quoi, la 'lenteur' de java vient peut-�tre de la fa�on de programmer, mais �a � mon avis c'est dans tous les langages. En l'occurance, ici il n'y avait vraiment pas besoin de cr�er un instance de Point � chaque m�thode (pour moi c'est une erreur de conception de la classe Point3 ou une mauvaise connaissance et/ou d'utilisation de l'objet)... Il faudrait donc revoir tes statistiques de performances c++/java un peu � la baisse...

Je mettrai le code remani� des que j'aurai fini...

enfin un benchmark!

m�me remarques que Cl�ment et gregy:

-La classe Vector est pr�vue pour le multi-threading car les m�thodes sont synchronis�es.
-A mon avis l'allocation dynamique d'un nouveau Point3 � chaque op�ration provoque une saturation du garbage-collector. En c++ les calculs sont fait sur la pile donc la m�moire n'est pas trop sollicit�.
En r��crivant les m�thodes pour faire en sorte de ne travailler qu'avec une instance le gain peut d�passer 300% (c'est ce que j'ai remarqu� dans mon appli et c'est ce qu'a remarqu� gregy). un peu comme ce que j'ai propos� dans un autre message. De plus un appel � new impose une synchronisation avec le garbage-collector.

Avec tout ca je trouve que java se d�brouille plutot bien non ? Maintenant il faudrait refaire les tests.
Il est a not� que la jre IBM 1.4 sous linux est bien plus rapide et plus optimis�e pour le calcul que celle de sun.

J'ajoute aussi que faire une boucle de 10^8 c'est pas tip top si les donn�es sont toujours les m�mes car tu favorises le cache m�moire. En plus ce n'est pas vraiment repr�sentatif d'une vraie appli de calcul scientifique.Java se d�brouille bcp mieux lorsque la taille de la donn�e � traiter augmente. Tu remarqueras que plus tu augmente la taille du polygone plus le ratio tend � se stabiliser....

J'ai effectu� les benchmarks plus pouss�s en analyse num�rique propos�s sur le site de Scimark 2. On peut y r�cup�rer le code en c et le code java et comparer ses r�sultats avec ceux dans la base. On peut lancer les tests avec une taille normale et avec une taille large des donn�es.

On remarque que java se d�brouille mieux si la taille des donn�es augmentent. C'est � dire lorsque les calculs sortent du cache m�moire. Java g�re mieux la m�moire apparemment.

Quant � dire si java est plus rapide que le c cela d�pend bien sur de votre machine mais il y a plus de chance avec la jre IBM 1.4 sous Linux et un pentium 4 ou un amd athlon. Voili voila.

perso j'obtient sur un pentium 4 1.7GHz win2K et jre sun 1.4:
java normal : 129 MFlops
c normal : 260 MFlops
java large : 85 MFlops
c large : 91 MFlops

sur un amd 1800+ linux mandrake 9 et jre ibm 1.4:
java normal : 251 MFlops
c normal : 290 MFlops
java large : 123 MFlops
c large : 128 MFlops

compil� en c avec gcc dans les deux cas avec l'option -03

->Les ordinateurs sont de plus en plus puissants donc la rapidit� d'ex�cution est de moins en moins un probl�me.
Par piti� n'employez pas des banalit�s et idioties de ce genre !!
Qui dit machine plus rapide dit machine faisant tourner des applis plus rapidement que sur d'autres machines .
Donc gaspillage ENORME au niveau performances.
Donc environnement de d�veloppement ( Java en l'occurence puisque c'est Java dont on parle) peu optimis� ou peu ad�quat pour le d�veloppement informatique.
Des machines plus puissantes ????
J'en viens � me poser la question de savoir � l'heure de .NET ou Java si je ne vais pas me remettre � l'assembleur !
Je fais une appli de cartographie sous Windows avec API 32 et m�me ce n'est pas assez performant !
Pour faire n'importe quel calcul en virgule flottante ou sur des matrices ou je ne sais quoi ,oui Java peut-�tre plus performant et rapide que le C++.
Mais tous les tests de comparaisons expos�s pr�cedemment sont en ligne de commandes.
Et pour afficher une fen�tre avec boutons et zones de textes tout le monde sait que �a rame en Java !

Envoy� par Gr�gory Picavet

C++

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
void f(int a, float b) {
}
int main(int, char **)
{
    f(0, 0.5);
}

compil� avec gcc : aucun warning

JAVA

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
class Test {
    public static void f(int a, float b) {
    }

    public static void main(String[] args) {
        f(0,0.5);
    }
}

test.java:7: f(int,float) in Test cannot be applied to (int,double)
f(0,0.5);
^
1 error

Ton analyse est compl�tement fausse parceque superficielle.
Le compilateur n'a pas "n�glig�" de v�rifier les param�tres, il les a convertis !
Pour v�rifier que le compilo ne prend pas les float pour des double
, rempla�ons le passage par valeur par un passage par r�f�rence.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
void f(float& k)
{
}

void g()
{
  double x = 0;
  f(x) ;
}

gcc -c conversions.cpp
conversions.cpp: In function `void g()':
conversions.cpp:8: could not convert `x' to `float&'
conversions.cpp:2: in passing argument 1 of `void f(float&)'

Si tu avais pouss� un peu plus tes tests, tu aurais vu que la valeur re�ue
par Test �tait correcte dans l'exemple que tu donnes,
donc que le double a bien �t� converti en float.
En r�sum�, pas d'erreur, ni � la compil, ni � l'exec.

Bon, ceci �tant dit, je d�veloppe.

S�mantiquement, un passage de param�tres par valeur est tr�s proche
d'une affectation(1) : le parametre r�el est affect� au param�tre formel.
Si le param�tre r�el peut etre "raisonnablement" converti vers le type du
param�tre formel compte tenu de ce qu'il connait de ces types, le compilo le fait.

Dans le contre-exemple que je donne pour monter que C++ v�rifie bien les types,
, ce n'est �videmment pas possible, car le passage par r�f�rence
(physiquement: par adresse)
conduirait la fonction f() � croire qu'elle re�oit un pointeur sur
un float alors l'objet point� est un double.
Foirage garanti, d'ou cette fois-ci erreur de compil
(et pas de warning, car �a ne PEUT PAS marcher, c'est donc bien un bug).

La v�ritable question soulev�e par ton intervention, ce n'est donc pas la v�rification
de type lors des appels de fonctions, c'est la d�cision de faire une conversion
de type ou non.

Tu vas bien sur objecter que �a ne change rien au fait que le passage du double
� la place du float peut provoquer un d�bordement, donc une erreur.
Cela peut effectivement se produire, de la m�me fa�on que �a peut se produire dans
n'importe quelle expression m�me homog�ne du point de vue des types.
Par exemple dans:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
	public  void testDebordement()
	{
    	  int i = 0  ;
          long k = 0  ;

          i =  Integer.MAX_VALUE  + 10 ;
          i = k ;
	}

x.java:30: possible loss of precision
found   : long
required: int
        i = k ;
            ^
1 error

La premi�re affectation est acc�pt�e parcequ'elle est homog�ne du point de vue du type
(alors m�me qu'elle ne donnera pas le r�sultat attendu !)
alors que la seconde est rejet�e (alors qu'elle fonctionnerait parfaitement).
Cette absurdit� montre les limites du typage dans ce cadre, et c'est pour
�a que C++ n'utilise pas le typage comme cela.

J'ai ainsi d�montr� que le refus de conversion entre type compatibles dans une affectation
n'est ni n�cessaire, ni suffisant pour �viter les ennuis.
Et il en va de m�me lors d'un passage d'argument par valeur, car celui-ci est une
affectation.
Par exemple si f re�oit un int :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
	f(Integer.MAX_VALUE  + 10) ; // Aie .....

on peut pr�voir de gros probl�mes dans f() alors m�me que tout semble correct
lors de la v�rification de type.
Non seulement ce genre d'utilisation du typage est inefficace,
mais en plus elle est pernicieuse dans la mesure
ou elle est de nature � donner une fausse impression de s�curit�.

L� ou �a devient comique, c'est que Java pratique la conversion pour les op�randes
d'op�rateurs arithm�tiques, mais pas pour l'affectation. Or "=" est bien un op�rateur
(et non une instruction). Il y a l� un comportement "non orthogonal", dict� evidemment
par le d�sir d'am�liorer la "s�curit�".

par exemple dans

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
int i = 0 ;
i = i + 3L ; // ne compile pas

La valeur de i est convertie en long avant l'addition, et le resultat est de type long.
L'affectation est donc
refus�e, au nom d'une doctrine qui dit qu'on ne peut affecter un long � un int sous peine
que tout vous saute � la figure.

Arriv� � ce point de ma r�flexion, et ayant constat� la diff�rence de traitement profonde
entre les deux op�rateurs, j'ai essay� ceci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
int i = 0 ;
i += 2147483648L ; // compile parfaitement

Ben oui, tu dois �tre d��u, �a compile tr�s bien. Le code donnant un r�sultat correct
ne compile pas et celui qui compile va �chouer lamentablement � l'ex�cution.
(Les deux codes faisant la m�me chose, du moins d'un point de vue logique)
Croustillant non ? Ceci montre que la conception du langage est incoh�rente.

Les concepteurs ont fait le choix d'autoriser l'affectation dans ce contexte.
OK ! , mais ils auraient fait l'autre, �a aurait �t� aussi mauvais :
comment expliquer � un programmeur qu'on peut additionner un int et un long
avec + et pas avec += ?

Il est cocasse de constater qu'ils ont choisi la rustine la moins voyante,
mais aussi la moins s�re. Bravo pour un langage qui proclame haut et fort
qu'il pratique un "typage fort".


Ceci montre s'il en �tait encore besoin que l'usage du typage fait par Java pour
assurer les conversions est mauvais.
Et je crois qu'il est mauvais car il est dogmatique.
Les probl�mes de conversion sont des probl�mes s�mantiques ardus. Qui peut r�ellement
d�cider si un type X peut �tre converti en Y dans telle ou telle condition, sinon
le programmeur ? Croire qu'appliquer des r�gles simplistes telles "on ne peut affecter
un double � un float sous peine de compromettre la s�curit�" permet de traiter ce genre de
questions est une tromperie intellectuelle et une �nerie technique.

Voila pour l'approche du probl�me des conversions entre types de base.
Pour les types d�finis par l'utilisateur, c'est le n�ant :
Pas de conversion possible (encore un manque d'orthogonalit� par rapport aux
types de base), sauf la conversion d'un type d�riv� vers un type plus "basique",
ce qui est une �vidence en programmation objet.
L'approche Java des v�ritables probl�mes est toujours la m�me :
circulez, rien � voir.


Au lieu de cela, C++ part du principe que les conversions sont dangereuses,
mais pas plus que n'importe quelle autre op�ration,
comme je viens de le d�montrer.
On doit donc les int�grer dans l'ensemble du processus calculatoire du programme,
comme un op�rateur de plus.
Et C++ offre des outils pour cela (conversion par op�rateur, conversion par construction)
qui permettent de pr�ciser la s�mantique de conversion (donc d'en augmenter la s�curit�).
Lorsque la conversion automatique est r�ellement probl�matique, il est possible
de demander au programmeur de prendre ses responsabilit�s (mot cl� explicit).
Enfin, si le transtypage est impossible ou ambigu, C++ te jette, ce qui est une autre mani�re de te faire prendre tes responsabilit�s.


Mais allons plus loin:
Je pense que le design de Java � ce niveau va bloquer l'�volution du langage
sur un point au moins.
Supposons que sous la pression des utilisateurs, SUN veuille ajouter la d�finition
d'op�rateurs dans les classes. Pourquoi pas ?

a+b sera alors interpr�t� comme quelque chose comme operator+(a,b), comme c'est
le cas en C++ ou en ADA.
Si a et b sont de types diff�rents, mais potentiellement compatibles, que faire ?
a) Refuser l'expression. Ce serait incoherent par rapport aux types pr�d�finis
sur lequels Java pratique des conversions.
b) Convertir les param�tres r�els de operator+() vers le type du param�tre formel
correspondant. C'est ce que fait C++.
Normalement, et pour �tre coh�rent avec l'application actuelle du typage sur
les param�tres de fonctions, c'est "impossible" en Java.
c) Exiger un transtypage manuel. Ceci conduit � un code du style
X x = (X)a + (X)b ;
Bonjour le codage! ce n'est pas marrant � utiliser, et ca fait exactement
ce que fait la solution pr�c�dente de fa�on automatique.


(1) en fait, il s'agit plus pr�cis�ment d'une construction.

option -pedantic-errors la bien nomm�e

si bien nomm�e que TOUS les warnings deviennent des erreurs...tip-top!

Ma foi, comme tu sembles d�sirer �tre matern� au point de ne pas vouloir d�cider
si un warning vaut la peine d'�tre pris en compte, �a me semble parfait.

Ca n'a pas grand chose � voir avec le langage

ca a � voir si le langage est strict ou pas

Allons, pas de mauvais esprit! Il y a dans javac une option -nowarn
pour supprimer les warnings, �a ne change rien au langage !

il a raison, ce n'est pas
forc�ment un probl�me

Va dire ca aux programmeurs qui font un peu de calcul scientifique.

Mince ! Pour une fois que je donne raison � un compilateur Java,
je me fais tacler ! Tu n'aurais pas un argument un peu moins lapidaire
et un peu plus clair ?

apr�s c'est au programmeur de prendre ses responsabilit�s.

c'est la philosophie du c++, en effet. Y'a rien � dire de plus

Le philosophie du C++, c'est surtout de ne pas prendre les programmeurs
pour des imb�ciles en leur faisant prendre des vessies pour des lanternes.

quote]

Envoy� par Clement Cunin

(En ce qui concerne Java qui n'est pas normalis�, l'impl�mentation
de Sun est d'ailleurs la seule r�f�rence possible).

? QUOI ?
Voila tout ce que tu dois savoir pour ecrire un compilateur ou une machine virtuel : http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html
Si tu veux des infos sur l'api, il faut matter le javadoc.

Vous n'avez pas l'air de savoir ce qu'est 'une norme.
Le document propos� est une sp�cification SUN, rien de plus.
Une norme est �labor�e de fa�on publique par un comit� genre ISO, AFNOR, ANSI etc..
Si j'ai le temps, je vous raconterai pourquoi Sun n'a jamais voulu que Java soit normalis�.
En attendant, je maintiens que l'impl�mentation de Sun reste la seule r�f�rence possible.

// Il y a ici un mystere : d'apres la doc du JDK, elementAt()
// est cense lancer ArrayIndexOutOfBoundsException.
// comme at() ne traite pas l'exception et qu'elle
// ne la transmet pas non plus, elle ne devrait pas compiler ..
// Or, elle compile tres bien avec le compilo de Sun
// J'ai du rater une marche quelque part

Rien de plus normale... La reponse a ce mist�re est expliquer dans le ... Javadoc evidement !
http://java.sun.com/j2se/1.4/docs/api/java/lang/RuntimeException.html
Tu voudrais quand meme pas qu'on soit obliger de tagger toutes les classes comme pouvant produire un NullPointerException ?

Oh ! Quelle d�ception !
Dire que je m'�tais imagin� que la signature des m�thodes renseignait leur utilisateur
potentiel sur ce � quoi il pouvait s'attendre.
Je cite un livre qui dit beaucoup de bien de Java:
"La signature d'une m�thode comprends la d�claration des exceptions susceptibles
de remonter lors de l'appel de cette m�thode"
Bon, je croyais tenir un domaine dans lequel Java �tait plus clean que C++,
mais je vois que c'est encore rat�.

Tu n'est pas programmeur C++ pour rien... Je ne vois pas trop l'interet d'h�rit� de la classe Vector. L'utilisation de Vector est a r�serv� exclusivement pour de l'acces Multi-Thread, ce n'est pas le cas, donc on utilise ArrayList. Et pour une structure de donn�e de taille fixe, preferrera utiliser un tableau...

L'int�r�t, c'est d'offrir � l'utilisateur les outils de manipulation d'�l�ments
offert par Vector pour manipuler les polygones.
Si je n'avais pas voulu cela, Polygone aurait juste utilis� un Vector en interne
et aurait du fournir des fonctions d'acc�s. Cela aurait encore ralenti cette classe,
alors ne vous plaignez pas.

A propose de ArrayList, vous auriez du essayer avant de proposer cette "optimisation"
ArrayList n'a pas la m�me interface que Vector : j'ai du remplacer ce qui suit

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
    	
        add(p.dup()) ; // dup evite les donnees partagees
        //addElement(p.dup()) ; // dup evite les donnees partagees

            //return (Point3)elementAt(i) ;
            return (Point3)get(i) ;

        // removeAllElements();
        removeRange(0,size()) ;

Comme je n'ai pas trouv� d'acc�s par it�rateur, j'ai du remplacer l'acc�s par it�rateur par
l'acc�s via la m�thode at() (qui utilise get() et r�alise le transtypage).
Si vous voyez un autre moyen, je suis preneur.

Le r�sultat des courses, c'est qu'il faut 27 secondes au lieu de 24 secondes pour r�aliser le test le plus court. Je suis peut-�tre qu'un programmeur C++, mais je teste avant de dire une b�tise.

En ce qui concerne la taille fixe, merci, je me doute bien qu'un tableau serait plus efficace.
Mais la taille n'est pas fixe.

La difference de 2 points dans l'espace donne ... un point dans l'espace... Bof !

Relisez ce que j'ai �crit

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
------------------ 
L'identification des concepts indique que l'on manipule 

-des points dans l'espace (plus exactement des vecteurs de position) 
-des polygones

Perso je recoderais la fonction pvect pour prendre 4 points et faire le calcul, on economise la construction 2 object intermediaire et on a un object qui ressemble a quelque chose.

Je ne comprends pas du tout, et je vous invite � me monter ce que
vous voulez dire.

A la place de la salle fonction dup, je ferais plutot un constructeur de recopie, c'est quand meme plus �l�gant.

Plus �l�gant ?
Cela conduit � ecrire

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
add(new Point3(p)) ;

au lieu de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
add(p.dup()) ;

Je veux bien, mais �a ne me parait pas evident.

Si j'ai le temps, je vous raconterai pourquoi Sun n'a jamais voulu que Java soit normalis�.

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

M�me s'il n'y a pas de normalisation, la sp�cification de la plateforme java2 permet de maintenir des impl�mentations coh�rentes de la part des constructeurs.
Weblogic, webSphere, jboss, sun one (encore heureux!), borland appserver, etc... sont des serveurs d'application respectant la spec j2EE . Cela dit, on parle couramment de norme j2EE, m�me si elle n'est pas valid�e pas un organisme. Tout le monde peut t�l�charger la sp�c j2ee et commencer � faire son serveur d'application (bon courage quand m�me). c'est valable pour une machine virtuelle aussi. Un programme java compile et se comporte de la m�me mani�re avec la jre ibm ou sun....

ArrayList n'a pas la m�me interface que Vector

elles impl�mentent java.util.List.... (cf le code ci-dessous)


Avec ce code :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
import java.util.*;

class Test {
    static final long dt = 3000;
    
    public static void main(String[] args) {
        int iter=0;
        
        if(args[0].equals("vector")){
            Vector vec = new Vector();
            
            for&#40;int i=0;i<1000; ++i&#41;
                vec.add&#40;new String&#40;"hello"&#41;&#41;;
            
            long t0=System.currentTimeMillis&#40;&#41;;
            while&#40;System.currentTimeMillis&#40;&#41;-t0<dt&#41; &#123;
                for&#40;int i=0; i<vec.size&#40;&#41;; ++i&#41;&#123;
                    String s = &#40;String&#41; vec.get&#40;i&#41;;
                &#125;
                ++iter;
            &#125;
        &#125; else &#123;
            ArrayList list = new ArrayList&#40;&#41;;
            
            for&#40;int i=0;i<1000; ++i&#41;
                list.add&#40;new String&#40;"hello"&#41;&#41;;
            
            long t0=System.currentTimeMillis&#40;&#41;;
            while&#40;System.currentTimeMillis&#40;&#41;-t0<dt&#41; &#123;
                for&#40;int i=0; i<list.size&#40;&#41;; ++i&#41; &#123;
                    String s = &#40;String&#41; list.get&#40;i&#41;;
                &#125;
                ++iter;
            &#125;
        &#125;
        
        System.out.println&#40;iter+" iterations"&#41;;
    &#125;
&#125;

j'obtient environ 71500 iterations sur les Vector et 96600 avec ArrayList
Soit un gain de 35%.

Maintenant avec les iterateurs, Vector reste constant et ArrayList descend � 51705. Soit une perte de 28%

Comment expliquer ca? Y'a -til une optimisation faites par la jvm?

Ca n'empeche pas que le vrai gain se situe cot� m�moire...Faire attention � ne pas saturer inutilement le garbage-collector.

Le compilateur n'a pas "n�glig�" de v�rifier les param�tres, il les a convertis !

donc que le double a bien �t� converti en float.

Super, c'est exactement ce que je voulais montrer. C'est la m�me histoire avec les convertions implicites que le compilateurs r�alise derri�re votre dos. Une petite erreur de frappe, et hop un bug pernitieux. Ici ca n'est pas grave. Dans un logiciel de calcul peut-�tre plus. Non le pire vient avec les op�rateurs de conversion implicite

ca a � voir si le langage est strict ou pas

Allons, pas de mauvais esprit! Il y a dans javac une option -nowarn
pour supprimer les warnings, �a ne change rien au langage !

Le philosophie du C++, c'est surtout de ne pas prendre les programmeurs
pour des imb�ciles en leur faisant prendre des vessies pour des lanternes.

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!

Et puis :
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.
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.
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++.
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".

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

Simplicit� => efficacit�
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.
G�n�ralement, les simplifications propos�es sont difficilement maintenable; ce qui est maintenable, c'est un code simple et clair. Ce qui est parfois incompatible avec les performances.

bon pour le code ... avant toute chose, ce code n'a aucun but d'est�tique informatique. Etant donn� que ce ne sont ni mes classes et que dans la vie de tous le jours je ne programmes pas des appli de ""g�om�trie"" qui calculent des aires... En r�sum� j'ai bidouill� autour de l'existant juste pour montrer que la facon de coder peut grandement am�liorer les soit disantes "m�-performances" de java... Mais d'autres fa�ons de faire existent, il y a certainement moyen de faire beaucoup plus beau et certainement encore plus performant, voir certaines autres remarques, l� n'�tait pas mon but ...

classe aire

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
import java.io.* ;
import java.util.* ;

class Aire{

    private static long ITERATIONS = 10000000L;

    public static void main(String args[]){
        try{
            InputStreamReader f = new InputStreamReader(new FileInputStream("essai.pol")) ;
            FormattedIStream fis = new FormattedIStream(f) ;

            double a = 0;

            Polygone pol = new Polygone() ;

            pol.readPolygone(fis) ;

            long date = System.currentTimeMillis() ; // top chrono ..
            OutputStreamWriter os = new OutputStreamWriter(System.out) ;

            System.out.println( "\nNb de points du polygone :" + pol.getSize() ) ;
            pol.writePolygone(os) ;

            for&#40; int i = 0 ; i < ITERATIONS ; ++i&#41;&#123;
              a = pol.aire&#40;&#41; ;
            &#125;
            System.out.println&#40; "\nNb d'iterations &#58;" + ITERATIONS &#41; ;
            System.out.println&#40; "Aire &#58; " + a &#41; ;
            System.out.println&#40; "Temps ecoule &#58; &#40;" + ITERATIONS + " iterations&#41; " +
                + &#40;System.currentTimeMillis&#40;&#41;-date&#41;/1000 + " secondes"&#41; ;
            System.out.flush&#40;&#41; ;
        &#125;


        catch&#40;Exception e&#41;
        &#123;
          e.printStackTrace&#40;&#41;;
                System.out.println&#40;"Exception&#58; " + e.toString&#40;&#41;
                        + "\n" &#41; ;
        &#125;
    &#125;
&#125;

classe polygone

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
import java.io.* ;
import java.util.* ;

class Polygone{

  private Point3[] arrayOfPoints = null;
  private Vector buffer = null;

  public Polygone(){
    this.buffer = new Vector();
  }

  public void addPoint3(Point3 p){
    //buffer.addElement(p.dub()) ; // dup evite les donnees partagees
    buffer.addElement(p) ;
  }

  public Point3 at(int i){
    return (Point3)buffer.elementAt(i) ;
  }

  public void readPolygone(FormattedIStream stream) throws IOException {
     stream.ordinaryChar((int)';') ; // ; est un token pour ce flot

      buffer.removeAllElements();

      Point3 p = new Point3() ;
      try{
          for( ; ;){
              p.readPoint3(stream) ;
              addPoint3(p.dub()) ;
          }
      }catch(IOException e){
          // on arrive ici � cause d'une programmation brol
      }

      if( ! stream.testChar((int)';') )
          throw new IOException("Polygone: ';' not found or syntax error in coordinates.") ;

      toPoint3Array();
  }

  private void toPoint3Array(){
    this.arrayOfPoints  = new Point3[this.buffer.size()];

    this.buffer.trimToSize();

    Enumeration e = this.buffer.elements();
    for(int i = 0; e.hasMoreElements(); i++){
      Point3 p = (Point3)e.nextElement();
      this.arrayOfPoints[i] = p ;
    }
  }

  public void writePolygone(OutputStreamWriter os) throws IOException{
    int i ;

    for(i = 0 ; i < this.buffer.size() ; ++i){
        at(i).writePoint3(os) ;
        os.write("  ",0,2) ;
    }
    os.write(";",0,1) ;
    os.flush() ;
  }

  public double aire(){
    Point3 som = new Point3();
    Point3 produit = null;
    Point3 p0 = null;
    Point3 p1 = null;
    Point3 p2 = null;

    if( this.arrayOfPoints.length > 2){// acces par tableau

        p0 = this.arrayOfPoints[0].getInitialValue();
        p1 = this.arrayOfPoints[1].getInitialValue();

        for(int i = 2 ; i < this.arrayOfPoints.length ; i++ ){
          p2 = this.arrayOfPoints[i].getInitialValue();
          p1.difference(p0);
          p2.difference(p0);
          p1.produitVectoriel(p2);
          som.somme(p1);
          p1 = p2 ;
        }
    }
     return 0.5 * som.norme() ;
  }

  public int getSize(){
    return this.buffer.size();
  }

}

classe point3

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
import java.io.*;

// Classe Point3, et ses operateurs
class Point3{
    private double initialX = 0.0d ;
    private double initialY = 0.0d;
    private double initialZ = 0.0d;
    private double x = 0.0d ;
    private double y = 0.0d;
    private double z = 0.0d;

    public Point3(){}

    public Point3(double x, double y, double z){
        this.initialX = this.x = x ;
        this.initialY = this.y = y ;
        this.initialZ = this.z = z ;
    }

    public String toString(){
        return x + " " + y + " " + z ;
    }

    public void readPoint3(FormattedIStream f) throws IOException{
        this.initialX = x = f.readDouble() ;
        this.initialY = y = f.readDouble() ;
        this.initialZ = z =  f.readDouble() ;
    }

    public void writePoint3(OutputStreamWriter os) throws IOException{
        String s = toString() ;
        os.write(s,0,s.length()) ;
    }

    public void somme(Point3 point){
      this.x += point.x;
      this.y += point.y;
      this.z += point.z;
    }

    public void difference(Point3 point){
      this.x -= point.x;
      this.y -= point.y;
      this.z -= point.z;
    }

    public void produitVectoriel(Point3 point){
        double tmpX = this.y * point.z - this.z * point.y ;
        double tmpY = -( this.x * point.z - this.z * point.x) ;
        double tmpZ = this.x * point.y - this.y * point.x ;

        this.x = tmpX;
        this.y = tmpY;
        this.z = tmpZ;
    }

    public double norme(){
      return Math.sqrt(this.x * this.x + this.y * this.y + this.z * this.z) ;
    }

    public Point3 dub(){
      return new Point3(x,y,z);
    }

    private void initValues(Point3 point){
      this.x = point.x;
      this.y = point.y;
      this.z = point.z;
    }

    private void initValues(double x, double y, double z){
      this.x = x;
      this.y = y;
      this.z = z;
    }

    public void resetInitialValues(){
      initValues(this.initialX, this.initialY, this.initialZ);
    }

    public Point3 getInitialValue(){
      this.resetInitialValues();
      return this;
    }

}

le stream

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
import java.io.StreamTokenizer;
import java.io.*;


class FormattedIStream extends StreamTokenizer
{
    private InputStreamReader ist ;

    FormattedIStream( InputStreamReader is){
        super(is) ;
        ist = is ;
        // Valide les "double" comme tokens
        this.parseNumbers() ;
    }
    // Renvoie un double si il existe,
    // ou lance une exception
    double readDouble() throws IOException
    {

        if( nextToken()== TT_NUMBER )
            return nval ;
        else
        {
            pushBack() ;
            throw new IOException("No number on stream.") ;
        }

    }

    // Exception si rien � lire ou pas de mot
    String readWord() throws IOException{
        if(nextToken() == TT_WORD )
            return  sval;
        else
            throw new IOException("No word on stream.") ;
    }
    // V�rifie la pr�sence du caract�re code
    // le caractere est consomme si il est present
    // tout autre caractere est laisse sur le flot
    // retour : vrai si caractere present
    // Exception si rien � lire

    boolean testChar(int code)  throws IOException
    {
       boolean yes ;
        if( nextToken() == code)
            yes =  true;
        else
        {
           pushBack() ;
            yes =  false ;
        }
        return yes ;
    }

}

sur ma machine
code ++gib : 4 points prennent 9 secondes � s'ex�cuter
8 points prennent 25 secondes � s'ex�cuter
mon code : 4 points prennent 2 secondes � s'ex�cuter
8 points prennent 5 secondes � s'ex�cuter

d�ol� je n'ai pas eu le courage de cr�er un fichier avec 64 points ....

La principale adaptation a �t� d'enlever la cr�ation d'instances de point3 dans �norm�ment de m�thodes.
je passes de 90000005 � 10000005 (= nombre d'iterations (le r�sutat de la somme) + les 4 points + 1?)instanciations soit un facteur de 9, que je suis sur qu'il y a moyen d'am�liorer encore car ca me semble beaucoup pour 'l'exercice' en question. Si mes calculs sont bons il n'en faudrait que 5 (pour 4 points), ce qui est faisable assez facilement (L� je rejoint l'avis de cl�ment, il faudrait une m�thode permettant d'envoyer plusieurs points dans la m�thode aire, sans devoir pour autant � chaque fois r�instancier l'objet Point3).... Alors java n'est pas performant avec les objets?? Evidemment quand programme � la fa�on sauvage, on obtient des r�sultats m�diocres...

Je voudrais �galment rajouter � propos du code, que j'essaie de d�cortiquer (du code c++ �crit en java) pour l'instant, comporte �galement quelques m�thodes totalement inutilis�es (il y a m�me des m�thodes qui �taient d�j� en remarque...) ce qui r�duit d�j� grandement la diff�rence de nombre de lignes de code... (soit une 50ene de lignes pour l'instant soit plus de la moiti� de la diff�rence, je n'ai pas compt� les remarques personelles, qui concernant java, et non le code la dedans...).

On ne fait pas le concours du nombre de lignes je crois ?
Le but est de mesurer les perfs. Si le code n'est pas utilis�,
il ne doit pas avoir beaucoup d'influence sur les perfs.

J'ai fait un copier/coller de mes fichiers, et j'aurais du retirer
les m�thodes inutilis�es, mais �a ne change rien au r�sultat.

Au passage, j'aurais pr�fer� qu'on m'indique comment me passer de
FormattedIStream. J'ai developp� ce truc pour faire ce que je fais
en 1 ligne de C++, et je ne le trouve pas particuli�rement beau.
En effet, je me tape l'empilement de
FileInputStream +
InputSteamReader +
FormattedIStream (qui utilise en interne StreamTokenizer)
OUF !!
Tout cela pour lire des double dans un fichier formatt� !
Apr�s cela, dire que Java est simple fait rigoler.
Il est tellement "simple" que toute la complexit� est report�e
sur les biblioth�ques.

Je pense d'ailleurs que FormattedIStream est mal con�ue : elle ne devrait
utiliser les exceptions que pour les erreurs "hardware"
et non pour les erreurs de formattage (mais �a, personne ne me l'a dit,
occup�s que vous �tes � "gratouiller" le code pour gagner les pr�cieuses
secondes).
Voila en tout cas ce qui arrive lorsqu'un outil n'est pas assez puissant :
on perd son temps sur les �-cot�s au lieu de se concentrer sur
le probl�me pos�.

-------------------------------------------------------------------

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
/*  // acces par index, grace � la methode at(int)
           p0 = at(0) ;
          for&#40;int i = 1 ; i < size&#40;&#41;-1 ; ++i&#41;
          &#123;
             som =
                som.somme&#40; &#40;&#40;at&#40;i&#41;.diff&#40; p0&#41;&#41;.pvect&#40;&#40;at&#40;i+1&#41;.diff&#40; p0&#41;&#41; &#41;&#41; &#41;;
          &#125;
        */

Remarques ??? ou oubli???

Ni l'un ni l'autre. C'est une version qui fait de l'acc�s direct
(ie: par index) au conteneur.
Pas utilis�e car 10% plus lente. J'ai du d'ailleurs la remettre en service
pour utiliser un ArrayList.

------------------------------

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
   
public /*boolean*/void addPoint3(Point3 p){
        buffer.addElement(p.dub()) ; // dup evite les donnees partagees
//        return true ;
    }

Evidemment on peut rajouter des trucs mais si ca ne vaut pas la peine ...

Exact ! On supprime, c'est une scorie d'une version ant�rieure.
On gagne combien de secondes l� ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 try
        {
            for( ; ;){
                p.readPoint3(stream) ;
                addPoint3(p) ;
            }
        }

        catch(IOException e)
        {
            // on arrive ici si on ne peut plus lire
            // en fait, il n'y a rien de special a faire.
        }

Personellement je ne programme pas avec des for( ; ; ) qui lancent des exceptions � l'int�rieur du bloc... Sans doute une pratique c++sienne. Mais ce code se r�sume � 3- 4 lignes si c'est bien cod�... Sans doute que java n'a pas encore permis d'uitliser le goto, alors il faut utilser des rustines...

Pour la version C++, il suffit de la regarder au lieu de calomnier :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
    for(  ; (i >> p)  ; )
    {
        pp.insert(pp.end(), p)  ;
    }

Encore qu'on puisse probablement faire encore plus simple.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
double x = -1;

...Dans la methode main .. j'ai pas compris � quoi ca servait

A rien bien s�r, c'est encore un reste d'une version ant�rieure.

Une exception devrait se produire seulement si le nombre de token num�rique avant chaque ';' n'est pas un multiple de trois.

pour eviter de terminer une boucle par une exception , un truc dans ce style :

while( stream.hasMorePolygons() ) {
}

FileInputStream +
InputSteamReader +
FormattedIStream

Pourquoi le InputStreamReader ici?

Il est tellement "simple" que toute la complexit� est report�e
sur les biblioth�ques

Le design pattern Decorateur permet d'ajouter dynamiquement des fonctionnalit�s � une hi�rarchie de classe. c'est une approche diff�rente du c++.
avantages/inconv�nients :
Comme avec les Lego(tm), tu peux interconnecter plusieurs d�corations avec une classe de d�part pour obtenir toute les combinaisons possibles moyennant tr�s peu de classes (classes de d�part, et classes de d�coration). En h�ritage simple, cela aurait donn� une progression exponentielle du nombre de classe pour chaque nouvelle fonctionnalit�. De plus pour le nommage des classes, ca aurait �t� compliqu�.
L'inconv�nient de cette flexibit� est un code plus lourd.


*InputStream classe de base pour les flux de donn�es entrant.
Classe d�rivant de inputStream :
-FileInputStream : lire un fichier.
-StringBufferInputStream : lire une chaine de charactere comme un flux

*Decorateurs (classes d�rivant de InputStream et poss�dant une r�f�rence sur un InputStream, permettant d'utiliser le comportement de base)
-ObjetInputStream : lire un objet en version s�rialis�e provenant de n'importe quel inputStream �ventuellement lu� m�me d�cor�.
-BufferedInputStream : fait la m�me chose que le flux de base r�f�renc�, mais utilise un buffer
-CheckedInputStream : utilis� pour zipper un flux
....

Pareil pour outputStream...

Swing utilise pas mal ce concept.

Envoy� par gregy

bon pour le code ... avant toute chose, ce code n'a aucun but d'est�tique informatique.

Et bien, avant toute chose : heureusement.


Sur le fond:
------------

Je croyais avoir clairement �nonc� les r�gles permettant une comparaison
objectives des performances de deux langages (ce que personne n'a contest�).


Or te voila parti dans une course � l'optimisation en bidouillant
le code � mort (le terme "bidouiller" est de toi, mais il est appropri�).
Que crois tu avoir prouv� ? Que Java est un langage tr�s rapide ?
Quelle naivet� !
Il ne t'est pas venu � l'id�e qu'il est possible de bidouiller des deux cot�s ?
(Quoique bidouiller autant me parait difficile)


La r�gle de base est que les deux programmes fassent la m�me chose
pour qu'on puisse les comparer. Si ce n'est pas le cas, on sodomise
les insectes, rien de plus.

Voici ce que tu as fait (je reconstitue ton cheminement intellectuel)

Acte 1
------
Les objets co�tant cher en Java, tu as d�cid� de mener les calculs
sur des tableaux plut�t que sur des vecteurs. Tu as donc introduit un
tableau de Point3 (structure de donn�e de bas niveau) dans la classe polygone.
Manque de pot, ceci revient � g�r�r la m�moire "� la main" puisqu'un
tableau doit �tre dimensionn� explicitement. Bref comme en C (pas C++).
Donc tu as l'id�e de garder le Vector, a cot� du tableau et de recopier
le Vecteur dans le tableau juste apr�s la lecture du fichier (toPoint3Array()).

Vlan, une m�thode de plus et deux structures de donn�es utilis�es en
parall�le. D'ou perte de place et probl�mes de coh�rence en perspective.

En effet, ainsi "�quip�" le Polygone ne peut plus �tre modifi�
(ajout/suppression de points) sous peine d'introduire une incoh�rence
entre le tableau et le Vector.
Quelle belle conception.

Acte 2
------
Les objets coutant cher en Java, tu as aussi l'id�e d'en limiter
la manipulation dans la m�thode calcul Polygone.aire(), en ne cr�ant
pas d'objet interm�diaire pour stocker les r�sultats interm�diaires.
Quelle bonne id�e !
Pour y parvenir, tu d�cide de changer la s�mantique de add qui
passe de simple addition (+) � addition-rangement (+=), de fa�on �
mener le calcul sur les Point3 du tableau eux-m�mes.
M�me op�ration sur le produit vectoriel.
Stop !
Ici, ton programme ne fait plus la m�me chose qu'avant et en �tant
honn�te, tu aurais du faire le m�me type de modif sur la version C++.
Tu aurais alors constat� une acc�l�ration de celle-ci.

Mais le pire reste � venir. Ayant fait cela, tu as constat� que le
ton programme ne marchait plus.

Acte 3
------
Phase de "d�buggage".
Ton (nouvel) algo fonctionne une fois, et �choue les 9999999 autres.
La raison en est simple : comme tu fais les calculs en utilisant
les points du polygone commes variables interm�diaires, le polygone
est d�truit � l'issue du premier calcul.
Au lieu de constater ton erreur et d'essayer une autre solution,
tu persistes en bidouillant la classe "Point3", qui jusqu'ici avait
echapp� � ta fureur optimisatrice.
Commes les Point3 sont �cras�s tu imagines de dupliquer les donn�es
� l'int�rieur de ceux ci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
    private double initialX = 0.0d ; 
    private double initialY = 0.0d; 
    private double initialZ = 0.0d; 
    private double x = 0.0d ; 
    private double y = 0.0d; 
    private double z = 0.0d;

Encore une duplication de donn�es, avec incoh�rence � pr�voir.
Pour recouvrir ta crotte, tu ajoutes �galement 2 m�thodes
( 2 !! ) pour restaurer discr�tement les donn�es en cours de calcul.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
    public void resetInitialValues(){ 
      initValues(this.initialX, this.initialY, this.initialZ); 
    } 

    public Point3 getInitialValue(){ 
      this.resetInitialValues(); 
      return this; 
    }

L'acc�s � un point devient donc:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
p2 = this.arrayOfPoints[i].getInitialValue();

au lieu de :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
p2 = this.arrayOfPoints[i];

Bien sur, � l'issue du dernier calcul, on ressort de aire() avec
un polygone v�rol�. L'utilisateur � l'aire, mais plus son polygone,
il doit �tre content.

Il y a en C++ un mot cl� const qui dit qu'une m�thode s'engage � ne pas
modifier son objet support. Voir mon code.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
double polygone::aire() const

OK, ce n'est pas assez bon pour Java mais �a t'aurait
rendu service ici.


Au moins une autre "optimisation" est nuisible dans ton programme :
tu as sorti l'appel au duplicateur de point ( dup() ) de la m�thode
Polygone.addPoint3(). Cette duplication avait pour but d'�viter �
l'utilisateur impr�voyant de se retrouver avec un polygone dont tous
les �l�ments pointent sur un seul et m�me point.

Probl�me typique de l'utilisation de pointeurs.
Non allez je rigole ! Il n'y a pas de pointeur en Java.

Comme cette tentative d'�viter les variables interm�diaires
� foir� comme les pr�c�dentes, tu as remis l'appel
� dup() (rebaptis� dub() ) dans l'appel de addPoint3() .

Tu n'as donc rien gagn�, mais en plus, le premier utilisateur naif
de Polygone va se retrouver avec un bug lorqu'il utilisera addPoint3()
en oubliant de dupliquer "a la main".



Conclusion:
===========

A propos des performances.
-------------------------
Les performances que tu exhibes n'ont aucune valeur puisque le programme
n'ex�cute plus les m�mes op�rations. Je me suis abstenu de ce genre
de manipulation (pourtant il m'aurait �t� tr�s simple de fourguer
un op�rateur += � la place de + et autres raccourcis).
Non seulement ton approche n'est pas honn�te, mais en plus tes sabots
sont particuli�rement bruyants.

Au passage, la taille des donn�es � augment� (plus de X 2)
et le nombre de m�thodes a aussi augment�.

A propos du style
-----------------
La mod�lisation objet en a pris un sale coup.
Un vecteur dans l'espace a trois composantes, et je ne vois
par pourquoi je devrais d�clarer six doubles.
M�me remarque pour la structure de donn�es redondante et potentiellement
incoh�rente de polygone.

La programmation par objet permet th�oriquement de rester proche
du probl�me (en manipulant les concepts qui interviennent dans celui-ci)
Or ton code est au ras de l'impl�mentation, bas� sur des bidouilles
qui feraient redoubler un �tudiant de 1�re ann�e de fac.

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.

Relisez les post ant�rieurs de Gregory Picavet et vous verrez
qu'il pr�conise des techniques d'optimisation analogues: recopier
les donn�es dans des SD de bas niveau pour les manipuler.



Le message �mis par vos deux contributions est clair.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
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.

Il ne peut pas y avoir de d�monstration plus �clatante des carences
de ce langage si on l'utilise pour autre chose que de programmer des
interfaces.

Si j'avais balanc� �a tout de go, on m'aurait trait� de Charlot.

Mainenant que c'est arriv� en direct devant vous, peut-�tre y croirez-vous.

sur ma machine
code ++gib : 4 points prennent 9 secondes � s'ex�cuter
8 points prennent 25 secondes � s'ex�cuter
mon code : 4 points prennent 2 secondes � s'ex�cuter
8 points prennent 5 secondes � s'ex�cuter

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.

Alors java n'est pas performant avec les objets??

En luttant avec auttant de force pour les �liminer de ton programme,
tu montres � l'�vidence que
Java n'est pas performant, SURTOUT avec les objets.

Evidemment quand programme � la fa�on sauvage, on obtient des r�sultats m�diocres...

Ce sera le mot de la fin.