un bon choix?

Loïc Joly

28/04/2004 à 23:56

XCyrano wrote:

bonsoir,

je developpe en java, mais pour des raisons de performance et de memoire
je souhaite reecrire mon apllication en C++.

la bibliotheque java d'oreilly est plutot pas mal, aussi je souhaite
acheter Programmation C++ par la pratique du meme editeur.

c'est un bon choix?

A priori, non. Voir par exemple une revue de la version anglaise :
http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0pb_O_Reilly&file=p001010a

Le même site contient des revues en général assez pertinentes de pas mal
de bouquins de C++. Je conseille vivement d'y faire un tour avant d'acheter.

--
Loïc
PS : Merci de donner plus d'info quand on demande des renseignements sur
un livre, par exemple, le nom de l'auteur aide bien.

Martinez Jerome

29/04/2004 à 15:13

XCyrano wrote:

je developpe en java, mais pour des raisons de performance et de memoire
je souhaite reecrire mon apllication en C++.

Pour la mémoire, admettons (mais est-ce important de nos jours?), mais
pour les performances j'ai un doute que tu gagnes des performances en
passant de Java a C++ : ces deux languages ont des performances
quasi-identiques.

Mickael Pointier

29/04/2004 à 15:36

je developpe en java, mais pour des raisons de performance et de
memoire je souhaite reecrire mon apllication en C++.

Pour la mémoire, admettons (mais est-ce important de nos jours?), mais
pour les performances j'ai un doute que tu gagnes des performances en
passant de Java a C++ : ces deux languages ont des performances
quasi-identiques.

Ca dépend de l'application, et de la qualité du JIT.

Typiquement, si tu veux t'amuser à faire des choses telles que des
manipulations bas niveau de pixels, avec champs de bits et tout le tralala,
les performances de Java sont au mieux calamiteuses.

Après pour faire des applications fenêtrées de type bureautique, il n'y a
effectivement pas grand intérêt à passer de l'un à l'autre pour des
problèmes de performance.

Mike

no.bcausse.spam

29/04/2004 à 15:46

Martinez Jerome
wrote:

Pour la mémoire, admettons (mais est-ce important de nos jours?),

la memoire je m'en arrangerai (j'ai deux/trois idees)

mais
pour les performances j'ai un doute que tu gagnes des performances en
passant de Java a C++ : ces deux languages ont des performances
quasi-identiques.

je suis un fervent defenseur de java, meme optimiste sur mon type
d'application (calculs et acces frequent a la memoire) le rapport doit
etre de 1 pour 2. d'autres penchent vers 1 sur 10 (pas de nom) :)

XCyrano

--
bruno Causse
http://perso.wanadoo.fr/othello

Richard Delorme

29/04/2004 à 17:53

Martinez Jerome
wrote:

Pour la mémoire, admettons (mais est-ce important de nos jours?),

la memoire je m'en arrangerai (j'ai deux/trois idees)

mais
pour les performances j'ai un doute que tu gagnes des performances en
passant de Java a C++ : ces deux languages ont des performances
quasi-identiques.

je suis un fervent defenseur de java, meme optimiste sur mon type
d'application (calculs et acces frequent a la memoire) le rapport doit
etre de 1 pour 2. d'autres penchent vers 1 sur 10 (pas de nom) :)

Les autres, c'est moi. L'application en question est un programme
d'Othello (le jeu où l'on retourne des pions), et, si l'on a l'ambition
d'avoir un programme très fort, susceptible de gagner des tournois,
l'utilisation du langage Java est à mon avis un sérieux handicap. Il
faut savoir que pour ce genre d'application reposant sur la force brute,
le choix même des algorithmes peut dépendre des performances du système.
Par exemple, à Othello, il existe des techniques de recherche sélective
qui ne sont efficaces que si le programme atteint une certaine
profondeur. Le problème est que pour atteindre cette profondeur, il faut
aller suffisament vite. L'handicap est finalement double, le programme
en Java est non seulement mauvais parce qu'il est lent, mais en plus
parce qu'il ne peut pas bénéficier de l'efficacité de certains
algorithmes qui ne marchent qu'à un niveau de vitesse supérieure. C'est
pourquoi, en partant d'un écart de vitesse pure de 1 à 2, on se retrouve
au final avec un écart de performance plus grand, de 1 à 5, voire de 1 à 10.

