Je suis d'accord avec le coup des 2 ringBuf de Robert
MAIS une idée vient à germer
ne devrait-on pas spécialiser un peut notre ringBuf.
Je veux dire par là que, 'hors' mis lorsqu'on change la structure
du provider on a toujours un ringBuf qui empile la MEME CHOSE
dans le MEME ordre, c'est ce qui nous permet de grace aux groupes
TSP de ne pas passer l'id d'une variable à chaque fois.
Donc, pourquoi est-ce que le RingData de Robert ne serait pas
créer une fois pour toute (un pour chaque provider) et donc
dimensionner à une taille fixe et on vote ensuite que le
consumer doit consommer le RingVector à disons 1 Mo/s ce qui
dimensionne le RingVecteur au 'n' premières données décritent
dans le RingData?
Bon je sens que je commence à être pas clair.
Je me plonge dans le code ce soir ou demain
soir et j'en reparle plus concrètement.
D'ailleurs quelqu'un de plus au jus que moi au niveau du
code pourrait-il me dire où (consumer/provider/glu) et
combien (1 par consumer...) de RingBuf sont utilisés
ACTUELLEMENT.
Eric
-------- Message d'origine--------
De: address@hidden de la
part de PAGNOT Robert (EADS ASTRIUM)
Date: lun. 05/01/2004 13:43
À: 'Stephane Galles'; tsp-devel
Cc:
Objet: RE: [Tsp-devel] Question sur le type 'String'
Suite ...
Par la même occasion, réflechissons bien à la manière de ranger les
vecteurs/tableaux.
Au départ je pensais deplier les vecteurs dans le RingBuf et accompagner
chaque element d'un compteur pour indiquer qu'ils font partie d'un même
vecteur.
L'idée est intéressante pour simplifier le dimensionnement du RingBuf de
vecteurs (que j'appelerai RingVector), mais l'overhead mémoire serait très
important. Je crois que l'on peut s'affranchir de ce compteur et même du
pointeur dans le RingBuf initial (que j'appelle RingData) par la méthode
suivante :
* élément de type VECTOR serait codé en RingData par un couple
ID-Type/Longueur uniquement
* RingVector serait un ringbuf d'octets bête et méchant.
* Le push d'une variable VECTOR se fait par un push dans
RingVector du
nombre d'octets qui va bien, suivi d'un push de id-type/longueur dans
RingData (section critique Mthread à prévoir ?)
* Le pop d'une variable VECTOR se fait par un pop de RingData (sans
commit !), puis un pop du nombre d'octets qui va bien dans RingVector
(avec
commit), puis un commit dans RingData.
Cette méthode est généralisable à des vecteurs de n'importe quoi : il
suffit
de définir un ringbuf (RingVector) dont l'élément de base n'est pas un
octet, mais le "n'importe quoi", et de créer un type particulier dans
RingData.
Il est à prévoir un overhead important en temps CPU car on doit
empiler/dépiler octet par octet (pas d'opération de cache possible
...). Les
méthodes "BURST" de ringbuf peuvent améliorer les choses, sinon on peut
"clusteriser" les données et dire, par exemple, que chaque élément de
RingVector mémorise, disons, 16 octets, et que l'on empilera/dépilera
autant de blocs de 16 octets qui faut pour compléter le vecteur. Ainsi, un
vecteur de 14 octets utilise un seul bloc (+ deux octets inutilisés),
et un
vecteur de 33 octets utilise 3 blocs (+ 15 octets inutilisés). C'est
clair ?
Maintenant, histoire de mélanger les discussions : une String
peut elle/doit elle etre considérée comme un vecteur de char, hum ?
Un puriste te dirait que non, surtout s'il a subi une (dé?)formation
Object
(argh !). Maintenant en ce qui concerne un protocole de communication, mon
humble avis est que C'EST STRICTEMENT PAREIL, on fait tous du ASCii, non ?
Steph.
Bob
PAGNOT Robert (EADS ASTRIUM) wrote:
> Eh oui, Robert is back !
>
> Premièrement toutes mes félicitations pour vos élocubrations pleines
> de bon sens, même en période franchement plutôt propice aux
> gastro-entérites et autres crises de foie. Je vois que le sujet
passione !
>
> Puisque je dois dire quelque chose d'utile, je vous proposerai de
> gérer les string (et d'une manière générale tout élement de longueur
> variable) par deux zones mémoires.
>
> 1) LE ringbuf basique qui ne contient qu'un pointeur, à la place de la
> valeur (tableau de bytes) : peu de changements par rapport à l'état
> actuel car ce ringbuf serait à largeur constante et connue !
>
> 2) Un ou plusieurs ringbufs stockant de façon circulaire les élements
> à taille variable. La largeur serait égale au max (fourni par le
> provider), et profondeur calculée selon la fréquence de sampling.
>
> On pourrait discuter sur le nombre de ringbufs à instancier (autant de
> ringbufs que d'élements, un seul ringbuf pour tous les éléments de
> longueur variable, ...), mais aussi sur la profondeur qui risque
> d'être difficile à modéliser !
>
> Sans vouloir se torturer l'esprit, pensez que dans le cas des textes,
> il s'agira essentiellement de messages asynchrones, dont la fréquence
> de changement sera très lente par rapport aux données synchrones !
> Limiter donc les paramètres à longueur variable en asynchrone (en gros
> - je transmet quand sa valeur change) ne serait pas très limitatif.
>
> De plus, dissocier en termes de mémoire les paramètres à longueur
> variable (string, tableaux - de quoi déjà ?, ...) des paramètres à
> longueur fixe (doubles, int, ...) sera probablement plus efficace que
> de tout mélanger. Ce sont des paramètres de nature différente.
>
> A+
>
> Robert
>
> -----Message d'origine-----
> De : Stephane Galles [mailto:address@hidden
> Envoyé : dimanche 4 janvier 2004 20:30
> À : Ibou de Joie; tsp-devel
> Objet : Re: [Tsp-devel] Question sur le type 'String'
>
>
> OK, donc dans ma TODO list je passe en priorité :
>
> "Comment implémenter un ringbuf qui gère des types variables ".
>
> C'est vrai que je restais conservateur pour la taille des strings
> parceque je n'avais pas envisagé de toucher de nouveau au RingBuf
> (A cause du vieux precepte : "ca marche bien, et depuis longtemps;
> donc t'evite de toucher avec tes gros doigts").
>
> Mais pas de problèmes, on va voir comment modifier le RingBuf.
>
> Par contre, je vais créer une batterie de tests unitaires qui vont
> aller avec le nouveau RingBuf, et il faudra les passer sur
> toutes les plateformes pour attraper tous les problèmes
> d'alignement.
>
> Je sens que cela va nécessiter un FrameWork de test un peu sérieux.
> Je connais quelqu'un qui a utilisé un FrameWork de tests unitaires
> il y a peu de temps. Je vais le contacter car il en était trés content.
> Je crois que c'est CUnit (http://cunit.sourceforge.net/) mais il
> faut que je vérifie.
>
> Steph.
>
> Ibou de Joie wrote:
>
> >Et un ringbuf qui gere des types de taille variable (Une zone memoire
> >commune globale, et on decale le ptr courant de la taille du dernier
> >element) : Certes on ne sait pas exactement le nombre de truc que l'on
> >peut y mettre, mais on connait leur occupation mémoire totale ? Ce doit
> >etre un peu tricky pour les pb d'alignement, et donc sans doute moins
> >efficace, mais à voir.
> >
> >Et je suis (comme d'hab) d'accord avec Eric, le provider doit pouvoir
> >donner la taille max de chaque element à la connexion.
> >
> >Y++
> >
> >
> >On Sat, 2004-01-03 at 13:13, Eric NOULARD wrote:
> >
> >
> >>Selon Stephane Galles <address@hidden>:
> >>Euh très honnêtement je pense que 8 caractères c'est un peu
> >>petit quiqui pour un Caribou de ta trempe.
> >>
> >>Je ne vois pas précisément le pb du ring buffer
> >>car je n'ai pas le code sous la main là ou je suis
> >>mais je pensais (bêtement) qu'une string avait une taille
> >>a priori illimité mais que le provider annonçait au consumer
> >>une taille MAX pour la session de sampling en cours de négoce.
> >>Ensuite une fois la request_sample_init, on peut plus toucher
> >>à la taille max, ce qui fait que le provider doit tailler
> >>son ring-buf en fonction de ça.
> >>
> >>
> >>
> >>
> >>>Bon, je me suis lancé sur le codage des autres types, int, string,
> etc...
> >>>J'ai commencé par le coté consumer. Je pense par contre que dans
> >>>un premier temps, et quitte à me contredir, je ne vais pas utiliser
> >>>les structures XDR pour la couche de transport. On vera cela
> >>>dans un 2eme temps.
> >>>
> >>>Une question concernant le type 'String' : Il y a bien une taille
> max ?
> >>>parceque si ce n'est pas le cas, je vais etre trés ennuyé pour les
> stocker
> >>>dans un ringbuffer coté consummer.
> >>>
> >>>Donc je propose 8 charatères max pour les string. Simplement parceque
> >>>les plus gros types (double et long long) font au max 8 octets et
> que donc
> >>>on ne perd pas de place dans les ringbuf à cause des strings.
> >>>
> >>>j'espere que le besoin 'String' ne consiste pas à essayer de faire
> transiter
> >>>des nombres en format string, sinon 8 charactères cela va etre un
> peu juste.
> >>>
> >>>J'avais compris ce besoin plutot pour faire passer des infos
> textuelles
> >>>comme "ON", "OFF", etc ... Am I right ?
> >>>
> >>>
> >>Je pense que tu as raison, mais on peut vouloir faire transiter
> >>un peu plus que 8 caractères.
> >>
> >>En gros, en ce qui concerne la taille max d'un string peut être
> dynamique
> >>MAIS une fois que les sample sont en route celle-ci ne change plus.
> >>
> >>De façon plus général, le consumer "découvre" les types des symboles
> >>(et donc leur taille) avec une request_info et/ou la premiere
> >>request_sample ensuite ces tailles ne peuvent pas changer dès que les
> >>sample ont commencés à transiter du provider au consumer.
> >>
> >>On pourrait imaginer que suite à un arrêt/redémarrage de la MEME
> >>requete de sample la taille/le type d'un symbole est changé.
> >>(si on oublie 30s le problème que ça pose côté provider).
> >>
> >>Qu'en penses-tu?
> >>
> >>
> >>>Stephane.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>Tsp-devel mailing list
> >>>address@hidden
> >>>http://mail.nongnu.org/mailman/listinfo/tsp-devel
> >>>
> >>>
> >>>
> >>--
> >>---
> >>Erk
> >>
> >>
> >>_______________________________________________
> >>Tsp-devel mailing list
> >>address@hidden
> >>http://mail.nongnu.org/mailman/listinfo/tsp-devel
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel
>
> This mail has originated outside your organization,
> either from an external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Tsp-devel mailing list
>address@hidden
>http://mail.nongnu.org/mailman/listinfo/tsp-devel
>
>
This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.