[Temps Réel] avec du C++ ?

Ben, a mon avis (mais je ne suis sur de rien) si tu veux un code réellement optimisé, qui turbine à fond, il te faudra notamment :

- faire un peu d'assembleur (dans certaines boucles des algos)
- tirer parti des possibilités de l'OS (hyperthreading, temps réel... selon l'OS)
- tirer parti du materiel (bi-processeur, GPU...)

Du coup, ben c'est plus trop portable.

Par contre, tu peux peut-etre faire une version portable, fonctionnelle et pas forcement très optimisée, pour servir de base à des versions optimisées spécifiques à chaque système.

Pour ce qui est des thread et de la couche graphique, je connait mal boost, mais souvent des #ifdef / #endif selon le systeme suffisent.

Bon courage !

(et je veux bien etre tenu au courant des performances, par curiosité)

Citation:

---

Envoyé par poukill

Juste une dernière question alors:

Quelle méthode utiliser pour du Multithreading (un processus pour l'affichage, l'autre pour les calculs), afin que le code soit portable?
Boost est-il une bonne idée? :?

Merci

---

API portable : pthread

a priori, 3 threads :
a. principal : interaction avec l'utilisateur et affichage
b. acquisition
c. calcul (mais pourrait faire l'objet de + d'1 thread…)

utilisez pthread_attr_setschedpolicy pour déterminer la priorité d'accès aux mutex, mais comme toutes les plate-formes ne supportent pas cette fonctionnalité, mettrez le code d'optimisation des priorités dans une fonction à part qui regroupera les compilations conditionnelles en fonction de l'environnement,
(ce qui vous permettra d'utiliser d'autres techniques de gestion des priorités des threads sur certaines plate-formes…)

communication entre threads (en gros)

principal vers acquisition
start
stop
(pause ?)

acquisition vers principal
status

acquisition vers calcul
data available

calcul vers principal
refresh display