--
Richard

NOXCyranoSPAM

29/04/2004 à 22:01

Causse Bruno wrote:

mais on s'ecarte, un bon livre en francais pour ecrire du code
efficace?.
pas un dico (Stroustrup) que je possede.

--
XCyrano
http://perso.wanadoo.fr/othello

kanze

30/04/2004 à 08:57

"Mickael Pointier" wrote in message
news:<c6r0aq$4bn$...

je developpe en java, mais pour des raisons de performance et de
memoire je souhaite reecrire mon apllication en C++.

Pour la mémoire, admettons (mais est-ce important de nos jours?),
mais pour les performances j'ai un doute que tu gagnes des
performances en passant de Java a C++ : ces deux languages ont des
performances quasi-identiques.

Ca dépend de l'application, et de la qualité du JIT.

Typiquement, si tu veux t'amuser à faire des choses telles que des
manipulations bas niveau de pixels, avec champs de bits et tout le
tralala, les performances de Java sont au mieux calamiteuses.

Ça dépend comment tu t'y prends, je crois. Dans les mésures que j'ai
fait, où Java brillait (par rapport à C++), c'est quand tu travaillais
sur des tableaux de types de base. Où il se présentait le pire, en
revanche, c'était pour des tableaux des petits types définis par
l'utilisateur, qui avait logiquement une sémantique de valeur (du genre
Point2D). Je n'ai pas fait des mésures sur des bitmaps en soi, mais a
priori, je m'attendrais que si tu manipulais des images dans des int[],
Java doit être compétitif, voire plus performant que C++, tandis que si
tu manipulais des Color[] (par exemple)...

Mais comme tu dis, ça dépend du JVM. D'une part, si les auteurs n'en ont
pas considéré ton cas, et ne l'ont pas optimisé, qu'importe la
différence potentielle. Et de l'autre, il ne s'agit sans doute pas
seulement de la manipulation des tableaux, mais aussi des interfaces
système. Si par la suite, pour afficher ton image, il faut passer par
les couches de Swing, voire par JNI, il y a une perte de performance
importante aussi.

Après pour faire des applications fenêtrées de type bureautique, il
n'y a effectivement pas grand intérêt à passer de l'un à l'autre pour
des problèmes de performance.

Question vitesse, probablement pas. Question taille mémoire, en
revanche, peut-être bien. Les JVM que j'ai connu en était extrèmement
gourmandes.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

"Mickael Pointier" <mpointier@eden-games.moc> wrote in message
news:<c6r0aq$4bn$1@apollon.grec.isp.9tel.net>...

je developpe en java, mais pour des raisons de performance et de
memoire je souhaite reecrire mon apllication en C++.

Pour la mémoire, admettons (mais est-ce important de nos jours?),
mais pour les performances j'ai un doute que tu gagnes des
performances en passant de Java a C++ : ces deux languages ont des
performances quasi-identiques.

Ca dépend de l'application, et de la qualité du JIT.

Typiquement, si tu veux t'amuser à faire des choses telles que des
manipulations bas niveau de pixels, avec champs de bits et tout le
tralala, les performances de Java sont au mieux calamiteuses.

Ça dépend comment tu t'y prends, je crois. Dans les mésures que j'ai
fait, où Java brillait (par rapport à C++), c'est quand tu travaillais
sur des tableaux de types de base. Où il se présentait le pire, en
revanche, c'était pour des tableaux des petits types définis par
l'utilisateur, qui avait logiquement une sémantique de valeur (du genre
Point2D). Je n'ai pas fait des mésures sur des bitmaps en soi, mais a
priori, je m'attendrais que si tu manipulais des images dans des int[],
Java doit être compétitif, voire plus performant que C++, tandis que si
tu manipulais des Color[] (par exemple)...

