Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1014 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  vitesse application

 


 Mot :   Pseudo :  
 
 Page :   1  2  3
Page Précédente
Auteur Sujet :

vitesse application

n°1036698
Profil sup​primé
Posté le 06-04-2005 à 01:58:24  answer
 

Bonjour,
 
En java ,la vitesse de l'execution d'un programe dépent elle aussi de la puissance de l'ordinateur sur lequel tourne le programe?
Un programe en java tournant sur un pc ayant un processeur 2 fois plus élévé qu'un autre pc, tournera t'il 2 fois plus vite?
 
Merci  :hello:

mood
Publicité
Posté le 06-04-2005 à 01:58:24  profilanswer
 

n°1036767
Worldofdad​a
Posté le 06-04-2005 à 09:08:40  profilanswer
 

je dirais qu'il ne tournera pas 2x plus vite mais un peu moins ... ca dépend quand meme de la RAM, de l'environnement, ...
 
Mais ca doit quand meme aller bien plus rapidement

n°1036821
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 10:07:57  profilanswer
 


 
de quoi veux-tu que ca depende d'autre que du processeur ? c'est lui qui fait le boulot, que ce soit du java ou du C ou autre chose
 
si sur un test de comparaison (type burn-test) un ordinateur A est + rapide qu'un ordinateur B de 50%, alors ca veut simplement dire que le processeur de A a un gain de 50% pour tout type d'applications par rapport à B
 
a+


Message édité par trevor le 06-04-2005 à 10:08:33

---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1036830
Lam's
Profil: bas.
Posté le 06-04-2005 à 10:10:29  profilanswer
 

trevor a écrit :

de quoi veux-tu que ca depende d'autre que du processeur ? c'est lui qui fait le boulot, que ce soit du java ou du C ou autre chose
 
si sur un test de comparaison (type burn-test) un ordinateur A est + rapide qu'un ordinateur B de 50%, alors ca veut simplement dire que le processeur de A a un gain de 50% pour tout type d'applications par rapport à B
 
