Discussion :

[kerpoint]

Bonjour,

je suis dans un courant de pensée (ou plutôt dans la mode ) "temps réel". Tout le monde parle autour de moi de temps réel, "il faudrait que ce soit en temps réel", "le temps réel réel c'est génial sous Windows XP"... patati et patata. Enfin, j'ai entendu beaucoup d'absurdités autour de moi plus par ignorance que par fermeture d'esprits...

Enfin, je me posais une question très simple et une chose que j'avais entendue par le passé : "le langage C++ n'est pas bien pour le temps réel"!!!

Je suis resté scotché et c'est vrai que pour moi, le langage le plus performant si le code est bien écrit reste l'assembleur...

Donc voilà ma question : l'assembleur est-il le langage le plus performant de manière général et pour le temps réel ? Est-il vrai que le langage C++ ne se prête pas au temps réel ? Si oui, pourquoi ?

Merci par avance,

---
K.

PS : j'entends déjà dire : " tout dépend pour performant". Peut-être passe-t-on plus de temps à coder en assembleur... Mais par exemple pour un code très simple, genre "helloWorld", l'assembleur est-il plus performant ?

[ALT]

L'assembleur n'est pertinent que dans les passages critiques du programme. C'est à dire quand un langage de plus haut niveau n'est pas capable d'effectuer le traitement dans le temps imparti.
Pour le reste, tout est possible.
Quand il y a des contraintes de parallélisme & de sécurité du code, on utilise Ada (aéronautique, astronautique, bancs de tests, pilotage de navettes ferroviaires automatisées...)

Bref, le langage utilisé importe peu, puisque dans les cas les plus sensibles on peut se rabattre sur l'assembleur. Et que les compilateurs modernes sont capables d'optimiser le code en fonction des besoins (rapidité, compacité...)

Donc, je maintiens que le recours à l'assembleur doit rester exceptionnel : pas question de développer l'ensemble de l'application dans ce langage.

[Mat.M]

Tout le monde parle autour de moi de temps réel, "il faudrait que ce soit en temps réel", "le temps réel réel c'est génial sous Windows XP"...

Attention tu parles de XP mais dans les systèmes temps réels le role de l'OS est quasi prépondérant..
pour des systèmes critiques utiliser XP c'est pas génial quand tu vois tout ce que ça bouffe inutilement comme ressources...
quand tu vois qu'il ya des parfaites inutilités comme des assistants qui regardent si tu utilises bien toutes les icones de ton bureau....
Pour faire du véritable temps réel il faut un véritable OS qui supporte parfaitement le multitache avec la plus grande intégrité , qui puisse allouer beaucoup de mémoire ...et XP n'est pas fait pour cela...
Quant à Vista pas la peine d'en parler..

[kerpoint]

C'est pour cela que je disais que j'entendais beaucoup d'absurdités. Le problème n'étant pas le nombre de processus qui tournent et qui bouffent la mémoire, mais de connaître le temps maximal que met un processus prioritaire pour effectuer une action. Or XP ne le permet pas, à cause notamment de son ordonnanceur...

http://www.jautomatise.com/Articles/AN4P19A22.htm

----
K.

[mchk0123]

Comme tu l'a dit si bien :

connaître le temps maximal que met un processus prioritaire pour effectuer une action*

Ce sera ta base pour estimer quel langage et quel os choisir.

Le terme temps réel, étant tellement galvaudé, qu'il faut savoir dans quel contexte on l'emploi. Pour certains le temps réel se mesure par une réponse maximale de l'ordre de la ms. Pour d'autre cela peut être de l'ordre de la s.

Le temps réel dans le contexte de la programmation d'un micro-processeur embarqué pour la régulation des commandes d'un avion de ligne, n'a rien à voir avec le "~temps réel~" dans le contexte le programmation d'un codec audio pour la transmission téléphonique.

* Je rajouterais que cette valeur donne les performances brute du matériel + système. Par dessus il faut estimer le nombre de tâches max que devra réaliser l'application car au dela d'un certain seuil cela peut faire écrouler les performances.

[margilb]