Mais comme tu dis, ça dépend du JVM. D'une part, si les auteurs n'en ont
pas considéré ton cas, et ne l'ont pas optimisé, qu'importe la
différence potentielle. Et de l'autre, il ne s'agit sans doute pas
seulement de la manipulation des tableaux, mais aussi des interfaces
système. Si par la suite, pour afficher ton image, il faut passer par
les couches de Swing, voire par JNI, il y a une perte de performance
importante aussi.

Après pour faire des applications fenêtrées de type bureautique, il
n'y a effectivement pas grand intérêt à passer de l'un à l'autre pour
des problèmes de performance.

Question vitesse, probablement pas. Question taille mémoire, en
revanche, peut-être bien. Les JVM que j'ai connu en était extrèmement
gourmandes.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

"Mickael Pointier" wrote in message
news:<c6r0aq$4bn$...

je developpe en java, mais pour des raisons de performance et de
memoire je souhaite reecrire mon apllication en C++.

Pour la mémoire, admettons (mais est-ce important de nos jours?),
mais pour les performances j'ai un doute que tu gagnes des
performances en passant de Java a C++ : ces deux languages ont des
performances quasi-identiques.

Ca dépend de l'application, et de la qualité du JIT.

Typiquement, si tu veux t'amuser à faire des choses telles que des
manipulations bas niveau de pixels, avec champs de bits et tout le
tralala, les performances de Java sont au mieux calamiteuses.

Ça dépend comment tu t'y prends, je crois. Dans les mésures que j'ai
fait, où Java brillait (par rapport à C++), c'est quand tu travaillais
sur des tableaux de types de base. Où il se présentait le pire, en
revanche, c'était pour des tableaux des petits types définis par
l'utilisateur, qui avait logiquement une sémantique de valeur (du genre
Point2D). Je n'ai pas fait des mésures sur des bitmaps en soi, mais a
priori, je m'attendrais que si tu manipulais des images dans des int[],
Java doit être compétitif, voire plus performant que C++, tandis que si
tu manipulais des Color[] (par exemple)...

Mais comme tu dis, ça dépend du JVM. D'une part, si les auteurs n'en ont
pas considéré ton cas, et ne l'ont pas optimisé, qu'importe la
différence potentielle. Et de l'autre, il ne s'agit sans doute pas
seulement de la manipulation des tableaux, mais aussi des interfaces
système. Si par la suite, pour afficher ton image, il faut passer par
les couches de Swing, voire par JNI, il y a une perte de performance
importante aussi.

Après pour faire des applications fenêtrées de type bureautique, il
n'y a effectivement pas grand intérêt à passer de l'un à l'autre pour
des problèmes de performance.

Question vitesse, probablement pas. Question taille mémoire, en
revanche, peut-être bien. Les JVM que j'ai connu en était extrèmement
gourmandes.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze

30/04/2004 à 09:43

Richard Delorme wrote in message
news:<4091247e$0$7784$...

Martinez Jerome
wrote:

Pour la mémoire, admettons (mais est-ce important de nos jours?),

la memoire je m'en arrangerai (j'ai deux/trois idees)

mais pour les performances j'ai un doute que tu gagnes des
performances en passant de Java a C++ : ces deux languages ont des
performances quasi-identiques.

je suis un fervent defenseur de java, meme optimiste sur mon type
d'application (calculs et acces frequent a la memoire) le rapport
doit etre de 1 pour 2. d'autres penchent vers 1 sur 10 (pas de nom)
:)