a+


 [:lam's]  
(et la vitesse de la RAM, la taille du cache L1/L2/L3, l'engorgement du bus PCI, la vitesse de swap du disque dur, ça compte pas ?)

n°1036833
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 10:13:03  profilanswer
 

j'ai schématisé...


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1037332
Profil sup​primé
Posté le 06-04-2005 à 14:25:29  answer
 

Entre la vitesse d'un programe realisé en c et le meme programe realisé en java ,il y a t'il une grande différence de vitesse déxécution?

n°1037376
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 14:40:08  profilanswer
 

les détracteurs de java ont tjs tiré à boulet rouge dessus avec pour principal argument la vitesse d'exécution
je crois qu'avec les bécanes actuels, si ça peut te donner une idée, il est tout à fait envisageable de faire du temps réel avec java (il existe même une JVM temps réel (aonix)), avec un système qui réagit suffisamment vite
 
maintenant, il est quasi sûr que dans 90% des cas, le C++ te donnera un système + rapide que Java, mais selon les spécifs de ton système, cela n'est peut-être pas nécessaire d'être aussi rapide que ce que permet le C++, et Java est peut-être largement suffisant (surtout qu'il faut se cogner le C++ !!!)
 
a+

n°1037610
Profil sup​primé
Posté le 06-04-2005 à 15:52:07  answer
 

Je tourne avec la avec la jdk 1.2.2.Aurais je un gain de perfomance important en passant a la version 1.5?

n°1037618
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 15:55:50  profilanswer
 

à partir de la 1.3 oui
 
mais après, sauf si réel besoin, je trouve que l'api devient trop une usine à gaz
 
une 1.3.1_15 (2000) est à mon sens largement suffisant pour devélopper en règle gnl


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1037676
the real m​oins moins
Posté le 06-04-2005 à 16:13:00  profilanswer
 

trevor a écrit :

à partir de la 1.3 oui
 
mais après, sauf si réel besoin, je trouve que l'api devient trop une usine à gaz
 
une 1.3.1_15 (2000) est à mon sens largement suffisant pour devélopper en règle gnl


n'importe quoi.
1.4 et 1.5 ont apporté leur lot d'amelioration de perfs, et des trucs indispensables dans l'api et le langage lui meme :o


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
mood
Publicité
Posté le 06-04-2005 à 16:13:00  profilanswer
 

n°1037690
benou
Posté le 06-04-2005 à 16:18:22  profilanswer
 

+1 sur moins moins

n°1037697
the real m​oins moins
Posté le 06-04-2005 à 16:21:53  profilanswer
 

"avec", steplé [:nofret]


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
n°1037703
benou
Posté le 06-04-2005 à 16:23:45  profilanswer
 


 :D  
fais pas ta farouche :o

n°1037852
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 17:53:03  profilanswer
 

the real moins moins a écrit :

n'importe quoi.
1.4 et 1.5 ont apporté leur lot d'amelioration de perfs, et des trucs indispensables dans l'api et le langage lui meme :o


 
c'est quoi ce qui est "indispensable" pour toi ? car ce ne l'est tet pas pour moi
perso j'ai encore jamais eu besoin de JAXP (v1.0 ou v1.3) ni des expressions régulières (encore que ca aurait pu tet me simplifier l'existence), ni de jdbc v3.0, bref; l'indispensable c'est très subjectif


Message édité par trevor le 06-04-2005 à 17:55:41

---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1037861
coffeeman
Posté le 06-04-2005 à 17:56:56  profilanswer
 

trevor a écrit :


je crois qu'avec les bécanes actuels, si ça peut te donner une idée, il est tout à fait envisageable de faire du temps réel avec java


 
Tu sais déjà vachement ce qu'es le temps réel :o
 


---------------
Moi, j'aime pas les signatures - J'écoute actuellement :
n°1037863
Arjuna
Aircraft Ident.: F-MBSD
Posté le 06-04-2005 à 17:57:20  profilanswer
 

En tout cas, si l'appli Java s'occupe de faire des trucs sur le réseau, ça changera rien que le processeur soit plus rapide.
 
IE 1.0, sur un 486 est aussi rapide pour charger une image que IE 6.0 sur un quadri-xéon 4 GHz, si derrière t'as un modem 14.4 Kbps :D

n°1037869
benou
Posté le 06-04-2005 à 18:02:14  profilanswer
 

trevor a écrit :

bref; l'indispensable c'est très subjectif


on est d'accord, mais t'as quand même des tas de trucs très utiles (je parle même pas des évlutions de java dans la 1.5)
 
en vrac : apis XML, xpath, imageio, concurrency, etc.

n°1037871
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 18:02:46  profilanswer
 

coffeeman a écrit :

Tu sais déjà vachement ce qu'es le temps réel :o


 
c'est bien de "critiquer", faudrait tet voir à argumenter aussi


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1037882
benou
Posté le 06-04-2005 à 18:07:25  profilanswer
 

trevor a écrit :

c'est bien de "critiquer", faudrait tet voir à argumenter aussi


le temps réel a rien à voir avec la vitesse : c'est la capacité de prédire un temps maximum (le plus faible possible, tant qu'à faire) pour un traitement donné, sur une machine donnée.

n°1037883
coffeeman
Posté le 06-04-2005 à 18:07:40  profilanswer
 

trevor a écrit :

c'est bien de "critiquer", faudrait tet voir à argumenter aussi


 
Les notions de temps réel ne sont absolument pas des problèmes de vitesse de traitement, mais de prédictibilité de vitesse de traitement. Un système temps réel de mesure de la dérive des continent peut avoir un temps de réponse garantie en jours, c'est pas génant.  
 
Accessoirement en java, le gc a une légère tendance à foutre la merde dans ce type de besoin, puisqu'il a quasiment sa "vie" propre et influe sur le temps de réponse (il est sur la même machine) et de manière différentes à chaque esai (il est super-stateful).
 
D'ailleurs, un gros travail de JRTS (la spec sur les API RT de java) est sur la gestion de la mémoire.


---------------
Moi, j'aime pas les signatures - J'écoute actuellement :
n°1037885
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 18:08:12  profilanswer
 

benou a écrit :

on est d'accord, mais t'as quand même des tas de trucs très utiles (je parle même pas des évlutions de java dans la 1.5)
 
en vrac : apis XML, xpath, imageio, concurrency, etc.


 
mais je n'ai pas dit que les versions 1.4 ou 1.5 étaient inutiles ou n'avaient pas d'intérêt particulier. j'ai dit qu'il me semblait qu'avec du 1.3 on avait dejà pas mal de choses, et une api suffisamment conséquente, tout comme une rapidité d'exécution raisonnable
et en effet, je n'ai jamais requis de version > j2se 1.3 jusqu'à présent, maintenant, si vous faites que du dev en java webstart ou bien bcp de trucs avec jdbc, il est certain que vous préféreriez sans doute une v > 1.4
 
mais, bon, l'auteur du thread dev en 1.2, passer en 1.3 ne me parait pas inutile, au-dessus si. ca n'est que mon avis, tlm peut ne pas être d'accord, et au final c'est la personne qui aura posé la question qui choisira.


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1037886
Moktar1er
No one replies...
Posté le 06-04-2005 à 18:08:28  profilanswer
 

benou a écrit :

le temps réel a rien à voir avec la vitesse : c'est la capacité de prédire un temps maximum (le plus faible possible, tant qu'à faire) pour un traitement donné, sur une machine donnée.