Déjà le concept de programme étant séquentiel ne peut être dans l’absolu, temps réel.
* Dans un PC il y a en plus le multitâche qui ne fait que partager du temps pour exécuté des bouts de programmes successivement et donner l'impression du temps réel.
* L'évolution des systèmes Windows réduisent paradoxalement la résolution des timer logiciel pour une reponse toujours asynchrone. Une réponse arrive quand le système à la main pour la générer...

En voulant rendre possible l'exécution d'application win95 w98 sur Xp j'ai réussi à obtenir des résultats intéressant avec une carte mère ayant un multiprocesseur virtuel (P4 630) avec un vrai double ça doit être encore mieux.
1/ affinité de tous les processus au processeur 1
2/ affinité de l'application "temps réel" au processeur 2
3/ Priorité temps réel pour l'application "temps réel"



Fonction à utiliser :
-Gestionnaire de tache
-SetProcessAffinityMask( hProcess,ProcessAffinityMask1);
-SetPriorityClass( hProcess,NORMAL_PRIORITY_CLASS);
- PrcView.exe

Pour exploiter le timer haute résolution (si disponible sur carte mère).
- QueryPerformanceCounter(&lpFrequency);

Ps : je complèterai par des valeur chiffré sur le gain obtenu.

[- Robby -]

Temps réel ! ...

Le temps réel, c'est s'occuper d'un événement ... en temps réel.
Un événement "extérieur" ... s'en occuper et le traiter à l'instant où il se produit.
La seule façon de faire réellement du temps réel (hi), c'est l'interruption. (par définition)
Le processeur abandonne imméditament toutes tâches et se consacre à la "demande".
Impossible sous XP et c'est bien dommage.
Maintenant, il faut voir si tu as besoin d'un "temps réel" avec une réponse de 2µs ou de 25ms ...
le problème est totalement différent.
Le temps réel où l'on parle de "la seconde" ... on passe au crayon/papier alors !
Si tu as besoin de faire de l'acquisition, prend une vieille bécane sous Dos, tu auras encore bien plus facile.
Un vieux truc comme un PC AT, qui tourne à 12Mhz, sous Dos ...
je te garantis un début d'acquisition en temps réel dans les 5µs !
Essaye de faire "ça" simplement avec un PC moderne sous XP !
ça me fait déjà sourire ...
ou alors travaille directement avec un micro-contrôleur.
Eventuellement un autre OS, conçu et dédié au temps réel (je ne connais pas le domaine)
... mais pas XP.

[Rémi Coquet]

Simplement quelques précisions pour limiter certaines confusions:

Temps réel (définition personnelle): Traitement d'un signal avant sa fin de validité (le signal étant définit comme un changement d'état).

