Impact du multi-core sur la consommation mémoire

[JYS]

Salut les Canards Xperts,

J'ai besoin de vos avis éclairés sur quelques points:
- Un proc multi-core consomme plus de mémoire qu'un proc mono-core, j'ai bon là ? (et pourquoi ? )
- Est-ce OS dépendant ? (Linux est ma cible privilégié).
- Est-ce dépendant des cas d'utilisations ?
- Si oui, quel est l'impact en % sur la mémoire.

Merci bcp si vous pouviez éclairer ma lanterne sur ce pb obscur pour moi.

[Wanou]

Salut les Canards Xperts,

J'ai besoin de vos avis éclairés sur quelques points:
- Un proc multi-core consomme plus de mémoire qu'un proc mono-core, j'ai bon là ? (et pourquoi ? )
- Est-ce OS dépendant ? (Linux est ma cible privilégié).
- Est-ce dépendant des cas d'utilisations ?
- Si oui, quel est l'impact en % sur la mémoire.

Merci bcp si vous pouviez éclairer ma lanterne sur ce pb obscur pour moi.

Ben... Je ne veux pas dire de conneries, mais à ma connaissance, non.
Le fait qu'il soit multi core ne change rien au fait que la mémoire est centralisée. Après, que ces données soient dans les différents caches, soit, mais c'est peanuts, et de toute facon, on ne dit jamais : j'ai 4Go + 2x128K+2x2Mo de mémoire. Le cache, on l'oublie.
Après, que les algo, notamment les sémaphores, consomment un peu de mémoire, je veux bien. Mais de toute facon, vu les OS multitaches de nos jours, je ne vois pas trop comment on peut s'en passer.

Maintenant, je laisse la parole aux experts....

[Yasko]

Je dirais : la RAM non, le cache oui.
C'est pour ça que chaque core a bien souvent son propre cache. Et c'est aussi pour ça que dans le cas de SMT/hyperthreading, on peut parfois observer une dégradation des perfs.

- Est-ce OS dépendant ? (Linux est ma cible privilégié).
Non (géré par le CPU)
- Est-ce dépendant des cas d'utilisations ?
Oui, mais vu que chaque core est assez cloisonné (à part pour le L3), c'est indépendant
- Si oui, quel est l'impact en % sur la mémoire.
N/A

Enfin, c'est mon avis très personnel, je peux me planter...

[DJ_DaMS]

Fefe ?

[Wanou]

Fefe ?

C'est marrant, je l'avais pensé....

FEFE!!!!! On a besoin de toi !!!!

[JYS]

Je pose la question, car on a observé une augmentation très nette de la taille de nos JVM sous Linux suivant le nombre de cores utilisés, et ce sur différents serveurs...Ce serait plus un bug JVM que qqchose lié à des contraintes matérielles
PS: Nos applis sont fortements multi-Thread (en général sur un serveur on lance une douzaine de JVM comprennant une cinquantaine de threads chacunes)

[Yasko]

Bon, en attendant d'avoir une réponse à ta question, il existe des outils dits de profiling (le projet TPTP d'eclipse.org par exemple) qui permettent de savoir entre autres comment est utilisé la mémoire.
Et je ne pense pas que ce soit un bug. Tu fais tourner quoi comme appli ? Un serveur web/servlet/EJB/... ?

Edit : Je pose la question de l'appli que tu fais tourner, car si tu as un nombre dynamique de thread, c'est normal que ta JVM grossisse (tu aurais dû mettre en 1er post directement ton observation sur la JVM plutôt que "Un proc multi-core consomme plus de mémoire qu'un proc mono-core, j'ai bon là ?")

[fefe]

J'arrive, j'arrive...
La reponse est oui et non bien sur .
Si tu confies exactement la meme charge a ta machine, alors non le fait d'avoir une machine multi core ne changera en rien ta memoire consommee (ou si peu, vu que quelques modules du kernel seront un peu plus gros, mais rien de sensible).

En revanche si tu as une appli qui detecte que tu as un multi core et se configure de maniere differente pour l'exploiter, alors oui tu as de bonnes chances de consommer plus de memoire.

