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

Version imprimable

19/02/2007, 15h06
poukill

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

Bonjour à Tous!

Je vais me lancer dans un gros projet ( 18 mois ) sur une analyse d'un phénomène physique très complexe...
L'analyse devra être effectué en temps réel... C'est une analyse événementielle d'images (analyse comportementale)...
Je dois donc détecter des événements anormaux.

J'ai quelques questions à vous poser:
1) Le C++ peut - il convenir à ce genre de tâche? J'ai pour ça un gros PC de calcul sous Windows et Unix si nécessaire.
Quand je programmais sur DSP, c'était du C, mais là j'ai d'autres outils de travail, nettement plus puissants... Alors je ne sais pas trop...

2) Pour afficher les images en temps-réel, montrer les résultats de mes analyses, suivre les phénomènes, quelle bibliothèque utiliser? Pendant mon précédent projet de six mois j'ai utilisé CImg, mais là?
Qt, WxWidget???

Je vous remercie beaucoup pour toutes vos réponses et/ou remarques!!! :D
19/02/2007, 15h37
themadmax

Le traitement d'image temp réel en C++ est possible, cela depand de la taille de la video a analysé et aussi de la complexité de ton traitement. Parfois il faut ecrire des algo en ASM pour optimisé (si cela est possible). Le nouveau truc à la mode est aussi d'utilise le GPU.
Pour ce qui est de l'affichage il existe des lib portable (SDL). Mais il faut savoir que l'affichage prend boucoup de temp, et il faut parfois utiliser des outils plus pres de la machine ( DirectX, OpenGL...)
Je crois pour un projet d'une durée longue, il est difficile d'estimer la rapidité du code. Fait rapidement des maquettes de ton prog pour savoir si l'ordre de gradeur est acceptable.
19/02/2007, 16h03
JolyLoic

Le C++ est fait pour des projets où le temps compte. Par contre, quel que soit le langage, tout ce qui est affichage est long, et souvent non déterministe en terme de temps d'exécution. Il est donc préférable de bien séparer traitement et affichage, de façon à effectuer ces derniers dans une tâche à faible priorité.

En plus du langage, il te faudra aussi choisir ton OS. Ni Windows ni les Unix classiques ne sont temps réels. Si louper de temps en temps tes contraintes de temps n'est pas très grave (temps réel mou), et que ces contraintes sont de l'ordre de quelques millisecondes, ils peuvent quand même convenir. Si ce n'est pas le cas, il faudra te tourner vers un véritable OS temps réel. Ce qui risque de limiter le choix de langage, le C++ n'étant pas disponible (ou pas bien supporté, ou buggé) sur certains de ces OS.
19/02/2007, 16h09
poukill

Pour l'instant, je n'ai aucune idée des traitements à effectuer.
C'est sur que dans un premier temps, je vais plutôt m'occuper des algos à développer...

Le but ici est de voir quels sont les outils qui peuvent être à ma disposition.
J'ai déjà utiliser un peu la SDL, mais pas Qt, ni WxWidget.

Pour le temps réel, une lib pas trop gourmande serait la bienvenue!
A moins que le GPU prenne le relais. J'imagine que pour l'affichage graphique, l'utilisation du GPU serait un plus, mais est-ce différent alors comme manière de programmer?

Merci ! :P
19/02/2007, 16h13
poukill

Citation:

Envoyé par JolyLoic

Le C++ est fait pour des projets où le temps compte. Par contre, quel que soit le langage, tout ce qui est affichage est long, et souvent non déterministe en terme de temps d'exécution. Il est donc préférable de bien séparer traitement et affichage, de façon à effectuer ces derniers dans une tâche à faible priorité.

En plus du langage, il te faudra aussi choisir ton OS. Ni Windows ni les Unix classiques ne sont temps réels. Si louper de temps en temps tes contraintes de temps n'est pas très grave (temps réel mou), et que ces contraintes sont de l'ordre de quelques millisecondes, ils peuvent quand même convenir. Si ce n'est pas le cas, il faudra te tourner vers un véritable OS temps réel. Ce qui risque de limiter le choix de langage, le C++ n'étant pas disponible (ou pas bien supporté, ou buggé) sur certains de ces OS.

