Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans souligné ou changement de police.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Richard Delorme
(Tiens un troll...)
(os2) wrote in news::
pour ceux désirant voir les performances de Java, C++ et GCJ dans quelques domaines j'ai effectué quelques tests
Et si tu utilisais un autre compilateur C++ ? Genre un qui est réputé pour produire un exécutable encore plus optimisé. (à moins que GCC ait fait de gros progrès...)
Si déjà gcc était utilisé de manière optimale...
Les fichiers source sont bien cachés. Le lien à suivre n'est pas mis en valeur. De plus, on a droit à un joli 403.
PS: en C++, on ne va pas utiliser strcat, mais std::string::operator+=() qui devait être encore plus rapide dès qu'assez de mémoire aura été réservée. Soit à la deuxième itération ou avant si c'est connu. (ceci dit, les sources sont inaccessibles)
C'est ce que fait le programme : http://kano.net/javabench/src/cpp/strcat.cpp Mais en jouant avec std::string::reserve() (je ne suis pas sûr de l'utilité).
PPS: Pour les matrices C++ est au coude à coude avec le fortran et permet une expressivité "mathématique" -- grâce à la surcharge d'opérateurs ; tu parlais de la facilité de développement.
Là par contre, le code c'est du C, à un cout près.
-- Richard
(Tiens un troll...)
marcpirat@yahoo.com (os2) wrote in
news:844b0dba.0410220431.702bb344@posting.google.com:
pour ceux désirant voir les performances de Java, C++ et GCJ dans
quelques domaines j'ai effectué quelques tests
Et si tu utilisais un autre compilateur C++ ? Genre un qui est réputé
pour produire un exécutable encore plus optimisé.
(à moins que GCC ait fait de gros progrès...)
Si déjà gcc était utilisé de manière optimale...
Les fichiers source sont bien cachés. Le lien à suivre n'est pas mis en
valeur. De plus, on a droit à un joli 403.
PS: en C++, on ne va pas utiliser strcat, mais std::string::operator+=()
qui devait être encore plus rapide dès qu'assez de mémoire aura été
réservée. Soit à la deuxième itération ou avant si c'est connu. (ceci
dit, les sources sont inaccessibles)
C'est ce que fait le programme :
http://kano.net/javabench/src/cpp/strcat.cpp
Mais en jouant avec std::string::reserve() (je ne suis pas sûr de
l'utilité).
PPS: Pour les matrices C++ est au coude à coude avec le fortran et permet
une expressivité "mathématique" -- grâce à la surcharge d'opérateurs ; tu
parlais de la facilité de développement.
Là par contre, le code c'est du C, à un cout près.
pour ceux désirant voir les performances de Java, C++ et GCJ dans quelques domaines j'ai effectué quelques tests
Et si tu utilisais un autre compilateur C++ ? Genre un qui est réputé pour produire un exécutable encore plus optimisé. (à moins que GCC ait fait de gros progrès...)
Si déjà gcc était utilisé de manière optimale...
Les fichiers source sont bien cachés. Le lien à suivre n'est pas mis en valeur. De plus, on a droit à un joli 403.
PS: en C++, on ne va pas utiliser strcat, mais std::string::operator+=() qui devait être encore plus rapide dès qu'assez de mémoire aura été réservée. Soit à la deuxième itération ou avant si c'est connu. (ceci dit, les sources sont inaccessibles)
C'est ce que fait le programme : http://kano.net/javabench/src/cpp/strcat.cpp Mais en jouant avec std::string::reserve() (je ne suis pas sûr de l'utilité).
PPS: Pour les matrices C++ est au coude à coude avec le fortran et permet une expressivité "mathématique" -- grâce à la surcharge d'opérateurs ; tu parlais de la facilité de développement.
Là par contre, le code c'est du C, à un cout près.
-- Richard
Jean-Marc Bourguet
Matthieu Moy writes:
Après, faut voir : Sur des machines récentes et selon les applications, ce n'est pas forcément la mémoire qui est limitante
Celles dont je m'occupe, on les fournis en 32 et 64 bits parce qu'en 32 bits parfois ca passe pas. Mais 64 bits est plus lent (et a un overhead memoire d'environ 50%) donc on a de la pression pour accepter plus.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Après, faut voir : Sur des machines récentes et selon les
applications, ce n'est pas forcément la mémoire qui est limitante
Celles dont je m'occupe, on les fournis en 32 et 64 bits parce qu'en
32 bits parfois ca passe pas. Mais 64 bits est plus lent (et a un
overhead memoire d'environ 50%) donc on a de la pression pour accepter
plus.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Après, faut voir : Sur des machines récentes et selon les applications, ce n'est pas forcément la mémoire qui est limitante
Celles dont je m'occupe, on les fournis en 32 et 64 bits parce qu'en 32 bits parfois ca passe pas. Mais 64 bits est plus lent (et a un overhead memoire d'environ 50%) donc on a de la pression pour accepter plus.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Luc Hermitte writes:
Jean-Marc Bourguet wrote in news::
Les fichiers source sont bien cachés.
Tellement bien que j'ai pas trouve.
Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans souligné ou changement de police.
Et le 403, tu fais quoi?
(Je sais je suis paresseux).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Luc Hermitte <hermitte@free.fr.invalid> writes:
Jean-Marc Bourguet <jm@bourguet.org> wrote in
news:pxbk6tisvkq.fsf@news.bourguet.org:
Les fichiers source sont bien cachés.
Tellement bien que j'ai pas trouve.
Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans souligné
ou changement de police.
Et le 403, tu fais quoi?
(Je sais je suis paresseux).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans souligné ou changement de police.
Et le 403, tu fais quoi?
(Je sais je suis paresseux).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Luc Hermitte
Richard Delorme wrote in news:41791ce9$0$15754$:
Si déjà gcc était utilisé de manière optimale...
Plus précisément, tu entends quoi ?
PS: en C++, on ne va pas utiliser strcat, mais std::string::operator+=() qui devait être encore plus rapide dès qu'assez de mémoire aura été réservée. Soit à la deuxième itération ou avant si c'est connu. (ceci dit, les sources sont inaccessibles)
C'est ce que fait le programme : http://kano.net/javabench/src/cpp/strcat.cpp Mais en jouant avec std::string::reserve() (je ne suis pas sûr de l'utilité).
En mettre un seul au début à 1+n*strlen("hello") OK, mais là il répète effectivement le code de +=.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Richard Delorme <abulmo@nospam.fr> wrote in
news:41791ce9$0$15754$7a628cd7@news.club-internet.fr:
Si déjà gcc était utilisé de manière optimale...
Plus précisément, tu entends quoi ?
PS: en C++, on ne va pas utiliser strcat, mais
std::string::operator+=() qui devait être encore plus rapide dès
qu'assez de mémoire aura été réservée. Soit à la deuxième itération
ou avant si c'est connu. (ceci dit, les sources sont inaccessibles)
C'est ce que fait le programme :
http://kano.net/javabench/src/cpp/strcat.cpp
Mais en jouant avec std::string::reserve() (je ne suis pas sûr de
l'utilité).
En mettre un seul au début à 1+n*strlen("hello") OK, mais là il répète
effectivement le code de +=.
--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
PS: en C++, on ne va pas utiliser strcat, mais std::string::operator+=() qui devait être encore plus rapide dès qu'assez de mémoire aura été réservée. Soit à la deuxième itération ou avant si c'est connu. (ceci dit, les sources sont inaccessibles)
C'est ce que fait le programme : http://kano.net/javabench/src/cpp/strcat.cpp Mais en jouant avec std::string::reserve() (je ne suis pas sûr de l'utilité).
En mettre un seul au début à 1+n*strlen("hello") OK, mais là il répète effectivement le code de +=.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Luc Hermitte
Jean-Marc Bourguet wrote in news::
Les fichiers source sont bien cachés. Tellement bien que j'ai pas trouve.
Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans
souligné ou changement de police.
Et le 403, tu fais quoi?
Rien. J'attends qu'il corrige ;)
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Jean-Marc Bourguet <jm@bourguet.org> wrote in
news:pxbzn2erebf.fsf@news.bourguet.org:
Les fichiers source sont bien cachés.
Tellement bien que j'ai pas trouve.
Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans
souligné ou changement de police.
Et le 403, tu fais quoi?
Rien. J'attends qu'il corrige ;)
--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
Les fichiers source sont bien cachés. Tellement bien que j'ai pas trouve.
Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans
souligné ou changement de police.
Et le 403, tu fais quoi?
Rien. J'attends qu'il corrige ;)
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Jean-Marc Bourguet
Richard Delorme writes:
os2 wrote:
salut
pour ceux désirant voir les performances de Java, C++ et GCJ dans quelques domaines j'ai effectué quelques tests
http://www.laboiteaprog.com/tutoriel725
bye ca serait possible d'avoir plus de details et les sources de tes
programmes.
A priori les programmes viennent de là : http://kano.net/javabench/ Et eux-même proviennent de là : http://shootout.alioth.debian.org/
Il y a deux tests ou le meilleur java de sa liste fait mieux que le plus mauvais C++. Si tes sources sont bien celles utilisees:
Pour objinst, ici 35% du temps est pris dans operator delete. La version Java est 19% plus rapide que la version C++ d'apres ses chiffres. Je me demande si le test est fait de sorte que le GC de Java se met en route.
Pour methcall, on dirait un test fait pour verifier que l'optimisation en contexte (celle qui permet d'inliner une fonction virtuelle parce que le JIT a remarque qu'elle seule est appelee) du JIT fonctionne bien (et on remarque la tres forte disparite entre Java et Java-serveur).
<tout aussi troll que le premier message> Conclusion: le seul avantage reel pour Java dans ces exemples c'est de ne pas desalloue dans les petits programmes et quand on utilise des fonctions virtuelles inutillement et les poids relatifs des differents tests ont ete ajuste de sorte que ca se change en un avantage pour Java. </tout aussi troll que le premier message>
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Richard Delorme <abulmo@nospam.fr> writes:
os2 wrote:
salut
pour ceux désirant voir les performances de Java, C++ et GCJ dans
quelques domaines
j'ai effectué quelques tests
http://www.laboiteaprog.com/tutoriel725
bye
ca serait possible d'avoir plus de details et les sources de tes
programmes.
A priori les programmes viennent de là :
http://kano.net/javabench/
Et eux-même proviennent de là :
http://shootout.alioth.debian.org/
Il y a deux tests ou le meilleur java de sa liste fait mieux que le
plus mauvais C++. Si tes sources sont bien celles utilisees:
Pour objinst, ici 35% du temps est pris dans operator delete. La
version Java est 19% plus rapide que la version C++ d'apres ses
chiffres. Je me demande si le test est fait de sorte que le GC de
Java se met en route.
Pour methcall, on dirait un test fait pour verifier que l'optimisation
en contexte (celle qui permet d'inliner une fonction virtuelle parce
que le JIT a remarque qu'elle seule est appelee) du JIT fonctionne
bien (et on remarque la tres forte disparite entre Java et
Java-serveur).
<tout aussi troll que le premier message>
Conclusion: le seul avantage reel pour Java dans ces exemples c'est de
ne pas desalloue dans les petits programmes et quand on utilise des
fonctions virtuelles inutillement et les poids relatifs des differents
tests ont ete ajuste de sorte que ca se change en un avantage pour
Java.
</tout aussi troll que le premier message>
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
pour ceux désirant voir les performances de Java, C++ et GCJ dans quelques domaines j'ai effectué quelques tests
http://www.laboiteaprog.com/tutoriel725
bye ca serait possible d'avoir plus de details et les sources de tes
programmes.
A priori les programmes viennent de là : http://kano.net/javabench/ Et eux-même proviennent de là : http://shootout.alioth.debian.org/
Il y a deux tests ou le meilleur java de sa liste fait mieux que le plus mauvais C++. Si tes sources sont bien celles utilisees:
Pour objinst, ici 35% du temps est pris dans operator delete. La version Java est 19% plus rapide que la version C++ d'apres ses chiffres. Je me demande si le test est fait de sorte que le GC de Java se met en route.
Pour methcall, on dirait un test fait pour verifier que l'optimisation en contexte (celle qui permet d'inliner une fonction virtuelle parce que le JIT a remarque qu'elle seule est appelee) du JIT fonctionne bien (et on remarque la tres forte disparite entre Java et Java-serveur).
<tout aussi troll que le premier message> Conclusion: le seul avantage reel pour Java dans ces exemples c'est de ne pas desalloue dans les petits programmes et quand on utilise des fonctions virtuelles inutillement et les poids relatifs des differents tests ont ete ajuste de sorte que ca se change en un avantage pour Java. </tout aussi troll que le premier message>
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
James Kanze
Luc Hermitte writes:
|> Jean-Marc Bourguet wrote in |> news::
|> >> Les fichiers source sont bien cachés.
|> > Tellement bien que j'ai pas trouve.
|> Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans |> souligné ou changement de police.
De quoi tu te plains ? Il aurait pû le faire blanc sur blanc.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Luc Hermitte <hermitte@free.fr.invalid> writes:
|> Jean-Marc Bourguet <jm@bourguet.org> wrote in
|> news:pxbk6tisvkq.fsf@news.bourguet.org:
|> >> Les fichiers source sont bien cachés.
|> > Tellement bien que j'ai pas trouve.
|> Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans
|> souligné ou changement de police.
De quoi tu te plains ? Il aurait pû le faire blanc sur blanc.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> Si, si. Tout à la fin, il y a écrit "ici" en noir sur blanc sans |> souligné ou changement de police.
De quoi tu te plains ? Il aurait pû le faire blanc sur blanc.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Jean-Marc Bourguet writes:
|> Je ne fais pas confiance aux benchmarks que je n'ai pas fait |> moi-meme: ils n'ont pas les memes prejuges que moi :-)
Le dicton exacte, je crois, c'est : « ne jamais faire confiance à un benchmark que tu n'as pas faussé toi-même ».
Ceci dit, si le but est de faire un benchmark où le Java tourne plus vite que le C++, je saurais le faire. Sans tricher sur le C++, non plus. Évidemment, l'inverse est aussi vrai.
Malheureusement pour le Java, les benchmarks où gagne le C++ ressemble plus aux problèmes dans mon application. Mais ce n'est pas forcement vrai pour tout le monde.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Jean-Marc Bourguet <jm@bourguet.org> writes:
|> Je ne fais pas confiance aux benchmarks que je n'ai pas fait
|> moi-meme: ils n'ont pas les memes prejuges que moi :-)
Le dicton exacte, je crois, c'est : « ne jamais faire confiance à un
benchmark que tu n'as pas faussé toi-même ».
Ceci dit, si le but est de faire un benchmark où le Java tourne plus
vite que le C++, je saurais le faire. Sans tricher sur le C++, non plus.
Évidemment, l'inverse est aussi vrai.
Malheureusement pour le Java, les benchmarks où gagne le C++ ressemble
plus aux problèmes dans mon application. Mais ce n'est pas forcement
vrai pour tout le monde.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> Je ne fais pas confiance aux benchmarks que je n'ai pas fait |> moi-meme: ils n'ont pas les memes prejuges que moi :-)
Le dicton exacte, je crois, c'est : « ne jamais faire confiance à un benchmark que tu n'as pas faussé toi-même ».
Ceci dit, si le but est de faire un benchmark où le Java tourne plus vite que le C++, je saurais le faire. Sans tricher sur le C++, non plus. Évidemment, l'inverse est aussi vrai.
Malheureusement pour le Java, les benchmarks où gagne le C++ ressemble plus aux problèmes dans mon application. Mais ce n'est pas forcement vrai pour tout le monde.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Matthieu Moy writes:
|> Jean-Marc Bourguet writes:
|> > Moi je ne m'en fous pas. Mais doubler ma memoire occupee (overhead |> > commun d'un GC d'apres ce que j'ai entendu dire, naturellement il |> > doit y avoir des exceptions)
|> Ce n'est pas que le GC qui bouffe de la mémoire en Java :
En général, un bon GC serait plus rapide qu'une gestion manuelle de la mémoire, mais la plupart du temps, il en aurait besoin d'environ deux fois plus de mémoire.
Dans le cas de Java, au moins avec le JVM de JDK quand je l'ai connu, la VM alloue d'office un bloc énorme de mémore. Qu'on en ait besoin ou non.
|> Toutes les classes héritent de Object, qui contient déjà pas mal de |> choses pour la gestion des verrous par exemple. Résultat, un Integer |> prends entre 20 et 30 octets de mémoire si mes souvenirs sont bons.
Mais un int, non.
Une bonne VM pourrait optimiser ça sans trop de problèmes. Mais c'est vrai que prèsque tout l'effort jusqu'ici s'est mis dans l'optimisation de la vitesse, et non l'utilisation de la mémoire.
|> Après, faut voir : Sur des machines récentes et selon les |> applications, ce n'est pas forcément la mémoire qui est limitante |> ...
Elle joue toujours une rôle. Plus un objet est grand, moins il en passe à la fois dans la cache.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > Moi je ne m'en fous pas. Mais doubler ma memoire occupee (overhead
|> > commun d'un GC d'apres ce que j'ai entendu dire, naturellement il
|> > doit y avoir des exceptions)
|> Ce n'est pas que le GC qui bouffe de la mémoire en Java :
En général, un bon GC serait plus rapide qu'une gestion manuelle de la
mémoire, mais la plupart du temps, il en aurait besoin d'environ deux
fois plus de mémoire.
Dans le cas de Java, au moins avec le JVM de JDK quand je l'ai connu, la
VM alloue d'office un bloc énorme de mémore. Qu'on en ait besoin ou non.
|> Toutes les classes héritent de Object, qui contient déjà pas mal de
|> choses pour la gestion des verrous par exemple. Résultat, un Integer
|> prends entre 20 et 30 octets de mémoire si mes souvenirs sont bons.
Mais un int, non.
Une bonne VM pourrait optimiser ça sans trop de problèmes. Mais c'est
vrai que prèsque tout l'effort jusqu'ici s'est mis dans l'optimisation
de la vitesse, et non l'utilisation de la mémoire.
|> Après, faut voir : Sur des machines récentes et selon les
|> applications, ce n'est pas forcément la mémoire qui est limitante
|> ...
Elle joue toujours une rôle. Plus un objet est grand, moins il en passe
à la fois dans la cache.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > Moi je ne m'en fous pas. Mais doubler ma memoire occupee (overhead |> > commun d'un GC d'apres ce que j'ai entendu dire, naturellement il |> > doit y avoir des exceptions)
|> Ce n'est pas que le GC qui bouffe de la mémoire en Java :
En général, un bon GC serait plus rapide qu'une gestion manuelle de la mémoire, mais la plupart du temps, il en aurait besoin d'environ deux fois plus de mémoire.
Dans le cas de Java, au moins avec le JVM de JDK quand je l'ai connu, la VM alloue d'office un bloc énorme de mémore. Qu'on en ait besoin ou non.
|> Toutes les classes héritent de Object, qui contient déjà pas mal de |> choses pour la gestion des verrous par exemple. Résultat, un Integer |> prends entre 20 et 30 octets de mémoire si mes souvenirs sont bons.
Mais un int, non.
Une bonne VM pourrait optimiser ça sans trop de problèmes. Mais c'est vrai que prèsque tout l'effort jusqu'ici s'est mis dans l'optimisation de la vitesse, et non l'utilisation de la mémoire.
|> Après, faut voir : Sur des machines récentes et selon les |> applications, ce n'est pas forcément la mémoire qui est limitante |> ...
Elle joue toujours une rôle. Plus un objet est grand, moins il en passe à la fois dans la cache.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