Par exemple dans un modele de parallelisation producer-consummer, tu te retrouves avec des buffers non negligeables entre les 2 qui etaient generalement tres petits dans une version destinee a un simple CPU (c'est un choix d'optimization judicieux, cela ne signifie pas que ce sera le cas systematiquement). Dans le cas d'un modele producer consummer les buffers sont employes pour pipeliner les taches, ici la taille du buffer est dependant de la latence d'une tache et de son debit et on augmente les 2 dans ce type de modele donc l'augmentation de la taille des buffer est ~= augmentation du debit x augmentation de la latence d'une tache.

Dans un modele de data parallelisme on peut partitionner les donnees existantes entre 2 CPUs ou choisir de traiter 2x plus de donnees en simultane (ou si on a optimise l'appli un facteur compris entre 1 et 2).

Bref, il est probable que ta JVM se rende compte que tu as 2 cpus et essaye d'en tirer partie, et donc alloue plus de buffers.

c'est normal que ta JVM grossisse (tu aurais dû mettre en 1er post directement ton observation sur la JVM plutôt que "Un proc multi-core consomme plus de mémoire qu'un proc mono-core, j'ai bon là ?")

L'augmentation de la taille du code en memoire due a la multiplication des threads est generalement peu visible face a la taille des donnees (ca depend des applis), mais c'est effectivement une autre source d'augmentation.

[JYS]

Bon, en attendant d'avoir une réponse à ta question, il existe des outils dits de profiling (le projet TPTP d'eclipse.org par exemple) qui permettent de savoir entre autres comment est utilisé la mémoire.
Et je ne pense pas que ce soit un bug. Tu fais tourner quoi comme appli ? Un serveur web/servlet/EJB/... ?

Edit : Je pose la question de l'appli que tu fais tourner, car si tu as un nombre dynamique de thread, c'est normal que ta JVM grossisse (tu aurais dû mettre en 1er post directement ton observation sur la JVM plutôt que "Un proc multi-core consomme plus de mémoire qu'un proc mono-core, j'ai bon là ?")

Non, Yasko, ne nb de Thread de nos applis n'est pas proportionnel au nb de CPU. Je précise notre pb:
On lance une appli de 50 Threads sur un single-core, puis on lance cette même appli sur un Dual-core et enfin sur un Quad-Core.
On observe une consmmation de la mémoire à chaque fois plus importante. Le nb de Thread actives dans la JVM est le même pour chaque cas de figure (observation faite avec JConsole et dump des threads).