D'accord Loïc pour la séparation traitement et affichage.

Ensuite, je ne pense pas être dans le temps réel pur, à compter le nombre de cycles de calcul... Je pênse que le temps réel mou fera l'affaire, je ne suis pas à la milliseconde...
19/02/2007, 16h15
Mat.M

Tu parles de SDL je trouve cette API très lente voire plus par rapport au simple GDI parfois sous Windows.
SI tu veux des performances faut accèder à des API natives comme Direct X ou simple GDI sous Windows je ne recommande pas trop les "wrappers"
Et puis l'OS a son importance comme le dit Loic Joly.
Vaut mieux un OS véritablement temps réel comme par exemple QNX
19/02/2007, 16h43
buzzkaido

Moi je dirais comme les autres :

- si tu as une contrainte forte sur le temps réel => OS temps réel, y'a que ça

- si tu as une contrainte "molle" sur le temps réels => au mieux un linux specialement optimisé, au pire un windows spécialement optimisé (un minimum de services qui tournent...)

Dans le deuxieme cas, que tu soit sous windows ou linux :

- un processus haute priorité pour le traitement, avec des algos bien pensés, bien optimisés, avec pour les parties les plus critiques un peu d'assembleur

- un processus faible priorité pour l'affichage, si possible avec le choix entre 2 ou 3 tailles/qualités d'affichage (pour accelerer si besoin). Pour l'affichage, rien de plus simple et de plus rapide que le GDI (à mon avis) si tu souhaites uniquement afficher des images (pas de calcul 3D...)

En tout cas, si ton but est la vitesse et pas l'ergonomie, evites les grosses bibliotheques graphiques qui vont t'ajouter des centaines de lignes de codes dont tu n'as rien à faire pour avoir juste une fenetre avec une image et un bouton "start"

Dans tous les cas, rien ne t'empeche d'utiliser une carte à DSP pour booster le tout, ou alors d'utiliser les fonctions specifiques du GPU pour accelerer le traitement sur les images.

Par exemple (je suis pas à 100% sur, mais en gros) :
Mettons que dans ton traitement temps réel tu ai besoin d'appliquer un filtre 9x9 sur ton image, tu peux utiliser directX pour ça. Du coup, si la carte graphique sait appliquer des filtres 9x9, c'est elle qui va le faire, et c'est autant de ressources economisées sur le CPU....
19/02/2007, 17h48
Mat.M

Citation:

Envoyé par buzzkaido

Moi je dirais comme les autres :

- si tu as une contrainte "molle" sur le temps réels => au mieux un linux specialement optimisé, au pire un windows spécialement optimisé (un minimum de services qui tournent...)

Il faut un XP embedded ; sur un Windows normal c'est pas possible de faire tourner des services au minimum sinon l'OS va difficilement tourner correctement.
A faire le rapprochement avec un Vista excessivement gourmand :roll:

-

Citation:

Envoyé par buzzkaido

Par exemple (je suis pas à 100% sur, mais en gros) :
Mettons que dans ton traitement temps réel tu ai besoin d'appliquer un filtre 9x9 sur ton image, tu peux utiliser directX pour ça. Du coup, si la carte graphique sait appliquer des filtres 9x9, c'est elle qui va le faire, et c'est autant de ressources economisées sur le CPU....

eh non : l'intérêt de Direct X c'est si tu veux afficher une succession d'images très rapidement comme pour un jeu vidéo.
Si tu veux appliquer un filtre ce qui requiert du temps CPU et non carte graphique parce que tu ne sollicites pas la carte alors l'intérêt de Direct X sera quasi nul.
Pour appliquer un filtre sur des images il faut faire des calculs qui font intervenir de la trigo et autres ce que la carte graphique ne sait pas forcément faire...
je crois cependant qu'il ya quelques cartes graphiques qui peuvent calculer des transformations de Fourrier utilisées notamment pour la compression/décompression JPEG...
A chaque fois quand on pense Direct X ( voire Open GL) il faut penser carte graphique et accélération graphique.
19/02/2007, 18h11
buzzkaido