Avec de surcroit la gestion des priorité, la préemption etc. La garantie qu'un traitement sera terminé dans le temps qu'il lui est imparti.

n°1037900
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 18:23:34  profilanswer
 

coffeeman a écrit :

Les notions de temps réel ne sont absolument pas des problèmes de vitesse de traitement, mais de prédictibilité de vitesse de traitement. Un système temps réel de mesure de la dérive des continent peut avoir un temps de réponse garantie en jours, c'est pas génant.  
 
Accessoirement en java, le gc a une légère tendance à foutre la merde dans ce type de besoin, puisqu'il a quasiment sa "vie" propre et influe sur le temps de réponse (il est sur la même machine) et de manière différentes à chaque esai (il est super-stateful).
 
D'ailleurs, un gros travail de JRTS (la spec sur les API RT de java) est sur la gestion de la mémoire.


 
avant de parler de prédictibilité, il faut tet d'abord voir un minimum le terme de temps de réponse. un système temps réel doit être adapté au processus que le système gère, la plupart des sytèmes temps réels tu les trouves dans l'industrie, sur les systèmes d'automatisation, chaîne de montage, chaîne de production, système embarqués de pilotage, etc.
même si je ne suis pas assez calé (loin de là) sur tous ces systèmes, je ne vois pas trop où prédictibilité il doit y avoir. l'important est surtout de pouvoir traiter l'information (i) avant que l'information (i+1) arrive et pouvoir réagir en conséquence.
 