verrous sur les données partagées (buffers d'acquisition, résultats des calculs,…)
verrous conditionnels pour exprimer les états

Le projet étant relativement conséquent (il risque d'avoir un diagramme UML assez chargé), je pense que ça va être difficile d'optimiser en assembleur les boucles.
Je pense plutôt porté mon optimisation sur une très bonne conception du programme! (enfin, je vais essayer ! :D )

Sinon, pour l'aspect portable, je pense que tu as raison. Si je développe sur le PC qui fera les calculs, alors tout est OK.
Mais je pense que ce ne sera pas le cas: le développement se fera sous Windows, et l'exécution sous Unix (meilleur en temps-réel mou je pense).

Le seul problème, c'est le multithreading... Il faudrait qu'il soit compatible dans les deux cas... :triste:

Merci pour ton aide buzzkaido! :P

Citation:

---

Envoyé par JeitEmgie

API portable : pthread

a priori, 3 threads :
a. principal : interaction avec l'utilisateur et affichage
b. acquisition
c. calcul (mais pourrait faire l'objet de + d'1 thread…)

utilisez pthread_attr_setschedpolicy pour déterminer la priorité d'accès aux mutex, mais comme toutes les plate-formes ne supportent pas cette fonctionnalité, mettrez le code d'optimisation des priorités dans une fonction à part qui regroupera les compilations conditionnelles en fonction de l'environnement,
(ce qui vous permettra d'utiliser d'autres techniques de gestion des priorités des threads sur certaines plate-formes…)

communication entre threads (en gros)

principal vers acquisition
start
stop
(pause ?)

acquisition vers principal
status

acquisition vers calcul
data available

calcul vers principal
refresh display

verrous sur les données partagées (buffers d'acquisition, résultats des calculs,…)
verrous conditionnels pour exprimer les états

---

pthread est vraiment compatible 100% Windows/Unix ?

Pour mieux comprendre ce que tu viens de me dire, je viens de dessiner le diagramme des tâches de chaque processus.

Citation:

---

acquisition vers principal
status

---

Je suis pas sur de comprendre parfaitement ce que tu veux dire? Le thread acquisition renvoi un truc du genre "acquisition en cours" au thread principal?

Sinon c'est OK, j'ai un graphe de communication assez clair sur papier!

Merci ! :D

Citation:

---

Envoyé par poukill

pthread est vraiment compatible 100% Windows/Unix ?

Pour mieux comprendre ce que tu viens de me dire, je viens de dessiner le diagramme des tâches de chaque processus.


Je suis pas sur de comprendre parfaitement ce que tu veux dire? Le thread acquisition renvoi un truc du genre "acquisition en cours" au thread principal?

Sinon c'est OK, j'ai un graphe de communication assez clair sur papier!

Merci ! :D

---

c'est une proposition sans connaître les détails de votre matériel, mais en général quand on acquiert des données à partir d'un hardware il est sympa de refléter dans l'interface utilisateur le statut (ou les statuts…) du matériel (quand bien sûr le dit matériel a un protocole de communication qui permet de le faire…) : ON/OFF/RECORDING/PAUSE/ERROR N° …/FRAME COUNTER/…

pthread c'est du POSIX… et c'est disponible sous tous les Unix, avec des subtilités dans certaines parties mais cela ne devrait pas vous toucher dans ce projet…

et il existe des bibliothèques pthread pour Windows…

Citation:

---

Envoyé par JeitEmgie

c'est une proposition sans connaître les détails de votre matériel, mais en général quand on acquiert des données à partir d'un hardware il est sympa de refléter dans l'interface utilisateur le statut (ou les statuts…) du matériel (quand bien sûr le dit matériel a un protocole de communication qui permet de le faire…) : ON/OFF/RECORDING/PAUSE/ERROR N° …/FRAME COUNTER/…

---

Oui, je comprend parfaitement... C'est toujours sympa de voir où on en est!

Citation:

---

Envoyé par JeitEmgie

pthread c'est du POSIX… et c'est disponible sous tous les Unix, avec des subtilités dans certaines parties mais cela ne devrait pas vous toucher dans ce projet…

---

J'ai déjà utilisé du POSIX sous Unix, mais jamais sous Windows. Je me demande si un programme développé sous Windows avec <pthread.h> fonctionnera de la même manière sous Unix?8O

Citation:

---

Envoyé par JeitEmgie

et il existe des bibliothèques pthread pour Windows…

---

Jamais utilisé encore, mais pourquoi pas donc!:D

Merci beaucoup pour ton aide!

Et si tu veux faire du C++ plutôt que du C, tu as effectivement boost (un peu léger en fonctionalités), ACE (un peu une enclume), ...

Citation:

---

Envoyé par Luc Hermitte

Et si tu veux faire du C++ plutôt que du C, tu as effectivement boost (un peu léger en fonctionalités), ACE (un peu une enclume), ...

---

pthread peut aussi s'utiliser en C++, non?

Luc, étant donné que mon projet sera définitivement orienté objet, quelle différence y a t-il alors entre boost et le standard POSIX?
L'un est t-il plus pratique, rapide que l'autre?

Je n'ai encore jamais utilisé boost...:(

Merci!

POSIX est un standard très répandu sur unix. Il y est implémenté avec des menus différences. Son API est en C.

ACE, comme boost, sont des bibliothèques C++ qui enveloppent les détails d'implémentation lié à un OS ou un autre. Elles font ainsi de leur mieux pour fournir une interface C++ portable qui encapsule les POSIX, win32, ...

Le côté C++ apporte des avantages pas si négligeables
- Un meilleur typage qui évite les erreurs idiotes dans les passages de paramètres

- Des façons plus propres qui définir des classes qui sont des tâches

- Il est possible de d'avoir des callbacks sur autre chose que des fonctions libres ayant des void * en paramètre.

- Elles définissent (ACE en particulier) toutes sortes d'"outils" de haut niveau pour faire du multi-tâches (reactor/proactor, barrières, système de messagerie inter-threads, compteurs atomiques, futures, intégration propre avec des sockets&autres timers, ...) et le tout de façon portable.


Le secret est que suivant l'OS cible, en interne, ce sont des appels aux primitives win32 ou POSIX (les détails de variations entre les divers UNIX étant déjà pris en compte) qui sont réalisés.

Citation:

---

Envoyé par Luc Hermitte

POSIX est un standard très répandu sur unix. Il y est implémenté avec des menus différences. Son API est en C.

---

Ok, c'est pas que je suis contre le C, mais dans un souci d'unité, je resterai bien dans du C++... :mrgreen:

Citation:

---

Envoyé par Luc Hermitte

ACE, comme boost, sont des bibliothèques C++ qui enveloppent les détails d'implémentation lié à un OS ou un autre. Elles font ainsi de leur mieux pour fournir une interface C++ portable qui encapsule les POSIX, win32, ...

---

Ok, boost choisi donc, en fonction de l'OS sur lequel le programme trourne, l'implémentation adéquate. C'est très bien pour moi si j'ai à travailler sur deux systèmes différents.

Maintenant, si j'ai la possibilité de travailler sur la même machine, du développement à l'exécution, est-ce qu'il vaut mieux coder directement en POSIX ou Win32? (meilleure performance ?)
Ou bien le gain de clarté est-il significatif en choisissant boost? (meilleure intégration dans mon environnement C++) La performance est-elle vraiment réduite?

Merci Luc pour tes précieux conseils ! :P

Je n'aime pas sortir du cadre des questions d'un forum. Mais vue quelques questions posé j'aimerai proposer la création d'un petit tuto. en français sur l'utilisation des GPUs. Personnellement je n'ai aucune connaissance dans ce domaine, mais cela m'interesse. Si des personnes sont interessés, ou motivé pour m'aider contacter moi.

Citation:

---

Envoyé par themadmax

Je n'aime pas sortir du cadre des questions d'un forum. Mais vue quelques questions posé j'aimerai proposer la création d'un petit tuto. en français sur l'utilisation des GPUs. Personnellement je n'ai aucune connaissance dans ce domaine, mais cela m'interesse. Si des personnes sont interessés, ou motivé pour m'aider contacter moi.

---

Moi, ça m'intéresse.
Je n'ai également aucune connaissance dans le domaine des GPU. On est probablement pas les seuls.
J'apprécierais un tutoriel "pour les nuls".

Le problème, c'est que pour exploiter le GPU il faut passer par une API 3D, donc DirectX ou OpenGL. Donc il n'y a pas à proprement parler de "programmation GPU pour les nuls", mais plutôt "comment débuter avec DirectX / OpenGL" puis "comment utiliser les shaders". C'est pas vraiment trivial.

A la limite ce qu'il serait intéressant de faire (si ça n'existe pas déjà) ce serait une bibliothèque pour abstraire les détails de programmation 3D et fournir une interface focalisée sur l'exploitation du GPU pour des calculs mathématiques.

Une bibliotheque mathematique pour GPU, ça existe... a moitié !

En partie sur :

http://www.gpgpu.org

Et sinon, NVIDIA vient de sortir ce qui ressemble à une API mathematique pour leurs GPUs :

http://www.developer.nvidia.com/object/cuda.html

Je n'ai pas creusé en détails ces docs, mais je crois bien que ce sont les references en matière de "General Purpose GPU"...

Pour peu qu'un standard se mette en place, ça pourrait signifier une forte augmentation des performances de nos PC en calculs scientifiques.

Citation:

---

Envoyé par poukill

Maintenant, si j'ai la possibilité de travailler sur la même machine, du développement à l'exécution, est-ce qu'il vaut mieux coder directement en POSIX ou Win32? (meilleure performance ?)

---

On est en mesure de s'attendre que de procéder directement aux appels natifs soit plus rapide. D'un autre côté boost et ACE sont excessivement template ce qui peut amener vitesse, comme code bloating.

Je t'avoue que je ne me suis jamais amusé à faire des mesures de perfs comparatives. Au taf, j'utilise ACE sur du solaris, il y a énormément de traffic en temps réel, et on tient les contraintes de perf sur la partie routeur.
Et pourtant à plusieurs reprises, j'ai croisé des avis négatifs (en termes de perfs) sur ACE.

Bref, fait des essais et vois si cela te convient.

Citation:

---

Ou bien le gain de clarté est-il significatif en choisissant boost? (meilleure intégration dans mon environnement C++) La performance est-elle vraiment réduite?

---

J'estime que le gain en robustesse, en relative portabilité, et en patterns orientés réseaux/TR en vaut la peine.

Ta réponse est très claire! Merci Luc :king:

Donc va pour la bibliothèque portable, je le sentais mieux comme ça aussi... Deux avis valent mieux qu'un seul... ;)

Bonne continuation,