Ben moi je croyais que lorsque l'on utilisait des fonctions directX, ça utilisait au maximum les ressources matérielles (cartes d'acceleration), et que donc il suffisait de mettre une carte graphique qui booste et d'utiliser directX pour avoir des operations graphiques qui boostent...

Et puis des fonctions trigo pour des filtres ? plutot du matriciel, non ?

Les GPU ne savent pas faire de trigo ? comment ils calculent les rotations en 3d, alors ?

Enfin, j'disait ça comme ça, mais je ne m'y connait pas des masses en GPU.

Par contre, si tu cherches un peu sur le WEB, y'a different projets qui permettent d'utiliser les capacités des GPUs pour faire du traitement mathématique... en vu d'accelerer des calculs scientifiques, par exemples !

Et oui, parcque quoi qu'on dise, un bon GPU c'est puissant presque comme un CPU, et ça fait toujours des registres, des additionneurs, des multiplicateurs, des bus... en plus ! Autant les utiliser !

(au passage, y'a meme des essais pour utiliser la puissance de la carte graphique pour des logiciels de son : on envoit des samples audio dans la carte graphique, on lui fait faire des calculs dessus, on recupere le resultat... ça parait n'importe quoi, mais la carte ne triate que des données, elle ne fait pas de difference entre audio et image, et comme des GPU font des FFT, par exemple...)

Bien sur, tout ça ne sert à rien si t'as une carte graphique à 20 euros... mais dans le cadre d'un setup particulier pour u projet particulier, autant bien choisir son matériel !
19/02/2007, 19h24
Charlemagne

Je prends la conversation au rebond...

Est-ce que quelqu'un connait des tutoriels/exemples de programmation GPU? (en particulier la FFT et la multiplication de matrices).
Quelqu'un a-t-il des benchmarks? (histoire de comparer CPU et GPU)
19/02/2007, 20h47
HanLee

Tu connais ce site http://www.gpgpu.org/ ?

Une comparaison, par exemple (trouvée sur le site) : http://gamma.cs.unc.edu/LU-GPU/
19/02/2007, 21h57
Mat.M

Citation:

Envoyé par buzzkaido

Ben moi je croyais que lorsque l'on utilisait des fonctions directX, ça utilisait au maximum les ressources matérielles (cartes d'acceleration), et que donc il suffisait de mettre une carte graphique qui booste et d'utiliser directX pour avoir des operations graphiques qui boostent...

Et puis des fonctions trigo pour des filtres ? plutot du matriciel, non ?

