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  

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

 
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+

   
(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 ?)

j'ai schématisé...

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?

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+

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

à 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

+1 sur moins moins

"avec", steplé

   
fais pas ta farouche

 
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

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

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

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.

 
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.

 
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.

 
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.

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.

 
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)...

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

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

mékiléconlui

c'est pourtant la seule chose qu'on demande à un système temps réel
 
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 ?
 

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.

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
 
 
on a pas attendu le Ghz pour faire du temps réel
 
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 !

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.

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
 
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 )

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

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

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

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

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 ?

à 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 )

y a un monde entre forte supposition et certitude

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 ...

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 Bonjour le truc