Les autres, c'est moi. L'application en question est un programme
d'Othello (le jeu où l'on retourne des pions), et, si l'on a
l'ambition d'avoir un programme très fort, susceptible de gagner des
tournois, l'utilisation du langage Java est à mon avis un sérieux
handicap. Il faut savoir que pour ce genre d'application reposant sur
la force brute, le choix même des algorithmes peut dépendre des
performances du système. Par exemple, à Othello, il existe des
techniques de recherche sélective qui ne sont efficaces que si le
programme atteint une certaine profondeur. Le problème est que pour
atteindre cette profondeur, il faut aller suffisament vite. L'handicap
est finalement double, le programme en Java est non seulement mauvais
parce qu'il est lent, mais en plus parce qu'il ne peut pas bénéficier
de l'efficacité de certains algorithmes qui ne marchent qu'à un niveau
de vitesse supérieure. C'est pourquoi, en partant d'un écart de
vitesse pure de 1 à 2, on se retrouve au final avec un écart de
performance plus grand, de 1 à 5, voire de 1 à 10.

La vitesse de Java dépend largement de la façon dont tu représentes les
données. J'ai fait des mésures il y a un certain temps (quand j'étais à
la Dresdner Bank) -- c'était des mésures tout simples, qui comparait le
JDK de l'époque (1.2.2, je crois -- avec Hot Spot, en tout cas, parce
que c'était pour évaluer Hot Spot que je les ai fait) et VC++ (6.0, je
crois, mais peut-être seulement 5.0).

Ce que j'ai trouvé, c'est que pour des calculs numériques sur des
double[] ou des int[], Java était légèrement plus rapide que C++. À
condition de ne pas mettre tout dans une seule fonction -- Hot Spot ne
compile jamais une fonction avant qu'elle soit executé (et qu'on en est
sorti) au moins une fois. Ce que j'ai trouvé aussi, c'est que changer le
double[] en quelque chose comme Point2D[] ne changeait pratiquement rien
sur la vitesse de C++, tandis qu'en Java, il fallait du coup deux ou
trois foix plus de temps (sans doute à cause de l'indirection
supplémentaire). Conclusion : il est possible à écrire du Java qui va
aussi vite que le C++, mais si tu programmes proprement, ça ne serait
pas le cas.

Une autre chose à considérer : dans mes essais, je n'ai travaillé
qu'avec les jeux de données assez petits par rapport à la RAM. Si tu
manipules des tableaux très grands, en revanche, il faut aussi
considérer qu'un Point2D[] en Java a une très mauvaise localité,
beaucoup pire qu'un std::vector<Point2D>, par exemple. (Au moins,
évidemment, que tu ne t'amuse à utiliser un std::vector<double> pour
représenter le point, plutôt que « double x,y ».)

Dans la passée, Gosling avait un papier intéressant sur l'utilisation de
Java dans le numérique, avec des propositions pour résoudrer le problème
ci-dessus ; malheureusement, le lien que j'y avais ne m'amène plus qu'à
la page d'accueil de Gosling, d'où on n'arrive pas à trouver le papier.

Une autre page intéressante : http://membres.lycos.fr/lefevre/java/ceaxx.html
L'auteur fait tourner un benchmark numérique sur plusieurs machines avec
des implémentations différentes de Java et de C++. Sur au moins une
machine, l'implémentation la plus rapide était le Java d'IBM. (Je n'ai
pas régardé exactement ce qu'il fait dans le benchmark.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Richard Delorme <abulmo@nospam.fr> wrote in message
news:<4091247e$0$7784$7a628cd7@news.club-internet.fr>...

Martinez Jerome <jerome.martinez@aenlever-orangefrance.com.invalid>
wrote:

Pour la mémoire, admettons (mais est-ce important de nos jours?),

la memoire je m'en arrangerai (j'ai deux/trois idees)

mais pour les performances j'ai un doute que tu gagnes des
performances en passant de Java a C++ : ces deux languages ont des
performances quasi-identiques.