Le temps réel, ou même temps réel critique, est tout à fait possible avec des OS comme Windows CE (c'est même leur but initial et ces OS ne sont que des versions embeded).

Avec Xp, comme avec Vista ou Seven il est tout à fait possible de faire du temps réel. Ce dernier intègre même des API comme AvSetMmThreadPriority (AVRT_PRIORITY_CRITICAL). Il existe en effet des mécanismes tout-à fait usuels et utilisés dans le MSG Pump par exemple ou les Timers low level. Les interruptions restent, bien évidemment, utilisables et gérables sous ses OS. Il est évident que les formes d'accès ont changées car nous sommes sur des systèmes "multitâches" de type sériel. Il est possible de descendre les niveaux de priorités de l'OS si besoin et d'élever ceux de ton application.
Ceci étant posé, il est néanmoins préférable de limiter les (nombres des) changements de contextes: Non seulement avoir une architecture cohérente et peu "chronovore" mais limiter aussi le nombre des services et d'applications (actifs) non directement liés à ton traitement.
Les limites ne sont donc pas indubitablement posées par l'OS cible mais par son utilisation (multitâches sériel / réel). Une chose à savoir quand-même: Le multitâche "est toujours plus lent" sauf dans le cas où tu parallélises des traitements sériels asynchrones.
Le réel "problème" actuel étant l'asynchronisme des tâches parallèles plutôt que les interruptions matérielles ou logicielles parfaitement gérées par les drivers.
Deux dernières choses:
Le temps réel n'est pas forcément lié au matériel (hormis le retour physique d'informations à l'utilisateur ou au hardware demandeur) mais toujours au temps de traitement d'un signal (Event).
- L'assembleur doit-être utilisé dans la globalité de ton cycle de traitement et non comme une poudre magique dans quelques fonctions seulement. C'est l'ensemble qui dois-être "TRc" pas seulement les traitements !

[MarcRemy]

Bonjour,

Juste une petite précision, il existe des versions Embedded de Windows qui permet de maitriser Windows dans un contexte industriel. Cela a commencé avec Windows NT et nous en sommes maintenant Windows 8 Embedded.
Au départ, la problématique était vraiment la ressource disque et CPU, aujourd'hui cette problématique n'existe plus. Les processeurs sont très puissants et la mémoire ne coute plus grand chose. La problématique s'est déplacé au niveau de la maitrise des services, des drivers Windows et des aspects sécurités. Attention, je ne dis pas que l'on peut tout faire avec Windows Embedded. Il y a toujours des applications très embarqués ou qui nécessitent des certifications spécifiques.

De la même façon, il y a des solutions pour transformer Windows en système temps réel. RTX en est une, et est largement utilisé dans l'automation, le médical et plein d’autres domaine. La puissance des processeurs d'aujourd'hui, couplé à la standardisation d'Ethernet (Ethercat, AVB, GigE Vision) font de cette solution une alternative intéressante.
En ce qui concerne l’assembleur, j’utilise toujours sur des parties critiques…mais de plus en plus rares.
Temps réel ou pas, lorsqu’il faut porter une application de plusieurs dizaines de milliers de ligne de code (et je suis gentil), l’assembleur est un cauchemar.
A éviter donc quand c’est possible, la durée de vie d’un système dans l’industrie rend inévitable le portage, et donc l'utilisation de langage C ou C++ lorsque l'on est a bas niveau...

[n5Rzn1D9dC]

Salut

Temps réel ou pas, lorsqu’il faut porter une application de plusieurs dizaines de milliers de ligne de code (et je suis gentil), l’assembleur est un cauchemar.

Tu parles de recoder en asm un code C qui ferait plusieurs milliers de lignes ?
Ce que je sais c'est que pour tous les codes C que j'ai recodé, au final la taille était divisé environ par 5.
Je veux juste dire que la taille d'un code source C ne veut pas dire grand chose, vu que le compilo va faire des gros patés qui pourraient être codé en quelques lignes d'asm "à la main".

Si tu sais clairement ce que le programme est censé faire, via la procédure (ne me souviens plus de l'appelation). Tu devrais pouvoir le coder entièrement en asm sans avoir besoin du code C.
En considérant qu'il est plus avantageux de coder le programme en asm bien entendu.

[Forthman]

Moi aussi je ressort ma pelle pour déterrer ce topic

Le problème de transformer un programme en langage évolué vers de l'assembleur,
c'est que l'approche est totalement différente.

Il n'y a pas très longtemps que j'ai appris à déchiffrer du code C (je comprends mais
je suis incapable de créer un programme),
et un jour j'ai posé une question à un ami programmeur (pas forcément un bon, mais c'est son taf) sur les entiers, et il m'a répondu texto : "t'emmerdes pas avec les entiers on
ne s'en sert que quand on peu pas faire autrement"
En assembleur on ne connaît que ça !

pareil pour les booléens, c'est amusant de vouloir jouer avec, mais pour transformer
ça en assembleur, il vaut mieux ne pas s'embêter à gérer des bits individuellement
sinon ça devient le boxon

Sinon, pour le temps réel dont j'ai besoin sur mes projets, j'utilise le mode reel+FLAT
et sans OS bien sûr (sauf parfois un petit freeDOS)

Dans les applications tournant sur PC avec OS moderne, l'idéal est d'avoir une
interface electronique s'occupant du temps réel (microcontrôleur) et de n'avoir que
l'interface sur le PC

[n5Rzn1D9dC]

Oui c'est clair pour l'approche différente.
D'ailleurs ça c'est une des choses qui m'amuse quand je dois recoder un code C en asm.
Il y a tellement de façon de faire différentes.