Oui tu as raison pour les calculs 3d mais pas pour les filtres.
Direct X ne sait en rien faire des calculs et utiliser l'accélération graphique pour tout ce qui est matriciel et filtres.
Direct X via Direct 3d ne sait que
*créer des objets 3d sous formes de sommets et plaquer des textures
*calculer les éclairages nécessaires
*afficher une scéne 3d
Pour exploiter les GPU il faut directement programmer en ASM ou bien utiliser des biblios pour.
Je crois que les derniers CPU de chez Intel ( j'ai dit CPU pas GPU ) ont des instructions ASM pour calculer par exemple des FFT.
Pas de mystêre pour optimiser tu seras obligé de passer par de l'ASM éventuellement ou bien prendre VTune d'Intel

Citation:

Envoyé par buzzkaido

Bien sur, tout ça ne sert à rien si t'as une carte graphique à 20 euros... mais dans le cadre d'un setup particulier pour u projet particulier, autant bien choisir son matériel !

Il y a peut-être certaines cartes graphiques professionnel et onéreuses qui permettent de traiter des images en temps réel
19/02/2007, 22h07
Laurent Gomila

Citation:

Direct X ne sait en rien faire des calculs et utiliser l'accélération graphique pour tout ce qui est matriciel et filtres.
Direct X via Direct 3d ne sait que
*créer des objets 3d sous formes de sommets et plaquer des textures
*calculer les éclairages nécessaires
*afficher une scéne 3d
Pour exploiter les GPU il faut directement programmer en ASM ou bien utiliser des biblios pour.

Enfin, ça fait quand même un bail que :
- Les GPUs se programment, via les shaders (on peut donc leur faire faire beaucoup de choses autre qu'afficher des triangles)
- Les shaders ne se programment plus en ASM, mais avec des langages proches du C
20/02/2007, 01h51
nicroman

En fait un GPU ne fait rien de tout ca vraiment:
* créer des objets 3d sous formes de sommets et plaquer des textures
* calculer les éclairages nécessaires
* afficher une scéne 3d

Un GPU est un CPU optimisé pour le calcul matriciel (4x4 dimensions) en flottant.
Jusqu'à DX7 ce calcul se limitait a des opérations fixes.
Depuis DX8 (et je ne parle pas de DX10), ces calculs sont entierement programmables.

Ensuite, que les données sur lequelles portent le calcul soient des coordonnées spatiales, des couleurs de texture, ... c'est juste un type d'utilisation.

Il existe aussi une autre partie du GPU très interessante: le rasterizer... un truc qui sait automatiquement découper une ligne (ou un triangle) en petits bouts avec une division gratuite au passage :)

En même temps, une fonction trigonométrique n'est ni plus ni moins qu'un produit vectoriel (sin) ou un produit scalaire (cos). Mais il faut penser au problême mathématique sous forme géometrique pour bien s'en rendre compte.
Et toutes les cartes graphiques sont des brutes en produits scalaire.

On pouvait déjà faire une simili FFT avec un simple plaquage de texture à l'époque de DX7, sans shader.

Maintenant avec les shaders (surtout unifiés), c'est encore plus simple.

Le seul inconvéniant, c'est récupérer les informations... RAM->GPU se fait très très vite, mais l'inverse est une véritable horreur ! Genre, 80ms juste pour récupérer un buffer !
Autant dire que c'est inacceptable pour du temps réel. A moins que le seul but soit d'afficher les données à la fin, auquel cas, il suffit de ne pas sortir de la carte graphique :)
20/02/2007, 08h58
poukill

Tout d'abord merci à tous pour vos réponses... :king:

Si je dois résumer vos remarques, je dirai dans mon cas:

1) Je suis dans du temps réel mou, avec des contraintes de temps pas encore trop bien définies. Le dévelloppement pourra être sous Windows, par contre je dispose de puissantes machines qui tournent sous Unix pour l'exécution...
-> Le Programme doit donc être portable (i.e les librairies aussi)

2) Cela éliminerai donc les lib graphiques natives de Windows. Qt ou SDL avec un processus de basse priorité serait-il une bonne solution?

3) Vous me conseillez de laisser la partie affichage à la carte graphique, en utilisant au max le GPU...

4) La gestion des processus : avec Boost par exemple???

Merci à tous encore pour votre aide ! :P
20/02/2007, 09h34
Charlemagne

Citation:

Envoyé par HanLee

Tu connais ce site http://www.gpgpu.org/ ?

Une comparaison, par exemple (trouvée sur le site) : http://gamma.cs.unc.edu/LU-GPU/

Merci.
Oui, j'ai trouvé ce site juste après avoir posté mon message. Il semble que ce soit le site de référence pour la programmation GPU. J'ai survolé quelques docs, c'est intéressant, mais en tant que débutant la dedans la quantité d'information fait un peu peur...

Je connais pas bien l'algorithme LU, ni l'implémentation qui en a été faite dans ATLAS. Je connais bien mieux l'implémentation de multiplication de matrice d'ATLAS, ou l'implémentation FFTW. Bref j'ai encore du mal a me faire une idée des perfs des GPU.