je suis un fervent defenseur de java, meme optimiste sur mon type
d'application (calculs et acces frequent a la memoire) le rapport
doit etre de 1 pour 2. d'autres penchent vers 1 sur 10 (pas de nom)
:)

Les autres, c'est moi. L'application en question est un programme
d'Othello (le jeu où l'on retourne des pions), et, si l'on a
l'ambition d'avoir un programme très fort, susceptible de gagner des
tournois, l'utilisation du langage Java est à mon avis un sérieux
handicap. Il faut savoir que pour ce genre d'application reposant sur
la force brute, le choix même des algorithmes peut dépendre des
performances du système. Par exemple, à Othello, il existe des
techniques de recherche sélective qui ne sont efficaces que si le
programme atteint une certaine profondeur. Le problème est que pour
atteindre cette profondeur, il faut aller suffisament vite. L'handicap
est finalement double, le programme en Java est non seulement mauvais
parce qu'il est lent, mais en plus parce qu'il ne peut pas bénéficier
de l'efficacité de certains algorithmes qui ne marchent qu'à un niveau
de vitesse supérieure. C'est pourquoi, en partant d'un écart de
vitesse pure de 1 à 2, on se retrouve au final avec un écart de
performance plus grand, de 1 à 5, voire de 1 à 10.

La vitesse de Java dépend largement de la façon dont tu représentes les
données. J'ai fait des mésures il y a un certain temps (quand j'étais à
la Dresdner Bank) -- c'était des mésures tout simples, qui comparait le
JDK de l'époque (1.2.2, je crois -- avec Hot Spot, en tout cas, parce
que c'était pour évaluer Hot Spot que je les ai fait) et VC++ (6.0, je
crois, mais peut-être seulement 5.0).

Ce que j'ai trouvé, c'est que pour des calculs numériques sur des
double[] ou des int[], Java était légèrement plus rapide que C++. À
condition de ne pas mettre tout dans une seule fonction -- Hot Spot ne
compile jamais une fonction avant qu'elle soit executé (et qu'on en est
sorti) au moins une fois. Ce que j'ai trouvé aussi, c'est que changer le
double[] en quelque chose comme Point2D[] ne changeait pratiquement rien
sur la vitesse de C++, tandis qu'en Java, il fallait du coup deux ou
trois foix plus de temps (sans doute à cause de l'indirection
supplémentaire). Conclusion : il est possible à écrire du Java qui va
aussi vite que le C++, mais si tu programmes proprement, ça ne serait
pas le cas.

Une autre chose à considérer : dans mes essais, je n'ai travaillé
qu'avec les jeux de données assez petits par rapport à la RAM. Si tu
manipules des tableaux très grands, en revanche, il faut aussi
considérer qu'un Point2D[] en Java a une très mauvaise localité,
beaucoup pire qu'un std::vector<Point2D>, par exemple. (Au moins,
évidemment, que tu ne t'amuse à utiliser un std::vector<double> pour
représenter le point, plutôt que « double x,y ».)

Dans la passée, Gosling avait un papier intéressant sur l'utilisation de
Java dans le numérique, avec des propositions pour résoudrer le problème
ci-dessus ; malheureusement, le lien que j'y avais ne m'amène plus qu'à
la page d'accueil de Gosling, d'où on n'arrive pas à trouver le papier.

Une autre page intéressante : http://membres.lycos.fr/lefevre/java/ceaxx.html
L'auteur fait tourner un benchmark numérique sur plusieurs machines avec
des implémentations différentes de Java et de C++. Sur au moins une
machine, l'implémentation la plus rapide était le Java d'IBM. (Je n'ai
pas régardé exactement ce qu'il fait dans le benchmark.)

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Richard Delorme wrote in message
news:<4091247e$0$7784$...

Martinez Jerome
wrote:

Pour la mémoire, admettons (mais est-ce important de nos jours?),

la memoire je m'en arrangerai (j'ai deux/trois idees)