selon cette définition là, qui pour moi est la seule (je crois pas que la prédictibilité soit la préoccupation majeure des dinosaures du temps réel tels que os9 et vxworks), java peut largement être adapté à du tr dans un contexte industriel (même s'il ne le garantit pas)...


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1037901
the real m​oins moins
Posté le 06-04-2005 à 18:24:49  profilanswer
 

tu serais pas un grand fan des écrans CRT des fois?


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
n°1037907
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 18:27:01  profilanswer
 

the real moins moins a écrit :

tu serais pas un grand fan des écrans CRT des fois?


 
je n'ai pas saisi l'allusion ? tu peux préciser ?


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1037910
Moktar1er
No one replies...
Posté le 06-04-2005 à 18:29:42  profilanswer
 

the real moins moins a écrit :

tu serais pas un grand fan des écrans CRT des fois?


mékiléconlui [:rofl]

n°1037916
benou
Posté le 06-04-2005 à 18:34:55  profilanswer
 

trevor a écrit :

(même s'il ne le garantit pas)...


c'est pourtant la seule chose qu'on demande à un système temps réel [:spamafote]
 
tu vas faire quoi fasse à un responsable d'usine : y a de fortes chances que la voiture finisse entière ? si le garbage collector se déclenche pas, normalemement, la voiture devrait sortir avec des roues ?
 
[:spamafote]

n°1037946
trevor
laissez la vie vous étonner...
Posté le 06-04-2005 à 18:50:33  profilanswer
 

si vous relisez quand même, ma phrase est "il est tout à fait envisageable de faire du temps réel avec java", je ne dis pas non plus que c'est la meilleure solution, je dis que c'est envisageable, en précisant qu'il existe même des JVM TR.
l'auteur du thread (qui va finir par abandonner son topic suite à cette polémique) s'interrogeait sur la vitesse d'exécution de java, je pense que de dire qu'on peut faire du TR en java n'est pas usurpé, et, je pense, répond bien à sa question, car en gnl, le TR est un domaine dans lequel les contraintes de temps priment.
 
la vitesse de traitements des ordinateurs a fortement évolué et continue toujours. en revanche, les contraintes matérielles restent +ou- identiques (on imagine mal un automate allant 10x + vite qu'il y a 5 ans). alors je pense sincèrement que c'est une solution envisageable, il faut simplement s'attarder sur les contraintes exactes du contexte dans lequel on veut développer.


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
n°1037951
benou
Posté le 06-04-2005 à 18:57:25  profilanswer
 

le truc c'est que tu fais un lien entre les performances des machines et le fait qu'on puisse faire du temps réel. Ca n'a juste rien à voir [:spamafote]
 
 
on a pas attendu le Ghz pour faire du temps réel [:spamafote]
 
je n'ai jamais regardé des JVM TR. C'est peut être en effet un moyen de faire du TR en Java. Mais les JVM classiques, elles n'en sont pas capables !
 
Et encore une fois, rien à voir avec les perfs !!! Si une application peut fonctionner avec une JVM classique, c'est que ce n'est aps une application temps réelle !

n°1037962
Lam's
Profil: bas.
Posté le 06-04-2005 à 19:06:11  profilanswer
 

trevor a écrit :

si vous relisez quand même, ma phrase est "il est tout à fait envisageable de faire du temps réel avec java"


Disons que Java n'est pas adapté pour diriger un calculateur d'ABS ou un missile autoguidé ("à tête chercheuse" ). Ca le rend donc non temps-réel, car non prédictif: absolument rien ne te garantit que tu pourras traiter la prochaine info en moins de 2 heures, puisque le GC peut très bien décider de défragmenter ton disque dur pour optimiser sa RAM si ça le chante...
 
Après, dans des exemples plus proches de nous, le "temps-réel" si cher aux jeux vidéos est depuis longtemps largement atteignable en Java, on est d'accord.

n°1037974
Arjuna
Aircraft Ident.: F-MBSD
Posté le 06-04-2005 à 19:12:11  profilanswer
 

benou a écrit :

le truc c'est que tu fais un lien entre les performances des machines et le fait qu'on puisse faire du temps réel. Ca n'a juste rien à voir [:spamafote]
 
 
on a pas attendu le Ghz pour faire du temps réel [:spamafote]


Ouais m'enfin le Java, c'est le seul environnement capable de transformer un serveur dernière génération en 8086 ashmatique, donc pour Java, on arrive à peine au MHz :whistle:
 
Sinon, juste un truc... Si j'ai bien compris, un système temps réel, c'est un système ou je sais à l'avance le temps d'éxécution d'une instruction, c'est bien ça ?
 
Alors... Même en VBS sous Windows 95 on doit être capable d'en faire non ???
 
Je veux dire... Tu fait toutes tes fonctions avec un timer, et tu empêches la fonction de se terminer avant la fin du timer, disons paramètré à 5 secondes.
Comme ça, faire 2 additions prendra certes autant de temps que faire un tri dans un tableau de quelques milions de lignes, mais tu as la garantie que ça prendra 10 secondes exactement... Non ?
 
(je pose juste une question, j'y connais rien en TR, je ne fais que supposer d'après ce que vous en dites :D)


Message édité par Arjuna le 06-04-2005 à 19:12:59
n°1037980
the real m​oins moins
Posté le 06-04-2005 à 19:15:32  profilanswer
 

Arjuna a écrit :

Je veux dire... Tu fait toutes tes fonctions avec un timer, et tu empêches la fonction de se terminer avant la fin du timer, disons paramètré à 5 secondes.
Comme ça, faire 2 additions prendra certes autant de temps que faire un tri dans un tableau de quelques milions de lignes, mais tu as la garantie que ça prendra 10 secondes exactement... Non ?


euh, j'y connais rien en TR non plus mais jsuis assez sur de mon coup en te disant que non [:troa]


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
n°1037989
FlorentG
Posté le 06-04-2005 à 19:18:45  profilanswer
 

trevor a écrit :

c'est quoi ce qui est "indispensable" pour toi ? car ce ne l'est tet pas pour moi
perso j'ai encore jamais eu besoin de JAXP (v1.0 ou v1.3) ni des expressions régulières (encore que ca aurait pu tet me simplifier l'existence), ni de jdbc v3.0, bref; l'indispensable c'est très subjectif


Pour ce qui est de la prog de jeux en Java, la version 1.5 a apporté la fonction system.nanoTime() qui aide beaucoup ;)

n°1038010
Arjuna
Aircraft Ident.: F-MBSD
Posté le 06-04-2005 à 19:31:41  profilanswer
 

the real moins moins a écrit :

euh, j'y connais rien en TR non plus mais jsuis assez sur de mon coup en te disant que non [:troa]


Ben vi mais pkoi ? Parceque mon truc ça fait exactement ce que fait le TR vu comme expliqué [:magicbuzz]


Message édité par Arjuna le 06-04-2005 à 19:31:50
n°1038017
the real m​oins moins
Posté le 06-04-2005 à 19:35:02  profilanswer
 

elle est où la garantie dans ton "truc"?


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
n°1038047
Arjuna
Aircraft Ident.: F-MBSD
Posté le 06-04-2005 à 19:55:12  profilanswer
 

Ben faire une addition en 5 secondes mise à part si le PC a planté (et ça, ça peut arriver aussi en TR), je vois pas comment c'est possible. Ensuite, le retour d'une fonction, ça correspond à un temps invariable normalement. Au lieu de passer par un timer, on peut même contrôleur l'horloge interne du PC (bon, après, si un abruti change l'heure sur le PC en même temps, évidement...)
 