Sinon, on m'a vanté l'outil suivant, comme étant le "meilleur actuellement"
http://graphics.stanford.edu/projects/brookgpu

J'accepte tout tutoriel/exemple/conseil pour m'initier aux GPU... Merci
20/02/2007, 09h38
JeitEmgie

Citation:

Envoyé par poukill

Bonjour à Tous!

Je vais me lancer dans un gros projet ( 18 mois ) sur une analyse d'un phénomène physique très complexe...
L'analyse devra être effectué en temps réel... C'est une analyse événementielle d'images (analyse comportementale)...
Je dois donc détecter des événements anormaux.

J'ai quelques questions à vous poser:
1) Le C++ peut - il convenir à ce genre de tâche? J'ai pour ça un gros PC de calcul sous Windows et Unix si nécessaire.
Quand je programmais sur DSP, c'était du C, mais là j'ai d'autres outils de travail, nettement plus puissants... Alors je ne sais pas trop...

2) Pour afficher les images en temps-réel, montrer les résultats de mes analyses, suivre les phénomènes, quelle bibliothèque utiliser? Pendant mon précédent projet de six mois j'ai utilisé CImg, mais là?
Qt, WxWidget???

Je vous remercie beaucoup pour toutes vos réponses et/ou remarques!!! :D

Avez-vous mesurer les quantités de données manipulées ?
Quels sont les "circuits" suivi par ces données et quelles sont les débits possibles tout au long ce ces circuits ?
Quelles ont les transformations (calculs) des données que vous devez effectués ?
Avez-vous fait des benchmarks de ces calculs ?
Vous parlez d'images : ce sont des images acquises (quelle interface hardware ? (débit ?), dimension, résolution, profondeur, faut-il convertir les espaces couleurs au vol ? …) qui doivent être manipulées ou simplement des graphiques déduits de vos calculs ?
Si ce sont des graphiques, il faudra analyser la répartition entre les parties "fixes" (invariant d'un frame à l'autre) et les parties "variables"…
Les résultats intermédiaires doivent-il être sauvés sur disque ? Quantité ?

etc.

l'analyse de la faisabilité d'une application "temps réel" commence par la définition de la notion de "temps réel" pour le contexte donné…
et ensuite il faut déterminer tous les chemins suivis par les données,
examiner le parallélisme logique, voir s'il peut se traduire par un parallélisme physique et examiner sur les différents chemins obtenus quels sont les débits possibles, voir s'il y a des conditions de compétition pour certaines resources à certains moments (CPU, mémoire, bus accès GPU, disque, GPU, interfaces vers l'hardware d'acquisition, …), bref déterminer le chemin critique…
(entre devoir faire des grosses FFT en temps réel et acquérir de l'HDTV les "bottlenecks" ne seront pas au même endroit : dans le premier cas, la conclusion pourrait être qu'il faut un multi-processeur dont chaque cpu a sa propre cache d'accès à la RAM, dans l'autre qu'il faut une carte graphique qui permette les meilleurs transferts DMA possibles, un RAID SCSI haut de gamme et un OS qui permette de copier la mémoire d'acquisition video directement dans celle du GPU sans copie intermédiaire…)

… vous avez posé une question relativement vague…
et à mon avis les réponses obtenues, même si elles peuvent être correctes dans un contexte donné, le sont tout autant car il manque essentiellement une vue d'ensemble de ce que vous devrez faire et ne fusse qu'un pré-analyse des "coûts" de chaque étape…
20/02/2007, 10h38
poukill

Citation:

Envoyé par JeitEmgie