mais pour les performances j'ai un doute que tu gagnes des
performances en passant de Java a C++ : ces deux languages ont des
performances quasi-identiques.

je suis un fervent defenseur de java, meme optimiste sur mon type
d'application (calculs et acces frequent a la memoire) le rapport
doit etre de 1 pour 2. d'autres penchent vers 1 sur 10 (pas de nom)
:)

Les autres, c'est moi. L'application en question est un programme
d'Othello (le jeu où l'on retourne des pions), et, si l'on a
l'ambition d'avoir un programme très fort, susceptible de gagner des
tournois, l'utilisation du langage Java est à mon avis un sérieux
handicap. Il faut savoir que pour ce genre d'application reposant sur
la force brute, le choix même des algorithmes peut dépendre des
performances du système. Par exemple, à Othello, il existe des
techniques de recherche sélective qui ne sont efficaces que si le
programme atteint une certaine profondeur. Le problème est que pour
atteindre cette profondeur, il faut aller suffisament vite. L'handicap
est finalement double, le programme en Java est non seulement mauvais
parce qu'il est lent, mais en plus parce qu'il ne peut pas bénéficier
de l'efficacité de certains algorithmes qui ne marchent qu'à un niveau
de vitesse supérieure. C'est pourquoi, en partant d'un écart de
vitesse pure de 1 à 2, on se retrouve au final avec un écart de
performance plus grand, de 1 à 5, voire de 1 à 10.

La vitesse de Java dépend largement de la façon dont tu représentes les
données. J'ai fait des mésures il y a un certain temps (quand j'étais à
la Dresdner Bank) -- c'était des mésures tout simples, qui comparait le
JDK de l'époque (1.2.2, je crois -- avec Hot Spot, en tout cas, parce
que c'était pour évaluer Hot Spot que je les ai fait) et VC++ (6.0, je
crois, mais peut-être seulement 5.0).

Ce que j'ai trouvé, c'est que pour des calculs numériques sur des
double[] ou des int[], Java était légèrement plus rapide que C++. À
condition de ne pas mettre tout dans une seule fonction -- Hot Spot ne
compile jamais une fonction avant qu'elle soit executé (et qu'on en est
sorti) au moins une fois. Ce que j'ai trouvé aussi, c'est que changer le
double[] en quelque chose comme Point2D[] ne changeait pratiquement rien
sur la vitesse de C++, tandis qu'en Java, il fallait du coup deux ou
trois foix plus de temps (sans doute à cause de l'indirection
supplémentaire). Conclusion : il est possible à écrire du Java qui va
aussi vite que le C++, mais si tu programmes proprement, ça ne serait
pas le cas.

Une autre chose à considérer : dans mes essais, je n'ai travaillé
qu'avec les jeux de données assez petits par rapport à la RAM. Si tu
manipules des tableaux très grands, en revanche, il faut aussi
considérer qu'un Point2D[] en Java a une très mauvaise localité,
beaucoup pire qu'un std::vector<Point2D>, par exemple. (Au moins,
évidemment, que tu ne t'amuse à utiliser un std::vector<double> pour
représenter le point, plutôt que « double x,y ».)

Dans la passée, Gosling avait un papier intéressant sur l'utilisation de
Java dans le numérique, avec des propositions pour résoudrer le problème
ci-dessus ; malheureusement, le lien que j'y avais ne m'amène plus qu'à
la page d'accueil de Gosling, d'où on n'arrive pas à trouver le papier.

Une autre page intéressante : http://membres.lycos.fr/lefevre/java/ceaxx.html
L'auteur fait tourner un benchmark numérique sur plusieurs machines avec
des implémentations différentes de Java et de C++. Sur au moins une
machine, l'implémentation la plus rapide était le Java d'IBM. (Je n'ai
pas régardé exactement ce qu'il fait dans le benchmark.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

un bon choix?

8 réponses

Veuillez sélectionner un problème