PS1: Et oui, on utilise plusieurs outils de profiling notemment pour résoudre les memory leaks (TPTP, OptimeIT, Yourkit, ...)
PS2: Nos applis (développées avec nos p'tites mains) sont des serveurs de telephonie sous IP, les performances et la bonne utilisation de multi-procs/cores est primordial.

J'arrive, j'arrive...
La reponse est oui et non bien sur .
Si tu confies exactement la meme charge a ta machine, alors non le fait d'avoir une machine multi core ne changera en rien ta memoire consommee (ou si peu, vu que quelques modules du kernel seront un peu plus gros, mais rien de sensible).

En revanche si tu as une appli qui detecte que tu as un multi core et se configure de maniere differente pour l'exploiter, alors oui tu as de bonnes chances de consommer plus de memoire.

Par exemple dans un modele de parallelisation producer-consummer, tu te retrouves avec des buffers non negligeables entre les 2 qui etaient generalement tres petits dans une version destinee a un simple CPU (c'est un choix d'optimization judicieux, cela ne signifie pas que ce sera le cas systematiquement). Dans le cas d'un modele producer consummer les buffers sont employes pour pipeliner les taches, ici la taille du buffer est dependant de la latence d'une tache et de son debit et on augmente les 2 dans ce type de modele donc l'augmentation de la taille des buffer est ~= augmentation du debit x augmentation de la latence d'une tache.

Dans un modele de data parallelisme on peut partitionner les donnees existantes entre 2 CPUs ou choisir de traiter 2x plus de donnees en simultane (ou si on a optimise l'appli un facteur compris entre 1 et 2).

Bref, il est probable que ta JVM se rende compte que tu as 2 cpus et essaye d'en tirer partie, et donc alloue plus de buffers.



L'augmentation de la taille du code en memoire due a la multiplication des threads est generalement peu visible face a la taille des donnees (ca depend des applis), mais c'est effectivement une autre source d'augmentation.

OK, merci, je vais regarder du côté des options de la JVM si il n'y a pas une optimisations d'activées pour employer au mieux le multi-core => d'oû l'impact sur la mémoire consommée.

PS: je vais regarder si les process C sont également impactés...là ce serait plus louche.

[Tramb]

JVM, performance, ne pas troller, ne pas troller.... gnnnnnn.... aaaaargh

Sinon comme le dit fefe l'implémentation même de la JVM et du kernel sous-jacent multiplient sans doute les buffers en fonction du nombre de cores (OpenMP style?) mais ça doit sans doute être marginal par rapport au storage additionnel par thread (stack, TLS, divers caches ...).

[Wanou]

JVM, performance, ne pas troller, ne pas troller.... gnnnnnn.... aaaaargh

Pourquoi ne pas troller ?
Quelqu'un a déjà vu quelque chose de performant dans une JVM ?
N'importe quoi, hein !

Moi, perso, le seul truc que j'ai vu qui soit correct dans une jvm, c'est une appli pour les rubik's cube.

Sinon, les JVM C'EST LE MAL !

C'était un message du Comité contre le Developpement d'Appli Pourries sous Java.

[fefe]

Sinon, les JVM C'EST LE MAL !

C'était un message du Comité contre le Developpement d'Appli Pourries sous Java.

Pourquoi se limiter a Java c'est le mal ? Tous les languages de haut niveau c'est le mal !

L'assembleur est limite trop haut niveau

/me retourne a coder du x86 en hexa (et non ce n'est pas une blague)

JVM, performance, ne pas troller, ne pas troller.... gnnnnnn.... aaaaargh

Sinon comme le dit fefe l'implémentation même de la JVM et du kernel sous-jacent multiplient sans doute les buffers en fonction du nombre de cores (OpenMP style?) mais ça doit sans doute être marginal par rapport au storage additionnel par thread (stack, TLS, divers caches ...).

Il a le meme nombre de threads donc en theorie ca ne vient pas de la...

[newbie06]

Tiens z'avez oublie de parler de speedup surlineaire. J'ai vu des benchmarks ou une appli tourne plus vite quand il y a plus de CPU et ce sans multithreading. La raison est assez amusante : la coherence materielle et le fait que le kernel arrete de polluer les caches du CPU sur lequel tourne l'appli.

[fefe]

Les speedups superlineaires existent depuis que les applis multithreadees existent . Le premier cours de parallelisme que j'ai eu, on m'a montre des speedup superlineaires sur de vieux Cray (avec entre autre les fameux vector bumps).

Sur les cpus actuels c'est essentiellement lie aux caches mais pas uniquement dans le cas que tu decris cela peut aussi etre lie a la pollution de toutes les tables employees dans les mecanismes de prediction, en partant des branchements jusqu'au prefetchers, et bien sur les caches et TLB.

PS: c'est OOT les speedups superlineaire, il parlait d'occupation memoire pas de perf (et comme certains l'ont fait remarquer Java et perf dans le meme thread groumpf).

[newbie06]

Les speedups superlineaires existent depuis que les applis multithreadees existent . Le premier cours de parallelisme que j'ai eu, on m'a montre des speedup superlineaires sur de vieux Cray (avec entre autre les fameux vector bumps).

Tu voulais dire applications single-threadees sur des machines a plusieurs CPU je suppose.
Et le vector bump, je connais pas : c'est la capacite pour une application d'utiliser les unites vectorielles d'un autre CPU ?

PS: c'est OOT les speedups superlineaire, il parlait d'occupation memoire pas de perf (et comme certains l'ont fait remarquer Java et perf dans le meme thread groumpf).

Mais non c'est tout a fait on topic : 2x plus de cache pour 2 CPUs => plus de perf mais plus d'utilisation memoire on chip (OK, chuis pas credible ).

[fefe]

Tu voulais dire applications single-threadees sur des machines a plusieurs CPU je suppose.
Et le vector bump, je connais pas : c'est la capacite pour une application d'utiliser les unites vectorielles d'un autre CPU ?

- oui, appli 1 thread, 2+ cpus (mais en general les effets en question sont souvent negligeables a moins que l'OS ou autre thread pollueur soit schedule tres/trop frequement)
- et les vectors bumps sont ce que tu observes si tu plot le speedup en fonction de la taille des donnees sur une machine vectorielle (avec une longueur de vecteur constante).
Ta courbe aura une forme en marches d'escalier, donc si tu cherches a calculer le gain lie a ta longueur de vecteur par rapport a une autre unite vectorielle de taille differente, suivant la taille des donnees que tu auras choisi tu pourras observer un speedup superlineaire (a supposer que l'appli scale parfaitement avec la vectorisation).

PS: desole pour les OOT, mais je demarre facilement

[Foudge]

Non, Yasko, ne nb de Thread de nos applis n'est pas proportionnel au nb de CPU. Je précise notre pb:
On lance une appli de 50 Threads sur un single-core, puis on lance cette même appli sur un Dual-core et enfin sur un Quad-Core.
On observe une consmmation de la mémoire à chaque fois plus importante. Le nb de Thread actives dans la JVM est le même pour chaque cas de figure (observation faite avec JConsole et dump des threads).

Aucune raison que ça consomme plus de RAM alors. En théorie, ça ne devrait absolument pas changer.
Ou alors le comportement diffère, non pas au niveau du nombre de thread, mais peut-être au niveau de la quantité de données à traiter et mis en RAM. Ca vient forcément du logiciel, pas du CPU !

[JYS]

Bon, après qq tests, on se dirige plus vers un bug dans le jre 1.5 => Mauvaise gestion du multi-core en environnement temps-réel.
On avait déjà détectés des anomalies en environnement 64bits, mais là c'est le bouquet pour une release censé être stable depuis un an !
... On est en train de vérifier que le jre1.6 se comporte mieux.

[HS]

Je peux pas vous laisser dire des conneries sur les perfs de Java tout X86 que vous êtes.
Vous n'êtes pas les seuls d'ailleurs:
Article:
Multi-core may be bad for Java

http://www.devwebsphere.com/devwebsp...ore_may_b.html

et la réponse (un peu plus technique) juste après:

Multi-core may be good for Java!

http://dev2dev.bea.com/blog/hstahl/a...ore_is_go.html

Sur ce, bonne réflexion

[/HS]

[newbie06]

Hum ca parle temps reel, et Java avec GC... Mon detecteur de contradiction sonne

Sinon pour ces histoires de perf, je me souviens d'un chouette numero du mag dev d'IBM qui presentait des resultats de leur JVM sur du calcul scientifique. Certains bench etaient plus rapides en Java qu'en C++ (generation de code dynamique vs statique toussa toussa). Mais bon, c'est plus anecdotique qu'autre chose.

[fefe]

Je peux pas vous laisser dire des conneries sur les perfs de Java tout X86 que vous êtes.

Oui mais les articles que tu link te disent pas que Java est performant, juste que java beneficie de multiples cpus. Java a toujours ete bon pour le threading entre autre en le rendant plus facilement accssible au programmeur.

Si j etais mauvaise langue je dirais qu'avoir un bon scaling est rendu facile quand on part de bas .

Il y a des choses pour lesquelles la perf absolue de java n'est pas mauvaise, et tout depend de a quoi on veut comparer, compare a la plupart des languages de script c'est performant, compare a du C ou du Fortran nettement moins (sauf si tu ne fais que des calculs ou la difference devient faible).

[JYS]

Oui mais les articles que tu link te disent pas que Java est performant, juste que java beneficie de multiples cpus. Java a toujours ete bon pour le threading entre autre en le rendant plus facilement accssible au programmeur.

Si j etais mauvaise langue je dirais qu'avoir un bon scaling est rendu facile quand on part de bas .

Il y a des choses pour lesquelles la perf absolue de java n'est pas mauvaise, et tout depend de a quoi on veut comparer, compare a la plupart des languages de script c'est performant, compare a du C ou du Fortran nettement moins (sauf si tu ne fais que des calculs ou la difference devient faible).

Je pense qu'il faut arrêter de vivre dans le passé, comparer Java à du language scripté était plausible sur les premières versions de Java. A partir du jre 1.4 (qui date de 2004) les perfs du Java se sont fortement rapproché de ce que l'on pouvait obtenir en C++ du fait de grosses améliorations sur le calcul mais surtout depuis que Java dispose d'une librairie pour mieux gérer les sockets (package nio).
Je te vois venir Fefe, oui mais C++ c'est pas C, et puis de toute façon il n'y a que l'assembleur qui marche...
Ok, mais le développement et la maintenance d'un code Assembleur (voir C) de plusieurs centaines de milliers de lignes coûtera bcp plus de temps en mise au point (x10) que le même code écrit en Java pour un gain au final en perfs qui va friser le 0.
Le seul point où aujourd'hui Java ne rejoint pas le code C, c'est sur les quantité mémoire utilisée (temps de libération de la mémoire plus long dû au Garbage Collector).
Sur les perfs il faut remettre vos pendules à l'heure les gars, Java employé pour le développement d'application serveurs est aussi performant que du code C++.
Aujourd'hui on en est au jre1.6 et je peux vous dire en l'utilisant tous les jours que nos applications sont au coude à coude, voir dépasse des applications concurrentes en terme de perfs dans le cadre des Media Serveurs (module qui permet l'envoit massif de flux RTP pour les applis VoIP).
Pourquoi ? Tout simplement parcequ'avec Java on peut passer plus de temps sur les parties intelligente du code plutôt que de perdre bêtement son temps sur des problèmes d'imprecisions du langage et de gestion mémoire.

PS:désolé pour la mise en page qui pique les yeux, c'est de l'écriture brut de fonderie.

[Tramb]

Sur les perfs il faut remettre vos pendules à l'heure les gars, Java employé pour le développement d'application serveurs est aussi performant que du code C++.

Mouais c'est pas moi que tu vas convaincre (et encore je suis un mou du cul qui fait du C++ et des intrinsics, pas un croisé de l'opcode comme fefe ).
A mon avis ca en dit plus sur la qualité du code C++ de vos compétiteurs et la qualité de votre code Java que sur les performances des JVM.

[fefe]

Je pense qu'il faut arrêter de vivre dans le passé,

Je pense qu'il faut apprendre a lire, et arreter d'etre defensif quand personne ne t'attaque, explications plus bas.

comparer Java à du language scripté était plausible sur les premières versions de Java. A partir du jre 1.4 (qui date de 2004) les perfs du Java se sont fortement rapproché de ce que l'on pouvait obtenir en C++ du fait de grosses améliorations sur le calcul mais surtout depuis que Java dispose d'une librairie pour mieux gérer les sockets (package nio).
Je te vois venir Fefe, oui mais C++ c'est pas C, et puis de toute façon il n'y a que l'assembleur qui marche...
Ok, mais le développement et la maintenance d'un code Assembleur (voir C) de plusieurs centaines de milliers de lignes coûtera bcp plus de temps en mise au point (x10) que le même code écrit en Java pour un gain au final en perfs qui va friser le 0.
Le seul point où aujourd'hui Java ne rejoint pas le code C, c'est sur les quantité mémoire utilisée (temps de libération de la mémoire plus long dû au Garbage Collector).
Sur les perfs il faut remettre vos pendules à l'heure les gars, Java employé pour le développement d'application serveurs est aussi performant que du code C++.

Des liens ? Je veux bien me remettre a jour, mais je veux des infos credibles.

Aujourd'hui on en est au jre1.6 et je peux vous dire en l'utilisant tous les jours que nos applications sont au coude à coude, voir dépasse des applications concurrentes en terme de perfs dans le cadre des Media Serveurs (module qui permet l'envoit massif de flux RTP pour les applis VoIP).
Pourquoi ? Tout simplement parcequ'avec Java on peut passer plus de temps sur les parties intelligente du code plutôt que de perdre bêtement son temps sur des problèmes d'imprecisions du langage et de gestion mémoire.

PS:désolé pour la mise en page qui pique les yeux, c'est de l'écriture brut de fonderie.

Est ce que j'ai dit a un seul instant que cela ne valait pas le coup de programmer en Java ? Non. Est ce que j'ai dit que Java avait les perfs de languages scriptes ? Si tu avais lu tu aurais vu que je disais justement que c'etait plus performant. Je ne pense pas avoir clame non plus la superiorite de l'assembleur sur les autres languages. Je ne souhaite a personne d'avoir a developper une appli en asm.
Est ce que j'aime coder en asm? Certainement, mais mon metier n'est pas d'ecrire du code (et heureusement vu mes habitudes de programmation).

La seule critique que j'ai faite porte sur les perfs et uniquement les perfs, j'ai meme rappele que les perfs de Java etaient comparables aux languages compile dans certains cas (sur du code calculatoire). Sur le reste parler de performance et de Java dans la meme phrase reste une mauvaise blague.

Le seul point sur lequel java n'a pas rejoint le code C... Il y en a plus d'un... On peut citer l'ecriture d'applications ayant vraiment besoin de performances, le meilleur exemple que je puisse donner est dans le domaine des codecs, il y a aussi les jeux ou les drivers. Ca fait un peu plus que juste la gestion memoire.

Bien entendu il y a beaucoup de domaines d'applications ou Java est le meilleur choix, mais pour des raisons completements differentes que la perf (et tu listes entre autre le cout de dev). Le java est mieux parce que tu peux passer plus de temps sur les parties intelligentes du code ? C'est plutot parce que a cout de developpement constant c'est le cas. Le ratio cout de developpement/performance s'ameliore considerablement avec les langages de haut niveaut, c'est certain. Ca ne les rend pas plus performants dans l'absolu.

Finalement, il n'y a quasiment plus personne qui ecrit de l'assembleur autrement que via quelques inlines dans du C, et les seules personnes qui maintiennent encore des programmes enormes en asm, sont les ancetres de ceux qui ecrivent encore en Cobol . Et heureusement.

pas un croisé de l'opcode comme fefe ).

Je ne demande qu'a etre convaincu, mais il me faut une argumentation plus etayee.

[newbie06]

Bon j'ai retrouve l'article d'IBM comparant F90 a Java : http://www.research.ibm.com/journal/sj/391/moreira.pdf
Pas aussi bon que dans mon souvenir, mais loin d'etre ridicule.

Je ne veux pas trop rentrer dans la discussion comparant les differents langages, tout ce que je dirai c'est que chaque langage a un domaine de predilection. L'assembleur sera toujours plus rapide que le C qui sera toujours plus rapide que le C++ qui sera toujours plus rapide que Java. C'est mecanique et lie a l'abstraction qui bien souvent se fait au detriment de la capacite a parler bas niveau. Apres selon le domaine, la portabilite, la maintenance, c'est tout autre chose et bien plus sujet a discussion.

PS - J'ai oublie de dire que le meilleur langage c'est Ocaml

[fefe]

Je ne veux pas trop rentrer dans la discussion comparant les differents langages, tout ce que je dirai c'est que chaque langage a un domaine de predilection. L'assembleur sera toujours plus rapide que le C qui sera toujours plus rapide que le C++ qui sera toujours plus rapide que Java. C'est mecanique et lie a l'abstraction qui bien souvent se fait au detriment de la capacite a parler bas niveau. Apres selon le domaine, la portabilite, la maintenance, c'est tout autre chose et bien plus sujet a discussion.

On est tout a fait d'accord.

Et je n'ai touche qu'au Caml pas objet, et c'etait pas desagreable a enseigner et pas mal du tout pour enseigner l'algorithmique. Certains de mes collegues passaient leurs journees en extase avec Ocaml donc il doit y avoir qq chose.

Bon j'ai retrouve l'article d'IBM comparant F90 a Java : http://www.research.ibm.com/journal/sj/391/moreira.pdf
Pas aussi bon que dans mon souvenir, mais loin d'etre ridicule.

C'est ce dont je me souvenais, sur du code calculatoire ce n'est pas mauvais, mais ca reste en moyenne 20% plus lent que du Fortran.

[Tramb]

Je ne demande qu'a etre convaincu, mais il me faut une argumentation plus etayee.

Meuh non on s'en fout chacun sa méthode, moi par exemple j'apprécie le ratio performance/temps de développement du C++ avec intrinsics.

Tout comme les Javaistes sont contents de la perf obtenue par rapport à l'effort demandé pour développer.
Perso, je refuse le garbage-collecting, et spécialement quand il mélange libération mémoire et finalisation des objets, donc Java c'est out pour moi.
De toute façon à mon sens il *faut* maitriser la durée de vie et l'ownership des objets.

Mais je ne suis pas contre écrire de l'ASM.
C'est juste que dans un cadre industriel, pas grand chose ne le justifie à mon avis. C'est assez rare au final de devoir gratter un cycle dans *une* routine, par contre optimiser des briques utilisées partout pour un gros bénéfice plus diffus, c'est assez courant.

[fefe]

Je ne demande qu'a etre convaincu,

... des perfs de Java . Pas la peine d'essayer de me convaincre que c'est bien pour moi, moins je programme mieux je me sens, et d'autres le font mieux que moi de toutes facons .

[Yasko]

Avant, je développais en Visual Basic.
Maintenant que je développe en Java, mes programmes vont beaucoup plus vite, je ne perds plus mes cheveux, et je peux balancer des "M$ suxx" à tout va (je suis Google powered avec GWT en plus), je suis totally open now.




Euh, je déconne hein (sur le fait que je développais en VB, pas sur le fait que Java soit plus rapide que VB ).

[Alice]

Mega Trolling gratuit: OCaml il parait que c'est vraiment léger comparé à du Haskell. Quant à Java... ah ben non rien à dire... c'est juste un veau.

[JYS]

Hi !

Bon, c'est vrai Fefe que mon ton était peut-être un peu too much, excuse mon côté passionné, je me suis relu et en effet en deuxième lecture mon message me paraît plus agressif que ce que je voulais exprimer.

Concernant le pb adressé par ce topic, vos avis m'ont tout de suite été profitables et je voulais vous en remercier.
L'hypothèse de la consomation mémoire lié au nb de procs/cores ayant tout de suite été écarté j'ai pû me concentrer (avec mon équipe) sur la recherche du pb dans la JVM et en effet bien caché dans la bug parade de Sun nous avons pû trouver confirmation sur ce bug lié au jre1.5 sur des système multi-core ayant plus de 2Go de RAM (et oui, il fallait au moins ça). Pb corrigé dans le jre1.6..ouf!

Maintenant concernant Java et les applications temps réel, je peux vous assurer que c'est une réalité et peut-être que vous entendrez parler de notre produit très bientôt

Je veux bien étayer mes dires mais peut-être vaudrait-il mieux que je crée un topic sur ce sujet dans la bonne section du Forum plutôt que de continuer à faire des appartés de plus en plus long dans celui-ci ?

...et je ne vais pas me défiler Fefe
Juste en préambule un exemple: Le codec G729A que nous utilisons, un des plus gourmand pour la VoIP (20Mips pour chaque flux), à votre avis, en quoi a-t-il été écrit ?

EDIT: Je viens de faire un tour sur les autres forums, j'avais pas remarqué qu'il n'y avait pas de section Software orienté programmation...j'ai mal cherché ? ça vous va si je crée le topic (un brin provocateur) "Java et temps réel" dans Hardware advanced ?