Avez-vous mesurer les quantités de données manipulées ?
Quels sont les "circuits" suivi par ces données et quelles sont les débits possibles tout au long ce ces circuits ?
Quelles ont les transformations (calculs) des données que vous devez effectués ?
Avez-vous fait des benchmarks de ces calculs ?
Vous parlez d'images : ce sont des images acquises (quelle interface hardware ? (débit ?), dimension, résolution, profondeur, faut-il convertir les espaces couleurs au vol ? …) qui doivent être manipulées ou simplement des graphiques déduits de vos calculs ?
Si ce sont des graphiques, il faudra analyser la répartition entre les parties "fixes" (invariant d'un frame à l'autre) et les parties "variables"…
Les résultats intermédiaires doivent-il être sauvés sur disque ? Quantité ?

etc.

l'analyse de la faisabilité d'une application "temps réel" commence par la définition de la notion de "temps réel" pour le contexte donné…
et ensuite il faut déterminer tous les chemins suivis par les données,
examiner le parallélisme logique, voir s'il peut se traduire par un parallélisme physique et examiner sur les différents chemins obtenus quels sont les débits possibles, voir s'il y a des conditions de compétition pour certaines resources à certains moments (CPU, mémoire, bus accès GPU, disque, GPU, interfaces vers l'hardware d'acquisition, …), bref déterminer le chemin critique…
(entre devoir faire des grosses FFT en temps réel et acquérir de l'HDTV les "bottlenecks" ne seront pas au même endroit : dans le premier cas, la conclusion pourrait être qu'il faut un multi-processeur dont chaque cpu a sa propre cache d'accès à la RAM, dans l'autre qu'il faut une carte graphique qui permette les meilleurs transferts DMA possibles, un RAID SCSI haut de gamme et un OS qui permette de copier la mémoire d'acquisition video directement dans celle du GPU sans copie intermédiaire…)

… vous avez posé une question relativement vague…
et à mon avis les réponses obtenues, même si elles peuvent être correctes dans un contexte donné, le sont tout autant car il manque essentiellement une vue d'ensemble de ce que vous devrez faire et ne fusse qu'un pré-analyse des "coûts" de chaque étape…

Je sais bien que ma question est vague...
Cependant, les réponses qui me sont apportées ici me sont très utiles pour éliminer des pistes.
Le projet ici est beaucoup plus conséquent que tout ce que j'avais vu à présent. Je pars de pas grand chose (bcp à défricher !!), et mes connaissances en développement sérieux et propre restent largement à parfaire, notamment sur du temps-réel (mou ici) multi-tâches ;)

Beaucoup d'habitués ici connaissent bien que moi les outils disponibles, ainsi que les différentes façons d'attaquer mon problème.

Je peux quand même donner plus de précision :

image : 320 * 240
Période d'échantillonnage : 20 ms
Durée du film : 30 secondes environ

La détection d'événements anormaux (algos pour l'instant complètement indéfinis, c'est le but du projet) devra permettre de stopper l'expérience (asservissement sur un circuit physique)

Voilà, j'espère être plus précis!;)
20/02/2007, 15h18
Mat.M

Citation:

Envoyé par Laurent Gomila

- Les shaders ne se programment plus en ASM, mais avec des langages proches du C

Oui je sais c'es le C graphique mais je voulais parler d'optimisations des calculs en ASM pas parler de programmer directement la carte 8-)
21/02/2007, 08h27
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
21/02/2007, 08h42
buzzkaido

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é)
21/02/2007, 09h07
JeitEmgie

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
21/02/2007, 09h09
poukill

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
21/02/2007, 09h39
poukill

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
21/02/2007, 09h55
JeitEmgie

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…
21/02/2007, 10h00
poukill

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!
21/02/2007, 10h25
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), ...
21/02/2007, 10h33
poukill

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!
22/02/2007, 00h44
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.

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.
22/02/2007, 08h57
poukill

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
22/02/2007, 10h27
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.
22/02/2007, 12h43
Charlemagne

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".
22/02/2007, 13h58
Laurent Gomila

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.
22/02/2007, 15h02
buzzkaido

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.
23/02/2007, 23h58
Luc Hermitte

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.
26/02/2007, 08h22
poukill

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,

Fuseau horaire GMT +2. Il est actuellement 03h58.