-Est-ce que Java est viable pour des applications tr=E8s grandes, j'ai
lu quelque part que l'on ne pouvait pas faire des programmes de plus
de 64ko ? C'est tr=E8s limitant non ?
Peut-on envisager l'utilisation de Java sur des aplications lourdes ?
Des exemples ?
-La rapidit=E9 et Java:
J'ai vu qu'il y avait une utilisation JIT (just in time), qui permet
une am=E9lioration importante des performances. Mais je me demandais
s'il existait un moyen, lors de l'execution d'un programme java, que
la console java le traduise eni=E8rement en code natif de la machine
avant son utlisation, et non pas seulement que de certaines parties du
programmes les plus souvent utilis=E9es (je ne parle pas de faire un
ex=E9cutable)
programme source java-> traduction totale en code natif sur la machine
cible->utlisation du programme
Cela ne permetrait-il pas, apr=E8s un certain temps(d=FB =E0 la compliation
en code natif) d'avoir une application totalement fluide ?
Nous développons une application d'analyse de données de contrôle non destructif. C'est une application desktop standalone. Historiquement, elle était développée en C++ et nous avons commencé à utiliser java pour l'UI basée sur swing (initialement avec des objectifs de portabilité). Je n'ai pas les métriques mais il y a plusieurs centaines de milliers de loc.
Contrairement à nos craintes initiales, les performances sont tres bonnes. Nous utilisons de moins en moins jni et le C++ même pour du calcul scientifique. L'expérience montre que les différences de perf pures ne sont pas significatives. Par contre les couts des appels avec de gros transferts de données entre java et C++ est important. La souplesse du gc et du multithread en java font la différence.
Le seul point négatif concernant java est le pb des perf d'affichage graphique. Il semble que java/swing/awt n'utilise que partiellement les possibilités matérielles d'accélération graphique. Cela évolue dans le bon sens, mais ce n'est pas encore comparable à une application native.
Bonjour,
Au passage, petite curiosité personelle ...
Pourriez-vous nous en dire plus sur les limitations de performance graphique que vous avez rencontré et votre environement ?
Car à ma connaissance, si le pipe Java2D est bien configuré, il est capable de merveilles ...
Nous développons une application d'analyse de données de contrôle non
destructif. C'est une application desktop standalone.
Historiquement, elle était développée en C++ et nous avons commencé à
utiliser java pour l'UI basée sur swing (initialement avec des objectifs de
portabilité). Je n'ai pas les métriques mais il y a plusieurs centaines de
milliers de loc.
Contrairement à nos craintes initiales, les performances sont tres bonnes.
Nous utilisons de moins en moins jni et le C++ même pour du calcul
scientifique. L'expérience montre que les différences de perf pures ne sont
pas significatives. Par contre les couts des appels avec de gros transferts
de données entre java et C++ est important. La souplesse du gc et du
multithread en java font la différence.
Le seul point négatif concernant java est le pb des perf d'affichage
graphique. Il semble que java/swing/awt n'utilise que partiellement les
possibilités matérielles d'accélération graphique. Cela évolue dans le bon
sens, mais ce n'est pas encore comparable à une application native.
Bonjour,
Au passage, petite curiosité personelle ...
Pourriez-vous nous en dire plus sur les limitations de performance
graphique que vous avez rencontré et votre environement ?
Car à ma connaissance, si le pipe Java2D est bien configuré, il est
capable de merveilles ...
Nous développons une application d'analyse de données de contrôle non destructif. C'est une application desktop standalone. Historiquement, elle était développée en C++ et nous avons commencé à utiliser java pour l'UI basée sur swing (initialement avec des objectifs de portabilité). Je n'ai pas les métriques mais il y a plusieurs centaines de milliers de loc.
Contrairement à nos craintes initiales, les performances sont tres bonnes. Nous utilisons de moins en moins jni et le C++ même pour du calcul scientifique. L'expérience montre que les différences de perf pures ne sont pas significatives. Par contre les couts des appels avec de gros transferts de données entre java et C++ est important. La souplesse du gc et du multithread en java font la différence.
Le seul point négatif concernant java est le pb des perf d'affichage graphique. Il semble que java/swing/awt n'utilise que partiellement les possibilités matérielles d'accélération graphique. Cela évolue dans le bon sens, mais ce n'est pas encore comparable à une application native.
Bonjour,
Au passage, petite curiosité personelle ...
Pourriez-vous nous en dire plus sur les limitations de performance graphique que vous avez rencontré et votre environement ?
Car à ma connaissance, si le pipe Java2D est bien configuré, il est capable de merveilles ...
Jusqu'à une date récente, nous utilisions le jdk 1.4. Les performances graphiques sont assez mauvaises comparées à ce que nous obtenions sur stations hp sous hp-ux en C/C++. En particulier le tracé de polylines est catastrophique. Il semble également que la gestion mémoire soit assez mauvaise en cas de tracé de graphiques lignes (GeneralPath) de dimensions très grandes par rapport à la fenêtre. Par exemple un tracé d'un signal inclu dans un carré [(0,0),(100,100)] et zoomez sur une très petite zone. Le tracé est clippé sur une toute petite zone, mais java semble réaliser le tracé complet sur une immense image off-screen et clipper le résultat. Il s'ensuit des erreurs et des temps de tracé délirants.
Comme cela ne se produit que dans des cas extrèmes nous avons simplement limité les possibilités de zoom. Mes essais d'utiliser le pipe openGl en java 5 se sont soldées par des crashes et des fonctionnements bizarres.
Nous venons juste de passer en java 6 et avant de répondre à ce mail, j'ai essayé de rajouter
-Dsun.java2d.opengl=True
au lancement de mon app. La réponse est
"Could not enable OpenGL pipeline for default config on screen 0"
au lancement de l'application.
Je ne peux donc pas dire si ça améliore les choses.
Si vous avez des infos sur le comment on fait pour utiliser ce pipeline, je suis preneur. Au passage ma machine est récente, c'est un dell optiplex 745 avec un ATI radeon x1300.
Merci d'avance.
"TestMan" a écrit dans le message de news: 46801a3b$0$18610$
Tout à fait d'accord.
Nous développons une application d'analyse de données de contrôle non destructif. C'est une application desktop standalone. Historiquement, elle était développée en C++ et nous avons commencé à utiliser java pour l'UI basée sur swing (initialement avec des objectifs de portabilité). Je n'ai pas les métriques mais il y a plusieurs centaines de milliers de loc.
Contrairement à nos craintes initiales, les performances sont tres bonnes. Nous utilisons de moins en moins jni et le C++ même pour du calcul scientifique. L'expérience montre que les différences de perf pures ne sont pas significatives. Par contre les couts des appels avec de gros transferts de données entre java et C++ est important. La souplesse du gc et du multithread en java font la différence.
Le seul point négatif concernant java est le pb des perf d'affichage graphique. Il semble que java/swing/awt n'utilise que partiellement les possibilités matérielles d'accélération graphique. Cela évolue dans le bon sens, mais ce n'est pas encore comparable à une application native.
Bonjour,
Au passage, petite curiosité personelle ...
Pourriez-vous nous en dire plus sur les limitations de performance graphique que vous avez rencontré et votre environement ?
Car à ma connaissance, si le pipe Java2D est bien configuré, il est capable de merveilles ...
Jusqu'à une date récente, nous utilisions le jdk 1.4. Les performances
graphiques sont assez mauvaises comparées à ce que nous obtenions sur
stations hp sous hp-ux en C/C++. En particulier le tracé de polylines est
catastrophique. Il semble également que la gestion mémoire soit assez
mauvaise en cas de tracé de graphiques lignes (GeneralPath) de dimensions
très grandes par rapport à la fenêtre. Par exemple un tracé d'un signal
inclu dans un carré [(0,0),(100,100)] et zoomez sur une très petite zone. Le
tracé est clippé sur une toute petite zone, mais java semble réaliser le
tracé complet sur une immense image off-screen et clipper le résultat. Il
s'ensuit des erreurs et des temps de tracé délirants.
Comme cela ne se produit que dans des cas extrèmes nous avons simplement
limité les possibilités de zoom. Mes essais d'utiliser le pipe openGl en
java 5 se sont soldées par des crashes et des fonctionnements bizarres.
Nous venons juste de passer en java 6 et avant de répondre à ce mail, j'ai
essayé de rajouter
-Dsun.java2d.opengl=True
au lancement de mon app. La réponse est
"Could not enable OpenGL pipeline for default config on screen 0"
au lancement de l'application.
Je ne peux donc pas dire si ça améliore les choses.
Si vous avez des infos sur le comment on fait pour utiliser ce pipeline,
je suis preneur.
Au passage ma machine est récente, c'est un dell optiplex 745 avec un ATI
radeon x1300.
Merci d'avance.
"TestMan" <none@example.com> a écrit dans le message de news:
46801a3b$0$18610$426a74cc@news.free.fr...
Tout à fait d'accord.
Nous développons une application d'analyse de données de contrôle non
destructif. C'est une application desktop standalone.
Historiquement, elle était développée en C++ et nous avons commencé à
utiliser java pour l'UI basée sur swing (initialement avec des objectifs
de portabilité). Je n'ai pas les métriques mais il y a plusieurs
centaines de milliers de loc.
Contrairement à nos craintes initiales, les performances sont tres
bonnes. Nous utilisons de moins en moins jni et le C++ même pour du
calcul scientifique. L'expérience montre que les différences de perf
pures ne sont pas significatives. Par contre les couts des appels avec de
gros transferts de données entre java et C++ est important. La souplesse
du gc et du multithread en java font la différence.
Le seul point négatif concernant java est le pb des perf d'affichage
graphique. Il semble que java/swing/awt n'utilise que partiellement les
possibilités matérielles d'accélération graphique. Cela évolue dans le
bon sens, mais ce n'est pas encore comparable à une application native.
Bonjour,
Au passage, petite curiosité personelle ...
Pourriez-vous nous en dire plus sur les limitations de performance
graphique que vous avez rencontré et votre environement ?
Car à ma connaissance, si le pipe Java2D est bien configuré, il est
capable de merveilles ...
Jusqu'à une date récente, nous utilisions le jdk 1.4. Les performances graphiques sont assez mauvaises comparées à ce que nous obtenions sur stations hp sous hp-ux en C/C++. En particulier le tracé de polylines est catastrophique. Il semble également que la gestion mémoire soit assez mauvaise en cas de tracé de graphiques lignes (GeneralPath) de dimensions très grandes par rapport à la fenêtre. Par exemple un tracé d'un signal inclu dans un carré [(0,0),(100,100)] et zoomez sur une très petite zone. Le tracé est clippé sur une toute petite zone, mais java semble réaliser le tracé complet sur une immense image off-screen et clipper le résultat. Il s'ensuit des erreurs et des temps de tracé délirants.
Comme cela ne se produit que dans des cas extrèmes nous avons simplement limité les possibilités de zoom. Mes essais d'utiliser le pipe openGl en java 5 se sont soldées par des crashes et des fonctionnements bizarres.
Nous venons juste de passer en java 6 et avant de répondre à ce mail, j'ai essayé de rajouter
-Dsun.java2d.opengl=True
au lancement de mon app. La réponse est
"Could not enable OpenGL pipeline for default config on screen 0"
au lancement de l'application.
Je ne peux donc pas dire si ça améliore les choses.
Si vous avez des infos sur le comment on fait pour utiliser ce pipeline, je suis preneur. Au passage ma machine est récente, c'est un dell optiplex 745 avec un ATI radeon x1300.
Merci d'avance.
"TestMan" a écrit dans le message de news: 46801a3b$0$18610$
Tout à fait d'accord.
Nous développons une application d'analyse de données de contrôle non destructif. C'est une application desktop standalone. Historiquement, elle était développée en C++ et nous avons commencé à utiliser java pour l'UI basée sur swing (initialement avec des objectifs de portabilité). Je n'ai pas les métriques mais il y a plusieurs centaines de milliers de loc.
Contrairement à nos craintes initiales, les performances sont tres bonnes. Nous utilisons de moins en moins jni et le C++ même pour du calcul scientifique. L'expérience montre que les différences de perf pures ne sont pas significatives. Par contre les couts des appels avec de gros transferts de données entre java et C++ est important. La souplesse du gc et du multithread en java font la différence.
Le seul point négatif concernant java est le pb des perf d'affichage graphique. Il semble que java/swing/awt n'utilise que partiellement les possibilités matérielles d'accélération graphique. Cela évolue dans le bon sens, mais ce n'est pas encore comparable à une application native.
Bonjour,
Au passage, petite curiosité personelle ...
Pourriez-vous nous en dire plus sur les limitations de performance graphique que vous avez rencontré et votre environement ?
Car à ma connaissance, si le pipe Java2D est bien configuré, il est capable de merveilles ...
Jusqu'à une date récente, nous utilisions le jdk 1.4. Les performances graphiques sont assez mauvaises comparées à ce que nous obtenions sur stations hp sous hp-ux en C/C++. En particulier le tracé de polylines est catastrophique. Il semble également que la gestion mémoire soit assez mauvaise en cas de tracé de graphiques lignes (GeneralPath) de dimensions très grandes par rapport à la fenêtre. Par exemple un tracé d'un signal inclu dans un carré [(0,0),(100,100)] et zoomez sur une très petite zone. Le tracé est clippé sur une toute petite zone, mais java semble réaliser le tracé complet sur une immense image off-screen et clipper le résultat. Il s'ensuit des erreurs et des temps de tracé délirants.
Quel composant utilisez vous pour l'affichage ?
Comme cela ne se produit que dans des cas extrèmes nous avons simplement limité les possibilités de zoom. Mes essais d'utiliser le pipe openGl en java 5 se sont soldées par des crashes et des fonctionnements bizarres.
Nous venons juste de passer en java 6 et avant de répondre à ce mail, j'ai essayé de rajouter
-Dsun.java2d.opengl=True
au lancement de mon app. La réponse est
"Could not enable OpenGL pipeline for default config on screen 0"
au lancement de l'application.
Vous êtes sous quel OS ? Avez-vous testé une appli OpenGL sur cette machine ?
Tout ça afin de vérifier que vous êtes bien dans les minimums requis : http://java.sun.com/javase/6/docs/technotes/guides/2d/new_features.html#ogl
Je ne peux donc pas dire si ça améliore les choses.
Si vous avez des infos sur le comment on fait pour utiliser ce pipeline, je suis preneur. Au passage ma machine est récente, c'est un dell optiplex 745 avec un ATI radeon x1300.
Par contre je ne sais pas si les soucis constatés dans l'implementation OpenGL d'API décris sur http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html ont été résolus ...
A+ TM
Jusqu'à une date récente, nous utilisions le jdk 1.4. Les performances
graphiques sont assez mauvaises comparées à ce que nous obtenions sur
stations hp sous hp-ux en C/C++. En particulier le tracé de polylines est
catastrophique. Il semble également que la gestion mémoire soit assez
mauvaise en cas de tracé de graphiques lignes (GeneralPath) de dimensions
très grandes par rapport à la fenêtre. Par exemple un tracé d'un signal
inclu dans un carré [(0,0),(100,100)] et zoomez sur une très petite zone. Le
tracé est clippé sur une toute petite zone, mais java semble réaliser le
tracé complet sur une immense image off-screen et clipper le résultat. Il
s'ensuit des erreurs et des temps de tracé délirants.
Quel composant utilisez vous pour l'affichage ?
Comme cela ne se produit que dans des cas extrèmes nous avons simplement
limité les possibilités de zoom. Mes essais d'utiliser le pipe openGl en
java 5 se sont soldées par des crashes et des fonctionnements bizarres.
Nous venons juste de passer en java 6 et avant de répondre à ce mail, j'ai
essayé de rajouter
-Dsun.java2d.opengl=True
au lancement de mon app. La réponse est
"Could not enable OpenGL pipeline for default config on screen 0"
au lancement de l'application.
Vous êtes sous quel OS ? Avez-vous testé une appli OpenGL sur cette
machine ?
Tout ça afin de vérifier que vous êtes bien dans les minimums requis :
http://java.sun.com/javase/6/docs/technotes/guides/2d/new_features.html#ogl
Je ne peux donc pas dire si ça améliore les choses.
Si vous avez des infos sur le comment on fait pour utiliser ce pipeline,
je suis preneur.
Au passage ma machine est récente, c'est un dell optiplex 745 avec un ATI
radeon x1300.
Par contre je ne sais pas si les soucis constatés dans l'implementation
OpenGL d'API décris sur
http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html
ont été résolus ...
Jusqu'à une date récente, nous utilisions le jdk 1.4. Les performances graphiques sont assez mauvaises comparées à ce que nous obtenions sur stations hp sous hp-ux en C/C++. En particulier le tracé de polylines est catastrophique. Il semble également que la gestion mémoire soit assez mauvaise en cas de tracé de graphiques lignes (GeneralPath) de dimensions très grandes par rapport à la fenêtre. Par exemple un tracé d'un signal inclu dans un carré [(0,0),(100,100)] et zoomez sur une très petite zone. Le tracé est clippé sur une toute petite zone, mais java semble réaliser le tracé complet sur une immense image off-screen et clipper le résultat. Il s'ensuit des erreurs et des temps de tracé délirants.
Quel composant utilisez vous pour l'affichage ?
Comme cela ne se produit que dans des cas extrèmes nous avons simplement limité les possibilités de zoom. Mes essais d'utiliser le pipe openGl en java 5 se sont soldées par des crashes et des fonctionnements bizarres.
Nous venons juste de passer en java 6 et avant de répondre à ce mail, j'ai essayé de rajouter
-Dsun.java2d.opengl=True
au lancement de mon app. La réponse est
"Could not enable OpenGL pipeline for default config on screen 0"
au lancement de l'application.
Vous êtes sous quel OS ? Avez-vous testé une appli OpenGL sur cette machine ?
Tout ça afin de vérifier que vous êtes bien dans les minimums requis : http://java.sun.com/javase/6/docs/technotes/guides/2d/new_features.html#ogl
Je ne peux donc pas dire si ça améliore les choses.
Si vous avez des infos sur le comment on fait pour utiliser ce pipeline, je suis preneur. Au passage ma machine est récente, c'est un dell optiplex 745 avec un ATI radeon x1300.
Par contre je ne sais pas si les soucis constatés dans l'implementation OpenGL d'API décris sur http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html ont été résolus ...
A+ TM
Xavier Tarrago
"TestMan" a écrit dans le message de news: 468199c5$0$14200$
Quel composant utilisez vous pour l'affichage ?
Un JPanel dont on surcharge paintComponent. Le tracé est essentiellement de l'affichage d'images et des tracés de polylines. (pour représenter des signaux numérisés et des cartographies)
Vous êtes sous quel OS ? Avez-vous testé une appli OpenGL sur cette machine ?
Windows xp pro. Non, mais je viens de descendre les derniers drivers ATI et le pipe openGl est maintenant utilisé. Malheureusement, les performances sont bien plus mauvaises qu'en fonctionnement normal.
Tout ça afin de vérifier que vous êtes bien dans les minimums requis : http://java.sun.com/javase/6/docs/technotes/guides/2d/new_features.html#ogl
C'est difficile à dire. Je ne connais pas openGl et je ne sais pas vérifier que : a.. Hardware accelerated drivers supporting the WGL_ARB_pbuffer, WGL_ARB_render_texture, and WGL_ARB_pixel_format extensions b.. OpenGL version 1.2 or higher c.. At least one pixel format with an available stencil buffer Je me dis que si ca utilise le pipe openGl c'est que ces conditions doivent être réalisées...
Par contre je ne sais pas si les soucis constatés dans l'implementation OpenGL d'API décris sur http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html ont été résolus ...
A+ TM
"TestMan" <none@example.com> a écrit dans le message de news:
468199c5$0$14200$426a74cc@news.free.fr...
Quel composant utilisez vous pour l'affichage ?
Un JPanel dont on surcharge paintComponent.
Le tracé est essentiellement de l'affichage d'images et des tracés de
polylines. (pour représenter des signaux numérisés et des cartographies)
Vous êtes sous quel OS ? Avez-vous testé une appli OpenGL sur cette
machine ?
Windows xp pro. Non, mais je viens de descendre les derniers drivers ATI
et le pipe openGl est maintenant utilisé. Malheureusement, les performances
sont bien plus mauvaises qu'en fonctionnement normal.
Tout ça afin de vérifier que vous êtes bien dans les minimums requis :
http://java.sun.com/javase/6/docs/technotes/guides/2d/new_features.html#ogl
C'est difficile à dire. Je ne connais pas openGl et je ne sais pas
vérifier que :
a.. Hardware accelerated drivers supporting the WGL_ARB_pbuffer,
WGL_ARB_render_texture, and WGL_ARB_pixel_format extensions
b.. OpenGL version 1.2 or higher
c.. At least one pixel format with an available stencil buffer
Je me dis que si ca utilise le pipe openGl c'est que ces conditions
doivent être réalisées...
Par contre je ne sais pas si les soucis constatés dans l'implementation
OpenGL d'API décris sur
http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html
ont été résolus ...
"TestMan" a écrit dans le message de news: 468199c5$0$14200$
Quel composant utilisez vous pour l'affichage ?
Un JPanel dont on surcharge paintComponent. Le tracé est essentiellement de l'affichage d'images et des tracés de polylines. (pour représenter des signaux numérisés et des cartographies)
Vous êtes sous quel OS ? Avez-vous testé une appli OpenGL sur cette machine ?
Windows xp pro. Non, mais je viens de descendre les derniers drivers ATI et le pipe openGl est maintenant utilisé. Malheureusement, les performances sont bien plus mauvaises qu'en fonctionnement normal.
Tout ça afin de vérifier que vous êtes bien dans les minimums requis : http://java.sun.com/javase/6/docs/technotes/guides/2d/new_features.html#ogl
C'est difficile à dire. Je ne connais pas openGl et je ne sais pas vérifier que : a.. Hardware accelerated drivers supporting the WGL_ARB_pbuffer, WGL_ARB_render_texture, and WGL_ARB_pixel_format extensions b.. OpenGL version 1.2 or higher c.. At least one pixel format with an available stencil buffer Je me dis que si ca utilise le pipe openGl c'est que ces conditions doivent être réalisées...
Par contre je ne sais pas si les soucis constatés dans l'implementation OpenGL d'API décris sur http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html ont été résolus ...