M'enfin à première vue, pour s'assurer qu'une tâche va mettre un temps "X" à s'éxécuter, et surtout, que dans la durée, il n'y aura pas de décallage, je ne vois pas de brèche.
 
Pour en revenir à l'application de gestion de la techtonique des plaques. Si le calcul doit prendre 1 jour pile poil, j'ai des doutes sur l'importance que le résultat soit donné à la micro-seconde près après 24 heures de calcul. Par contre, ce qui importe, c'est que dans 50 ans, le résultat tombe toujours à 9h pile, et non pas qu'il se doit décallé d'une heure, à force d'accumler une petite inexactitude.
 
Ainsi, faire un contrôle de sortie de la fonction à partir de l'horloge système me semble tout à fait répondre au problème, non ?

n°1038049
benou
Posté le 06-04-2005 à 19:56:17  profilanswer
 

FlorentG a écrit :

Pour ce qui est de la prog de jeux en Java, la version 1.5 a apporté la fonction system.nanoTime() qui aide beaucoup ;)


à ma connaissance, y a très peu de hardware capable d'un telle précision => tant que t'es sur du x86 classique, la fonction est inutile (enfin je crois [:petrus75])

n°1038052
benou
Posté le 06-04-2005 à 19:58:49  profilanswer
 

Arjuna a écrit :

Ben faire une addition en 5 secondes ...


y a un monde entre forte supposition et certitude [:spamafote]


Message édité par benou le 06-04-2005 à 20:06:54
n°1038055
benou
Posté le 06-04-2005 à 20:01:02  profilanswer
 

Arjuna a écrit :

Ainsi, faire un contrôle de sortie de la fonction à partir de l'horloge système me semble tout à fait répondre au problème, non ?


Tu feras pas du temps réel sans un système capable de la faire, même en bidouillant dans tous les sens ...
l'OS aussi a son importance dans l'histoire, ainsi que la partie hardware ...

n°1038056
FlorentG
Posté le 06-04-2005 à 20:01:47  profilanswer
 

benou a écrit :

à ma connaissance, y a très peu de hardware capable d'un telle précision => tant que t'es sur du x86 classique, la fonction est inutile (enfin je crois [:petrus75])


Ben la fonction utilisée sous la 1.4 (system.currentTimeMillis) avait une précision de 12ms sous XP, et de 45 ms sous 98 [:alph-one] Bonjour le truc ;)

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  vitesse application

 

Sujets relatifs
application VB.NETOuvrir une application
Killer son applicationOuvrir un fichier pdf depuis une application Java
[Visual .Net] Références Vide sous SmartDevice ApplicationFonction lancer au démarrage d'une application visual c++ .NET
CreateObject("Excel.Application") ne crée pas l'objet !application multi-form en C#, simple mais bloqué..
Developper une application windows....Ancrer une application java
Plus de sujets relatifs à : vitesse application


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR