JKB a écrit :
une métaphore que tu devrais comprendre
l'obj et les design pattern sont à l'informatique se que sont les
patates (théorie des ensembles) aux maths
c'est puissant mais cela ne te dit pas si a entier est premier
pour le savoir tu as besoin d'un traitement
JKB a écrit :
une métaphore que tu devrais comprendre
l'obj et les design pattern sont à l'informatique se que sont les
patates (théorie des ensembles) aux maths
c'est puissant mais cela ne te dit pas si a entier est premier
pour le savoir tu as besoin d'un traitement
JKB a écrit :
une métaphore que tu devrais comprendre
l'obj et les design pattern sont à l'informatique se que sont les
patates (théorie des ensembles) aux maths
c'est puissant mais cela ne te dit pas si a entier est premier
pour le savoir tu as besoin d'un traitement
Le Fri, 24 Sep 2010 10:19:15 +0200,
remy écrivait :JKB a écrit :
mais tu es bouché, la généricité n'est pas dans l' algo qui traite les
données ,mais dans le conteneur qui encapsule la donnée
C'est toi qui es bouché, c'est exactement ce que je te dis.l'algo est le même ,je répète
S'il est générique, oui,
assertion n'a _aucune_ raison d'être vraie.
Regarde un peu Lapack.
Tu verras qu'à un problème simple qu'est l'inversion de matr ice, il
y a des tas de solutions en fonction de tes données.
je trie un entier
ou je trie un conteneur qui contient un entier
point barre ,la différence s'arrête lÃ
Non. On ne trie pas que des entiers dans la vie. On peut trier des
chaînes de caractères, des distances dans un graphe, et surt out, on
peut avoir besoin d'un algorithme thread safe, donc soit coller un
mutex sur le tout, soit copier les données. C'est _beaucoup_ plus
compliqué que tu ne le penses et les différences de performa nces ne
sont pas dans le trait du crayon. Par ailleurs, tu ne réponds pas
sur les problèmes de défauts de pages introduits par la cons ommation
de ressources induite par la programmation objet générique.
la méthode de tri est la même ,c'est la même ,c'est l a même,c'est la
même,après si le mec est assez con pour mettre dans ton cont eneur non
pas un entier mais 100k de données
Je dois encore pouvoir les trier. De toute façon, répond à ce que
j'ai écrit sur les calculs d'itinéraires.
Le Fri, 24 Sep 2010 10:19:15 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
mais tu es bouché, la généricité n'est pas dans l' algo qui traite les
données ,mais dans le conteneur qui encapsule la donnée
C'est toi qui es bouché, c'est exactement ce que je te dis.
l'algo est le même ,je répète
S'il est générique, oui,
assertion n'a _aucune_ raison d'être vraie.
Regarde un peu Lapack.
Tu verras qu'à un problème simple qu'est l'inversion de matr ice, il
y a des tas de solutions en fonction de tes données.
je trie un entier
ou je trie un conteneur qui contient un entier
point barre ,la différence s'arrête lÃ
Non. On ne trie pas que des entiers dans la vie. On peut trier des
chaînes de caractères, des distances dans un graphe, et surt out, on
peut avoir besoin d'un algorithme thread safe, donc soit coller un
mutex sur le tout, soit copier les données. C'est _beaucoup_ plus
compliqué que tu ne le penses et les différences de performa nces ne
sont pas dans le trait du crayon. Par ailleurs, tu ne réponds pas
sur les problèmes de défauts de pages introduits par la cons ommation
de ressources induite par la programmation objet générique.
la méthode de tri est la même ,c'est la même ,c'est l a même,c'est la
même,après si le mec est assez con pour mettre dans ton cont eneur non
pas un entier mais 100k de données
Je dois encore pouvoir les trier. De toute façon, répond à ce que
j'ai écrit sur les calculs d'itinéraires.
Le Fri, 24 Sep 2010 10:19:15 +0200,
remy écrivait :JKB a écrit :
mais tu es bouché, la généricité n'est pas dans l' algo qui traite les
données ,mais dans le conteneur qui encapsule la donnée
C'est toi qui es bouché, c'est exactement ce que je te dis.l'algo est le même ,je répète
S'il est générique, oui,
assertion n'a _aucune_ raison d'être vraie.
Regarde un peu Lapack.
Tu verras qu'à un problème simple qu'est l'inversion de matr ice, il
y a des tas de solutions en fonction de tes données.
je trie un entier
ou je trie un conteneur qui contient un entier
point barre ,la différence s'arrête lÃ
Non. On ne trie pas que des entiers dans la vie. On peut trier des
chaînes de caractères, des distances dans un graphe, et surt out, on
peut avoir besoin d'un algorithme thread safe, donc soit coller un
mutex sur le tout, soit copier les données. C'est _beaucoup_ plus
compliqué que tu ne le penses et les différences de performa nces ne
sont pas dans le trait du crayon. Par ailleurs, tu ne réponds pas
sur les problèmes de défauts de pages introduits par la cons ommation
de ressources induite par la programmation objet générique.
la méthode de tri est la même ,c'est la même ,c'est l a même,c'est la
même,après si le mec est assez con pour mettre dans ton cont eneur non
pas un entier mais 100k de données
Je dois encore pouvoir les trier. De toute façon, répond à ce que
j'ai écrit sur les calculs d'itinéraires.
Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilation). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilation). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilation). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
JKB wrote:Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive p eu ou prou
aux mêmes performances qu'un programme natif n'est pas éto nnant en
soit (même s'il faut rajouter l'étape de compilation). C'e st la gestion
de cette mémoire qui grève les performances (à moins d'a voir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'in fluence sur
la rapidité d'exécution d'un programme Java. C'est assez e ffarant.
Je pense que c'est tout à fait exact, le compilateur à la volée H otSpot
génère des tas de bouts de code machine qui occupent la mémoire. De même
les objets sont alloués dynamiquement et restent là tant que le gar bage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner sur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entrées sorti es et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machi nes
...
JKB <jkb@koenigsberg.invalid> wrote:
Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive p eu ou prou
aux mêmes performances qu'un programme natif n'est pas éto nnant en
soit (même s'il faut rajouter l'étape de compilation). C'e st la gestion
de cette mémoire qui grève les performances (à moins d'a voir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'in fluence sur
la rapidité d'exécution d'un programme Java. C'est assez e ffarant.
Je pense que c'est tout à fait exact, le compilateur à la volée H otSpot
génère des tas de bouts de code machine qui occupent la mémoire. De même
les objets sont alloués dynamiquement et restent là tant que le gar bage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner sur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entrées sorti es et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machi nes
...
JKB wrote:Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive p eu ou prou
aux mêmes performances qu'un programme natif n'est pas éto nnant en
soit (même s'il faut rajouter l'étape de compilation). C'e st la gestion
de cette mémoire qui grève les performances (à moins d'a voir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'in fluence sur
la rapidité d'exécution d'un programme Java. C'est assez e ffarant.
Je pense que c'est tout à fait exact, le compilateur à la volée H otSpot
génère des tas de bouts de code machine qui occupent la mémoire. De même
les objets sont alloués dynamiquement et restent là tant que le gar bage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner sur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entrées sorti es et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machi nes
...
Michel Talon a écrit :JKB wrote:Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilation). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Je pense que c'est tout à fait exact, le compilateur à la volée HotSpot
génère des tas de bouts de code machine qui occupent la mémoire. De même
les objets sont alloués dynamiquement et restent là tant que le garbage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner sur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entrées sorties et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machines
...
d'un autre côté une machine de base dispose en entrée de gamme
d'un minimum de 2 à 3 Go de ram
je ne dis pas qu'il n'y a pas ,un surcout lié à la consommation mémoire
mais l'obj ne se limite pas à java ,même si c'est l'un des rares à avoir
réussi à imposer cette approche, le c++ en consomme nettement moins
mais je suis complètement d'accord il y a un surcout
Michel Talon a écrit :
JKB <jkb@koenigsberg.invalid> wrote:
Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilation). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Je pense que c'est tout à fait exact, le compilateur à la volée HotSpot
génère des tas de bouts de code machine qui occupent la mémoire. De même
les objets sont alloués dynamiquement et restent là tant que le garbage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner sur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entrées sorties et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machines
...
d'un autre côté une machine de base dispose en entrée de gamme
d'un minimum de 2 à 3 Go de ram
je ne dis pas qu'il n'y a pas ,un surcout lié à la consommation mémoire
mais l'obj ne se limite pas à java ,même si c'est l'un des rares à avoir
réussi à imposer cette approche, le c++ en consomme nettement moins
mais je suis complètement d'accord il y a un surcout
Michel Talon a écrit :JKB wrote:Le problème de java n'est pas tant le code interprété ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilation). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sérieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Je pense que c'est tout à fait exact, le compilateur à la volée HotSpot
génère des tas de bouts de code machine qui occupent la mémoire. De même
les objets sont alloués dynamiquement et restent là tant que le garbage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner sur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entrées sorties et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machines
...
d'un autre côté une machine de base dispose en entrée de gamme
d'un minimum de 2 à 3 Go de ram
je ne dis pas qu'il n'y a pas ,un surcout lié à la consommation mémoire
mais l'obj ne se limite pas à java ,même si c'est l'un des rares à avoir
réussi à imposer cette approche, le c++ en consomme nettement moins
mais je suis complètement d'accord il y a un surcout
Le Fri, 24 Sep 2010 11:41:50 +0200,
remy écrivait :Michel Talon a écrit :JKB wrote:Le problème de java n'est pas tant le code interpré té ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilati on). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sé rieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Je pense que c'est tout à fait exact, le compilateur à la v olée HotSpot
génère des tas de bouts de code machine qui occupent la mà ©moire. De même
les objets sont alloués dynamiquement et restent là tant qu e le garbage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner s ur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entré es sorties et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machines
...
d'un autre côté une machine de base dispose en entrée d e gamme
d'un minimum de 2 Ã 3 Go de ram
C'est parfaitement ridicule actuellement pour n'importe quel
traitement de données (surtout fait en Java).je ne dis pas qu'il n'y a pas ,un surcout lié à la consommat ion mémoire
mais l'obj ne se limite pas à java ,même si c'est l'un des r ares à avoir
réussi à imposer cette approche, le c++ en consomme nettem ent moins
mais je suis complètement d'accord il y a un surcout
Je reprends mon exemple : 400 Mo contre 6.5 Go. Quand tu t'appelles
Mappy, ça compte. Quant à l'occupation mémoire, une foi s le soft
compilé, Java ou C++, même combat !
JKB
Le Fri, 24 Sep 2010 11:41:50 +0200,
remy <remy@fctpas.fr> écrivait :
Michel Talon a écrit :
JKB <jkb@koenigsberg.invalid> wrote:
Le problème de java n'est pas tant le code interpré té ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilati on). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sé rieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Je pense que c'est tout à fait exact, le compilateur à la v olée HotSpot
génère des tas de bouts de code machine qui occupent la mà ©moire. De même
les objets sont alloués dynamiquement et restent là tant qu e le garbage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner s ur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entré es sorties et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machines
...
d'un autre côté une machine de base dispose en entrée d e gamme
d'un minimum de 2 Ã 3 Go de ram
C'est parfaitement ridicule actuellement pour n'importe quel
traitement de données (surtout fait en Java).
je ne dis pas qu'il n'y a pas ,un surcout lié à la consommat ion mémoire
mais l'obj ne se limite pas à java ,même si c'est l'un des r ares à avoir
réussi à imposer cette approche, le c++ en consomme nettem ent moins
mais je suis complètement d'accord il y a un surcout
Je reprends mon exemple : 400 Mo contre 6.5 Go. Quand tu t'appelles
Mappy, ça compte. Quant à l'occupation mémoire, une foi s le soft
compilé, Java ou C++, même combat !
JKB
Le Fri, 24 Sep 2010 11:41:50 +0200,
remy écrivait :Michel Talon a écrit :JKB wrote:Le problème de java n'est pas tant le code interpré té ou compilé que
l'utilisation énorme de ressources mémoire. Qu'on arrive peu ou prou
aux mêmes performances qu'un programme natif n'est pas étonnant en
soit (même s'il faut rajouter l'étape de compilati on). C'est la gestion
de cette mémoire qui grève les performances (à moins d'avoir une
foultitude de Go dès qu'on fait tourner un truc sé rieux). Regarde un
peu les différentes specs des allocateurs de Solaris et l'influence sur
la rapidité d'exécution d'un programme Java. C'est assez effarant.
Je pense que c'est tout à fait exact, le compilateur à la v olée HotSpot
génère des tas de bouts de code machine qui occupent la mà ©moire. De même
les objets sont alloués dynamiquement et restent là tant qu e le garbage
collector ne les ramasse pas. Ce n'est pas fait pour tourner sur des
petites machines, c'est fait pour un usage industriel, pour tourner s ur
de gros serveurs avec des tonnes de mémoire. Dans ce cas, c'est
efficace. De même le ZFS de Sun cache massivement les entré es sorties et
utilise de grosses quantités de mémoire. Tous ces softs ont été pondus
par des gens qui voulaient pousser les clients à upgrader leurs machines
...
d'un autre côté une machine de base dispose en entrée d e gamme
d'un minimum de 2 Ã 3 Go de ram
C'est parfaitement ridicule actuellement pour n'importe quel
traitement de données (surtout fait en Java).je ne dis pas qu'il n'y a pas ,un surcout lié à la consommat ion mémoire
mais l'obj ne se limite pas à java ,même si c'est l'un des r ares à avoir
réussi à imposer cette approche, le c++ en consomme nettem ent moins
mais je suis complètement d'accord il y a un surcout
Je reprends mon exemple : 400 Mo contre 6.5 Go. Quand tu t'appelles
Mappy, ça compte. Quant à l'occupation mémoire, une foi s le soft
compilé, Java ou C++, même combat !
JKB
Toxico Nimbus wrote:purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
Je ne suis pas du tout un utilisateur de Java, mais je crois que les
performances sont globalement équivalentes à celles du C (idem pour le
Lisp d'ailleurs) donc je ne vois pas ce qui peut te faire dire ça.
D'ailleurs il y a énormément de serveurs très sollicités qui tournent
via Java.
Maintenant s'il s'agit de calcul scientifique, comme ce que
fait JKB, alors évidemment c'est Fortran ou C.
Je ne dirais pas la même chose pour des langages qui tournent via un
interpréteur, comme perl, python, etc. Là ça peut passer s'il y a peu de
traîtement et beaucoup d'entrées sorties, ce qui est un cas assez
général, autrement il faut au moins que les parties critiques soient
codées de façon compilée (par exemple pyrex pour python).
Toxico Nimbus <ToxN@free.fr> wrote:
purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
Je ne suis pas du tout un utilisateur de Java, mais je crois que les
performances sont globalement équivalentes à celles du C (idem pour le
Lisp d'ailleurs) donc je ne vois pas ce qui peut te faire dire ça.
D'ailleurs il y a énormément de serveurs très sollicités qui tournent
via Java.
Maintenant s'il s'agit de calcul scientifique, comme ce que
fait JKB, alors évidemment c'est Fortran ou C.
Je ne dirais pas la même chose pour des langages qui tournent via un
interpréteur, comme perl, python, etc. Là ça peut passer s'il y a peu de
traîtement et beaucoup d'entrées sorties, ce qui est un cas assez
général, autrement il faut au moins que les parties critiques soient
codées de façon compilée (par exemple pyrex pour python).
Toxico Nimbus wrote:purement malhonnête. Maintenant, il y a des optimisations qu'il vaut
mieux penser dès le début ; par exemple quand on voit le coût de
l'interfaçage du Java et du C, on réfléchit à deux fois avant de traiter
un gros volume de données en Java.
Je ne suis pas du tout un utilisateur de Java, mais je crois que les
performances sont globalement équivalentes à celles du C (idem pour le
Lisp d'ailleurs) donc je ne vois pas ce qui peut te faire dire ça.
D'ailleurs il y a énormément de serveurs très sollicités qui tournent
via Java.
Maintenant s'il s'agit de calcul scientifique, comme ce que
fait JKB, alors évidemment c'est Fortran ou C.
Je ne dirais pas la même chose pour des langages qui tournent via un
interpréteur, comme perl, python, etc. Là ça peut passer s'il y a peu de
traîtement et beaucoup d'entrées sorties, ce qui est un cas assez
général, autrement il faut au moins que les parties critiques soient
codées de façon compilée (par exemple pyrex pour python).
Quant à l'occupation mémoire, une fois le soft
compilé, Java ou C++, même combat !
Quant à l'occupation mémoire, une fois le soft
compilé, Java ou C++, même combat !
Quant à l'occupation mémoire, une fois le soft
compilé, Java ou C++, même combat !
Toxico Nimbus a écrit :Le 23/09/2010 22:58, PP a écrit :L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand même.
l'optimisation réside dans la modularité du code
en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de manière
élégante les interactions de ses différents traitements
mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une fois sur 3
Toxico Nimbus a écrit :
Le 23/09/2010 22:58, PP a écrit :
L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand même.
l'optimisation réside dans la modularité du code
en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de manière
élégante les interactions de ses différents traitements
mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une fois sur 3
Toxico Nimbus a écrit :Le 23/09/2010 22:58, PP a écrit :L'optimisation DOIT rester dans l'esprit des développeurs pour un tas
d'autres choses encore. Au niveau software certes, mais au niveau
hardware encore plus ! Ce qui semble encore mal barré.
Plus personne n'optimise plus et les clients achètent quand même.
l'optimisation réside dans la modularité du code
en gros ,
l'obj est une manière élégante de rendre modulaire
un traitement et les design pattern permettent d'agencer de manière
élégante les interactions de ses différents traitements
mais ses notions ne servent pas à effectuer un traitement
(par exemple un tri) le traitement lui il est codé une seule fois et
certainement plus optimisé qu'un machin bidule écrit à l'arrache par un
prétendu auto proclamé expert, qui en plus se plante une fois sur 3