Bonjour j'aimerai connaitre ce qu-ai une mémoire tampon , à quoi elle sert , si il y a qu'une seule mémoire tampon pour chaque programme exécuter ou si il y à qu'une seul mémoire tampon pour plusieurs programmes , quand es-que quelle ce vide etc etc... ?

j'ai regarder différentes explication, mais à part dire quelle garde des données temporairement il n'y a rien d'autres...

par exemple sur MSDN pour Flush(), (en VB.net) il est dit: "Efface les mémoires tampon pour ce flux et provoque l'écriture dans le fichier des données mises en mémoires tampon"

Le "Efface les mémoires pour ce flux" ça veut dire qu'il peut y avoir plusieurs mémoires tampon pour un seul programme, c'est à dire qu'à chaque fois qu'un programme remplit une mémoire tampon il en créer une de plus ?

bref je pense que vous avez compris

merci d'avance

-
Edité par Anonyme 26 janvier 2018 à 2:31:12

Salut,

Une mémoire-tampon (plus souvent appelée Buffer) est une zone en mémoire vive (ou du disque dur) utilisée pour stocker temporairement des données.

L'utilité du Buffer est directement liée à la mémoire et aux périphéries (mais c'est un peu différent en .NET*). On peut voir ça comme une "salle d'attente", qui va permettre à des données relatives à un programme d'épargner l'attente que générera la communication microprocesseur/périphéries de l'ordinateur, dont le débit est variable, mais souvent long (de l'ordre de quelques microsecondes, ce n'est pas grand-chose pour nous, mais pour un ordinateur si).

Dans les langages de programmation, l'utilisation du buffer permet de gérer le flux IO (Input/output → entré /sortie). En vb.net, cela se fait de manière assistée et automatique, mais dans d'autres langages, comme en C par exemple, on peut accéder directement aux adresses dans lesquels sont "enregistrés" les données.

Flush(), de la bibliothèque standard (stdlib), permet (si je reprends mon exemple) de vider la/une salle d'attente, afin de faire de la place pour d'autres patients.

* Les langages .NET (ici je vais parler du VB) sont compilé et exécuté à la volée (généralement) par une machine virtuelle, un peu à la java, mais adapté à Windows. Le programme est compilé (traduit) en CLR (Common Langage Runtime), et l'adressage mémoire se fait virtuellement dans la VM, jusqu’à la compilation en langage machine. Donc le principe est le même, mais ça passe par une surcouche et ça se fait de manière beaucoup plus automatique qu'en C par exemple.

Salut , donc si je comprend bien le Buffer contient que les données d'un seul programmes à la fois, par exemple il contient les données d'un programme(1) il se vide contient des données d'un autre programme(2) , il se vide et peut contenir à nouveau les données du programme juste avant (1) ?

et sert d'intermédiaire entre tous les périphériques ? c'est à dire que toutes données doit passer par cette mémoire et ensuite distribuer au différents périphériques ? par exemple: HDD->Buffer->microprocesseur->Buffer->écran (périphériques) ?

mais en C par exemple le Flush() il faut l'utiliser tout le temps ou le système d'exploitation gère le tampon ? enfin jveux dire quand es-que que le buffer se vide quand le périphérique à besoin de ses données ou il faut faire à chaque fois Flush() ?

-
Edité par Anonyme 26 janvier 2018 à 19:57:24

Gusus a écrit:

Le Buffer contient ne que les données d'un seul programmes à la fois, par exemple il contient les données d'un programme (1) il se vide contient des données d'un programme (2), il se vide et peut contenir à nouveau les données du programme juste avant (1) ?

L'adressage mémoire se fait de manière automatique, il faut voir un buffer comme une zone entière de mémoire constituée de plusieurs emplacements dans lesquels sont enregistré des données (en byte), peu importe le programme, mais une fois en cours d'utilisation, lui seul a accès à ces données. Tant qu'il n'est pas fermé, et même si un de ses buffers n'est plus utilisé, celui-ci restera inaccessible pour touts autres programmes.

Tu peux voir ça de cette manière :

Gusus a écrit:

Il sert d'intermédiaire entre tous les périphériques ? c'est à dire que toutes données doit passer par cette mémoire et ensuite distribuer au différents périphériques ? par exemple: HDD->Buffer->microprocesseur->Buffer->écran (périphériques) ? 

Non, pas spécialement, il est possible de passer outre, mais honnêtement je ne sais pas comment faire. Je ne pense pas que ce soit faisable en .NET en tout cas. En C, il y a surement moyen de contourner. Sinon, tout n'a pas nécessairement besoin de passer par des buffers non plus.

Je modifierais ton exemple : 

Instruction → 
Adressage mémoire et mise en cache de certaines données (buffer) →
passage des données par/dans le CPU → 
transfère des informations vers un/des drivers → 
résultat.

C'est évidemment un exemple grossier.

Gusus a écrit:

Mais en C par exemple le Flush() il faut l'utiliser tout le temps ou le système d'exploitation gère le tampon ? enfin jveux dire quand es-que que le buffer se vide quand le périphérique à besoin de ses données ou il faut faire à chaque fois Flush() ?

Flush() est nécessaire dans certains cas, mais pas tout le temps. De plus il existe des milliers, si par des millions (voir des milliards) d'emplacement possible pour un buffer, donc par de quoi s'inquiéter.

Exemple d'utilisation en C :

printf("Hello, world!");
fflush(stdout);

fflush(stdout) force l'affichage (et vide le buffer). Avant d'être affiché, les caractères sont mis en mémoire (mémoire-tampon). fflush(stdout) vide cette mémoire et force l'affichage des caractères qui s'y trouvaient.

il faut faire à chaque fois Flush() ?

Si on traduit "Flush", cela revient à dire en programmation "Forcer la sortie en chassant les données du buffer". Dans l'exemple précédent, la sortie est l'affichage en console.

_____

Tu as mieux compris ?

L'adressage mémoire se fait de manière automatique, il faut voir un buffer comme une zone entière de mémoire constituée de plusieurs emplacements dans lesquels sont enregistré des données (en byte), peu importe le programme, mais une fois en cours d'utilisation, lui seul a accès à ces données. Tant qu'il n'est pas fermé, et même si un de ses buffers n'est plus utilisé, celui-ci restera inaccessible pour touts autres programmes.

Att tu essaye de me dire que chaque programme créer son propre Buffer dans la ram par exemple ?

En quelque sorte, chaque programme se voit attribuer une partition de mémoire RAM par l'OS.

vanaur a écrit:

En quelque sorte, chaque programme se voit attribuer une partition de mémoire RAM par l'OS.

Donc l'OS donne à chaque programme qui s'exécute, un seul buffer placer quelques part dans la RAM ?

Gusus a écrit:

Donc l'OS donne à chaque programme qui s'exécute, un seul buffer placer quelques part dans la RAM ?

Bon. Je reprends.

Le rôle du système d'exploitation

Le rôle majeur d'un système d'exploitation, est de gérer les ressources matérielles en permettant leur allocation et leurs partages (à l'aide de drivers, souvent). Il joue un rôle de "chef suprême" dans l'ordinateur, c'est lui qui attribue aux différents programmes une place en mémoire vive, pour pouvoir s’exécuter. Si un programme ne respecte pas tout l'espace qui lui a été donné, l'OS, sans pitié, le ferme.

Les buffers dans les programmes

Les buffers ont justement comme rôle de définir des espaces (à taille dynamique) dans la mémoire dans lesquelles seront stockés temporairement certaines données relatives au programme qui utilise cette zone de RAM. Ils permettent aux programmes de réduire la différence entre la vitesse d'entrée et la vitesse de sortie.

Le fonctionnement d'un buffer

Je vais prendre un exemple concret : Lorsque tu regardes une vidéo sur YouTube, une partie de la vidéo est stockée dans un buffer afin d'avoir toujours une petite marge de visionnage fluide, regarde sur la capture d'écran :

• La barre rouge, est ce qui a déjà été visionné, et elle continue à avancer au fur et à mesure que l'on regarde la vidéo,
• La barre grise, est ce qui a déjà été téléchargé par l'ordinateur afin de ne pas avoir à attendre un téléchargement complet, donc tout ce qui est grisé a été mis dans un buffer temporairement,
• La barre transparente, est ce qui n'a pas encore été téléchargé.

C'est le meilleur exemple que je puisse te donner. Il faut bien avoir en tête cette idée-ci en tête : "un buffer stocke temporairement des données afin de réduire le temps d'attente entre le sorite et l'entrée".

Nombre de buffer

Il n'y a pas un buffer par programmes, mais par périphéries (je ne vais pas m'attarder là-dessus, parce que je m'y connais moins bien de ce côté-là), mais en gros, si je reprends l'exemple du code C donné au poste précédent , il y a un buffer dédié à la sortie (stdout), un buffer dédier à l'entrée (stdin), et d'autres encore (stdbuf, stderr.....). Il est même possible d'en alloué dans la partition de mémoire du programme. Donc, il n'y a pas qu'un seul buffer, mais autant que nécessaire.

Emplacement des buffers dans la mémoire

Les buffers sont juste des zones en mémoire vive définie comme tel par le programme, ou plus généralement par l'OS.

Contenu d'un buffer

Un buffer ne contient (généralement) pas les données directement, comme on pourrait le croire sur le schéma que je t'ai donné ci-dessus. Mais plutôt des adresses mémoires relatives aux données qui vont être utilisées par les périphéries ou le programme, voici à quoi cela ressemble :

0xffffd75c:     0x42424242      0xffffd900      0xffffd9e0      0xffffd834
0xffffd76c:     0xf7e303fd      0xf7fa83c4      0xffffd790      0x00000000
0xffffd77c:     0xf7e18a63      0x08048550      0x00000000      0x00000000
0xffffd78c:     0xf7e18a63      0x00000003      0xffffd824      0xffffd834
0xffffd79c:     0xf7feb79a      0x00000003      0xffffd824      0xffffd7c4
0xffffd7ac:     0x0804982c      0x0804822c      0xf7fa8000      0x00000000
0xffffd7bc:     0x00000000      0x00000000      0x1bb78110      0x270ce500
0xffffd7cc:     0x00000000      0x00000000      0x00000000      0x00000003
0xffffd7dc:     0x08048390      0x00000000      0xf7ff0fe0      0xf7e18979
0xffffd7ec:     0xf7ffd000      0x00000003      0x08048390      0x00000000
0xffffd7fc:     0x080483b1      0x080484f5      0x00000003      0xffffd824

Et je pourrai continuer.

Ce que je viens de te montrer, pourraient être simplement un ensemble d'adresses qui formerait une petite chaine de caractère en sortie, ou alors une petite piste audio. Enfin, j'exagère un peu, mais le principe est là.

______

Tu as mieux compris maintenant xD ? N'hésite pas

-
Edité par vanaur 27 janvier 2018 à 13:31:05

Salut , Bon j’espère que ce sera la bonne :) 

Donc

• Les buffers ont justement comme rôle de définir des espaces (à taille dynamique) dans la mémoire dans lesquelles seront stockés temporairement certaines données relatives au programme qui utilise cette zone de RAM. Ils permettent aux programmes de réduire la différence entre la vitesse d'entrée et la vitesse de sortie

Donc plusieurs programmes peuvent utiliser le même Buffer ? ,les Buffers contient plusieurs Adresses de différentes données destiner à différents programmes ou périphériques  ?

• Les buffers ont justement comme rôle de définir des espaces (à taille dynamique) dans la mémoire

Les Buffers ils ont bien quand même une taille maximum ? , il me semble qui ce soit 512 KO mais qu'on pourrai l'augmenter grâce au registre de Windows ?

• Nombre de buffer
• Il n'y a pas un buffer par programmes, mais par périphéries (je ne vais pas m'attarder là-dessus, parce que je m'y connais moins bien de ce côté-là), mais en gros, si je reprends l'exemple du code C donné au poste précédent , il y a un buffer dédié à la sortie (stdout), un buffer dédier à l'entrée (stdin), et d'autres encore (stdbuf, stderr.....).

Il y a donc par exemple dans la RAM un Buffer pour la Sortie un autre pour L'entrée , et encore d'autres ? 

• Il est même possible d'en alloué dans la partition de mémoire du programme. Donc, il n'y a pas qu'un seul buffer, mais autant que nécessaire.

quelle mémoire l'HDD par ex ?

• Emplacement des buffers dans la mémoire

  Les buffers sont juste des zones en mémoire vive définie comme tel par le programme, ou plus généralement par l'OS.

Donc les Buffers sont créer par l'OS ? et es-que ces buffers sont placer dans la RAM un peu partout c'est à dire qu'ils ne doivent pas êtres spécialement à la "queue-leu-leu" ou dans un endroit précis de la RAM  ? 

Contenu d'un buffer

• Un buffer ne contient (généralement) pas les données directement, comme on pourrait le croire sur le schéma que je t'ai donné ci-dessus. Mais plutôt des adresses mémoires relatives aux données qui vont être utilisées par les périphéries ou le programme, voici à quoi cela ressemble :

 Donc un Buffer contient généralement des emplacements mémoires (des emplacements que de la mémoire ou est contenu le buffer ou aussi d'autres emplacements mémoires ? ex:HDD) mais qui peuvent aussi contenir des instructions ou autres ?

-
Edité par Anonyme 27 janvier 2018 à 21:27:01

Gusus a écrit:

Donc plusieurs programmes peuvent utiliser le même Buffer ? ,les Buffers contient plusieurs Adresses de différentes données destiner à différents programmes ou périphériques  ?

Oui et non. Des buffers comme stdout par exemple, il y en a autant qu'il y a de programme qui en on besoin, s'il n'y avait qu'un seul buffer pour la centaine de programmes qui tournent en même temps, croit moi qu'il y aurait des problèmes Mais, dans certains cas, plusieurs programmes peuvent utiliser le même buffer. Je n'ai pas de cas concret, (à part peut-être l'OS lui-même) désoler.

Gusus a écrit:

Les buffers ont justement comme rôle de définir des espaces (à taille dynamique) dans la mémoire

Les Buffers ils ont bien quand même une taille maximum ? , il me semble qui ce soit 512 KO mais qu'on pourrai l'augmenter grâce au registre de Windows ?

Oui, évidemment. D'ailleurs, lorsque les données stockées dans le buffer dépassent sa capacité de stockage, on a ce qu'on appelle un "buffer overflow, ou un stack overflow" (dépassement de mémoire). Avant, et encore maintenant, mais c'est plus compliqué, les hackers exploitaient cette faille du buffer overflow pour accéder au processus du programme, puisqu'ils écrivaient du code en dehors de l'espace mémoire alloué, l'OS exécutait le code qui se trouvait en dehors du buffer.

Sinon, la taille du buffer est définie (par l'OS, le compilateur ou le programme) en fonction de l'utilisation qu'on veut lui faire faire. Ca peut aller de quelques octets à plusieurs MO, mais la taille est limitée (je pense que le maximum, c'est 4 bytes).

Gusus a écrit:

quelle mémoire l'HDD par ex ?

Le buffer se trouve toujours dans la mémoire vive, la RAM, puisqu'il joue un rôle de "temporisateur".

Gusus a écrit:

Emplacement des buffers dans la mémoire

Les buffers sont juste des zones en mémoire vive définie comme tel par le programme, ou plus généralement par l'OS.

Donc les Buffers sont créer par l'OS ? et es-que ces buffers sont placer dans la RAM un peu partout c'est à dire qu'ils ne doivent pas êtres spécialement à la "queue-leu-leu" ou dans un endroit précis de la RAM  ? 

Ils sont là où l'OS le décide. Il n'y a pas d'ordre précis, je pense qu'ils sont dans un ordre logique par rapport à l'emplacement du programme, mais je ne suis pas certain.

Gusus a écrit:

Donc un Buffer contient généralement des emplacements mémoires (des emplacements que de la mémoire ou est contenu le buffer ou aussi d'autres emplacements mémoires ? ex:HDD) mais qui peuvent aussi contenir des instructions ou autres ?

Les buffers peuvent être utilisés pour à peu près tout, mais je ne vois pas l'intérêt d'un buffer de contenir des instructions. Des fonctions, oui, certaines opérations quelconques aussi, mais le plus généralement, ce sont des adresses relatives à des données (peu importe l'emplacement), ou même directement les données elles-mêmes.

Salut

vanaur a écrit:

Oui, évidemment. D'ailleurs, lorsque les données stockées dans le buffer dépassent sa capacité de stockage, on a ce qu'on appelle un "buffer overflow, ou un stack overflow" (dépassement de mémoire). Avant, et encore maintenant, mais c'est plus compliqué, les hackers exploitaient cette faille du buffer overflow pour accéder au processus du programme, puisqu'ils écrivaient du code en dehors de l'espace mémoire alloué, l'OS exécutait le code qui se trouvait en dehors du buffer.

Sinon, la taille du buffer est définie (par l'OS, le compilateur ou le programme) en fonction de l'utilisation qu'on veut lui faire faire. Ca peut aller de quelques octets à plusieurs MO, mais la taille est limitée (je pense que le maximum, c'est 4 bytes).

Donc la taille max d'un Buffer c'est 4 octets ? parce-que j'avais vu sur internet plusieurs articles comme quoi qu'on pouvais l'augmenter mais il était préciser que c'étais une mémoire tampon pour l'OS je crois, correct ?

vanaur a écrit:

Le buffer se trouve toujours dans la mémoire vive, la RAM, puisqu'il joue un rôle de "temporisateur".

Donc les Buffers toujours dans la RAM ok

vanaur a écrit:

Ils sont là où l'OS le décide. Il n'y a pas d'ordre précis, je pense qu'ils sont dans un ordre logique par rapport à l'emplacement du programme, mais je ne suis pas certain.

Ok , du style l'emplacement du programme comment par exemple à l'emplacement 5000 et se termine à 6000 et le premier Buffer commence à 6001 finit à une certaine adresse et ainsi de suite ?

vanaur a écrit:

Les buffers peuvent être utilisés pour à peu près tout, mais je ne vois pas l'intérêt d'un buffer de contenir des instructions. Des fonctions, oui, certaines opérations quelconques aussi, mais le plus généralement, ce sont des adresses relatives à des données (peu importe l'emplacement), ou même directement les données elles-mêmes.

oui c'est ce que je voulais dire par "instructions" c'est à dire des fonctions ou meme des variables ? mais plus generalement des adresses mémoires qui peut etre des adresses de d'autres supports de stockage comme une clé usb par exemple ?

"Oui et non. Des buffers comme stdout par exemple,il y en a autant qu'il y a de programme qui en on besoin, s'il n'y avait qu'un seul buffer pour la centaine de programmes qui tournent en même temps, croit moi qu'il y aurait des problèmesMais, dans certains cas, plusieurs programmes peuvent utiliser le même buffer. Je n'ai pas de cas concret, (à part peut-être l'OS lui-même) désoler."

Donc les Buffers sont créer autant qu'un programme en a besoin et une fois qu'un programme les/l' utilise(s) plus un autre programme peut l'utiliser ? 

-
Edité par Anonyme 29 janvier 2018 à 0:34:38

Gusus a écrit:

Donc la taille max d'un Buffer c'est 4 octets ? parce-que j'avais vu sur internet plusieurs articles comme quoi qu'on pouvais l'augmenter mais il était préciser que c'étais une mémoire tampon pour l'OS je crois, correct ?

La taille est limitée, il n'est pas possible de dépasser une certaine quantité de stockage, mais il est toujours possible de cumuler plusieurs buffers pour stocker les continuités.

Gusus a écrit:

Ok, du style l'emplacement du programme comment par exemple à l'emplacement 5000 et se termine à 6000 et le premier Buffer commence à 6001 finit à une certaine adresse et ainsi de suite ?

En fait, ils peuvent être un peu n'importe où. En électronique, les buffers se situent toujours entre le microprocesseur et les bus de communications (sorte de mini-câble qui transporte des données). Je ne sais pas si c'est la même chose en informatique, ou si c'est "virtualisé". Quoi qu'il en soit, c'est l'OS qui décide. Je disais que les emplacements étaient disposés de manière logique, mais je faisais référence au système d'exploitation qui allait être logique dans ses "décisions".

Gusus a écrit:

Oui c'est ce que je voulais dire par "instructions" c'est à dire des fonctions ou meme des variables ? mais plus generalement des adresses mémoires qui peut etre des adresses de d'autres supports de stockage comme une clé usb par exemple ?

Oui, les valeurs relatives à un programme (comprenant les "variables") sont pour la plupart stockées en buffer ou en cache. Sinon, je ne comprends pas bien la dernière phrase (mauve).

Gusus a écrit:

Donc les Buffers sont créer autant qu'un programme en a besoin et une fois qu'un programme les/l' utilise(s) plus un autre programme peut l'utiliser ? 

Je ne sais pas, il n'y a pas mal de possibilité et de variations possible, selon l'OS, le programme, les autres programmes, ... Mais généralement, le buffer "reste fidèle" à son programme. Je ne vais pas en dire plus, car je ne suis pas sûr de cette dernière affirmation, mais en toutes logiques, c'est comme ça que ça fonctionne. Lorsque le programme cesse d'exister cependant, les buffers se libèrent, et/ou du moins, sont accessibles par d'autres programmes. Les anciennes valeurs sont alors soit effacées, soit utilisé pour générer du pseudo-aléatoire.

Salut , désolé pour le retard 

j'ai fais quelques recherches et j'ai trouver quelques petits trucs dis moi ce que tu en pense

Donc pour répondre à ta question 'Je ne sais pas si c'est la même chose en informatique, ou si c'est "virtualisé" '  .

Il existe effectivement deux types tampons ,

ceux implémenter directement dans le matériels comme par exemple des barrettes de RAM avec tampon qui sont la plupart du temps utiliser par les serveurs , le tampon du claviers ou même sur le DD, mais il y a une limite du Buffer car c'est une mémoire fixe dans le matériel (comme la RAM ou le DD qui a une limite), il contient des données comme les caractères d'un clavier ou même des emplacements de mémoires bref n'importe quelle données , et utilise le FIFO (premier entré premier sortie), enfaîte c'est comme une mémoire normale sauf quelle est utiliser pour stocker des données temporairement et utilise FIFO correct ?

Vient le second type de tampon , Virtuel qui lui est implémentés dans le logiciel

Une majorité de logiciels utilise ces tampons(Virtuel) , qui utilisent généralement la RAM plus rapide pour stocker les données temporaires.Donc normalement un tampon virtuel est fidèle au programme qu'il "la créer"

c'est à dire que ces Buffers au-lieu de contenir directement les "données" , il stocke généralement des emplacement de mémoire(qui sont aussi des données). enfaîte un Buffer Virtuel c'est simplement un tableaux de CHAR qui pointe vers des emplacements de mémoires ? , après je sais pas si il pointe que vers des adresses de la RAM ou si il peut pointé sur d'autres adresses mémoires, et aussi je sais pas quelle taille maximum fait le tableaux de CHAR 4 octets comme tu la dis plus haut ? et je sais pas non plus si il utilise FIFO mais je pense que oui ?

-
Edité par Anonyme 6 février 2018 à 0:38:40

Gusus a écrit:

Enfaîte c'est comme une mémoire normale sauf quelle est utiliser pour stocker des données temporairement et utilise FIFO correct ?

(J'imagine que tu le sais déjà, mais) La RAM (Random Access Memory) n'a pas pour objectif de garder constamment des données en mémoire. Elle permet de rendre plus performant, et surtout plus rapide le software en stockant les données et le code machine des programmes en cours d'utilisation.

La mémoire virtuelle est une sorte d’extension de la RAM sur le disque dur. Je ne serais pas t'expliquer en entier, mais grossièrement, le système d'exploitation va créer ou utiliser ce qui s'appelle une "page d'échange" ou encore une "partition scratch". Il peut ainsi allouer de la mémoire vive ou de la mémoire dure virtuelle via cette page d'échange entre les deux mémoires.

FIFO (First Input First Output) permet de gagner en rapidité. En effet, si le système RAM fonctionnait à la manière d'une pile (d'appel), le temps de communication entre les périphéries serait beaucoup plus long. C'est pour cette raison que le matériel de la RAM fonctionne sur du FIFO. La contrainte est que ça prend plus de place dans le PC si mes souvenirs sont bons.

____

Gusus a écrit:

Enfaîte un Buffer Virtuel c'est simplement un tableaux de CHAR qui pointe vers des emplacements de mémoires ?

Non (d'ailleurs, pourquoi un tableau de char ?). Je ne connais pas trop bien ce que sont les buffers virtuels, mais de ce que j'ai pu comprendre, ce sont des "bout de mémoire vive" qui sont traitées de la même façon qu'un buffer réel par un programme (volontairement ou non) ou par l'OS, selon les besoins. L’avantage de ces buffers virtuels, est qu'ils sont dynamiques, au temps dans leur capacité de stockage (qui est quand même limitée) qu'en nombre, même si encore une fois c'est limité. Je pense qu'une application ne doit pas dépasser 256 buffers virtuels, mais je n'affirme rien. Voici un exemple en Visual Basic, je pense que ça te parlera mieux qu'en C :

Dim MyBuffer() As Byte '// Donc, c'est un tableau stocké dans un buffer virtuel
ReDim MyBuffer(321)    '// Puisque le buffer virtuel a une taille dynamique, il est possible de redéfinir celle du tableau 
                       '   (en C, on aurait utiliser malloc (ou realloc selon les cas))
...

Hello, pour moi quand on parle de buffer on parle de virtuel, je n'étais même pas au courant qu'il y en avait 2 "types".

Gusus a écrit:

Vient le second type de tampon , Virtuel qui lui est implémentés dans le logiciel

Une majorité de logiciels utilise ces tampons(Virtuel) , qui utilisent généralement la RAM plus rapide pour stocker les données temporaires.Donc normalement un tampon virtuel est fidèle au programme qu'il "la créer"

c'est à dire que ces Buffers au-lieu de contenir directement les "données" , il stocke généralement des emplacement de mémoire(qui sont aussi des données). enfaîte un Buffer Virtuel c'est simplement un tableaux de CHAR qui pointe vers des emplacements de mémoires ? , après je sais pas si il pointe que vers des adresses de la RAM ou si il peut pointé sur d'autres adresses mémoires, et aussi je sais pas quelle taille maximum fait le tableaux de CHAR 4 octets comme tu la dis plus haut ? et je sais pas non plus si il utilise FIFO mais je pense que oui ?

-
Edité par Gusus 6 février 2018 à 0:38:40

Les buffers peuvent contenir des données ou des adresses, ca dépend de ton utilisation, c'est donc plus large qu'un tableau de Char.

La taille mémoire d'un tableau dépend de ce que le programme décide de lui allouer, ca peut être très grand comme très petit.

Par exemple tu veux afficher chaque caractère individuellement d'un fichier texte. La façon la plus simple est de lire un caractère, l'afficher et passer au suivant, sauf que dans ce cas tu as autant d'opérations de lectures que de caractères.

Pour améliorer ce programme tu peux créer un tableau de caractères qui stockera 10 (ou 100, ou 1000 etc...) caractères. Ainsi au lieu d’accéder au disque dur, lire le fichier afficher le caractère, réaccéder au disque, relire le fichier etc... tu lis le fichier, tu stockes un certain nombre de caractères dans ton tableau, tu affiches le premier de ton tableau, puis le suivant etc... et une fois arrivé à la fin tu "recharge" ton tableau. Ici ton tableau servira de buffer.

buffer n'est qu'au final le nom donné à un élément (virtuel ou non) qui agit de façon à rendre accessible des données de manière temporaire pour les rendre plus dynamique et rapide lors de leurs utilisations par un quelconque programme.

N'importe quel type de variable (même les tableaux) peut (mais c'est très souvent) être mis en buffer pour des besoins d'accessibilité. Que ce soit un int, un char un std::multimap<std::tuple<std::string, std::vector<char>>, int, long>... Le principe est à chaque fois le même. Et cela s'applique de la même façon pour les tableaux.

Sinon, un "tableau" à proprement parler ne peut pas vraiment servir de buffer, mais... de simple tableau. Les données qu'il contient seront, elles, peut-être stockées dans un buffer (réel ou virtuel), mais le tableau ne sera que "l’intermédiaire", en tant que variable à type structuré. Tu aurais pu créer autant de variable char qu'il y a de caractère dans le fichier, et ça fonctionnerait aussi (même si ça n'a aucun intérêt). Donc, je ne suis pas trop d'accord avec ton dernier paragraphe. Le système de buffer/OS est assez complexe, et utilise directement les instructions, très basique et bas-niveau, du microprocesseur.

-
Edité par vanaur 8 février 2018 à 17:35:23

Salut ,

"(J'imagine que tu le sais déjà, mais) La RAM (Random Access Memory) n'a pas pour objectif de garder constamment des données en mémoire. Elle permet de rendre plus performant, et surtout plus rapide le software en stockant les données et le code machine des programmes en cours d'utilisation."

Oui ce que je voulais dire par "Enfaîte c'est comme une mémoire normale sauf quelle est utiliser pour stocker des données temporairement et utilise FIFO correct ?"

je parlai du Buffer physique , comme par exemple un Buffer d'une RAM , ces Buffer sont simplement une zone de la mémoire vive (si on parle d'un Buffer d'une RAM) réserver à cette utilisation. mais ce type de RAM avec tampon son réserver le plus souvent au server mais il y a d'autre Buffer , dans le DD , clavier etc... et c'est pour ça que j'ai dis "Enfaîte c'est comme une mémoire normale sauf quelle est utiliser pour stocker des données temporairement et utilise FIFO correct ?"" 

je ne parlai pas directement de la RAM mais d'un Buffer physique implémenter dans un matériel

"La mémoire virtuelle est une sorte d’extension de la RAM sur le disque dur. Je ne serais pas t'expliquer en entier, mais grossièrement, le système d'exploitation va créer ou utiliser ce qui s'appelle une "page d'échange" ou encore une "partition scratch". Il peut ainsi allouer de la mémoire vive ou de la mémoire dure virtuelle via cette page d'échange entre les deux mémoires."

"La mémoire virtuelle est une sorte d’extension de la RAM sur le disque dur. " 

Humm pas obliger la mémoire virtuelle utilise le disque dur comme extension que quand la RAM n'a plus de place normalement ?

"Je ne serais pas t'expliquer en entier, mais grossièrement, le système d'exploitation va créer ou utiliser ce qui s'appelle une "page d'échange" ou encore une "partition scratch". Il peut ainsi allouer de la mémoire vive ou de la mémoire dure virtuelle via cette page d'échange entre les deux mémoires.""

si tu parle de la traduction des adresses Virtuelle en adresses Physique c'est le MMU qui s'en occupe via une table

"Non (d'ailleurs, pourquoi un tableau de char ?). Je ne connais pas trop bien ce que sont les buffers virtuels, mais de ce que j'ai pu comprendre, ce sont des "bout de mémoire vive" qui sont traitées de la même façon qu'un buffer réel par un programme (volontairement ou non) ou par l'OS, selon les besoins. L’avantage de ces buffers virtuels, est qu'ils sont dynamiques, au temps dans leur capacité de stockage (qui est quand même limitée) qu'en nombre, même si encore une fois c'est limité. Je pense qu'une application ne doit pas dépasser 256 buffers virtuels, mais je n'affirme rien. Voici un exemple en Visual Basic, je pense que ça te parlera mieux qu'en C :"

Ce que je voulais dire par un Tableaux c'est que les adresses Virtuelle d'une mémoire virtuelle doit être stocker quelque part ?, un peu Paradoxal nn ?

"buffer n'est qu'au final le nom donné à un élément (virtuel ou non) qui agit de façon à rendre accessible des données de manière temporaire pour les rendre plus dynamique et rapide lors de leurs utilisations par un quelconque programme."

Exact !  et vu qu'un Buffer (Virtuelle) n'est qu'une mémoire Virtuelle qui agit d'une certaine façon , un buffer Virtuelle reste fidele à son programme et peut partager avec d'autres programmes ses données

-
Edité par Anonyme 12 février 2018 à 17:09:03

Et bien, je pense que tu as bien tout assimilé !

Gusus a écrit:

Humm pas obliger la mémoire virtuelle utilise le disque dur comme extension que quand la RAM n'a plus de place normalement ?

Pas nécessairement, certains processus utilise ce principe pour se faire "discret" et consommé peu de "vrais" mémoire vive. Je ne serais pas te dire lesquels. Mais par contre, je sais que ce n'est pas simple à implémenter, et je pense même que seul l'OS, dans une mesure convenable, sache faire ça.

Gusus a écrit:

Ce que je voulais dire par un Tableaux c'est que les adresses Virtuelle d'une mémoire virtuelle doit être stocker quelque part ?, un peu Paradoxal nn ?

Je n'ai pas trop compris cette phrase, mais toutes les données doivent bien être stockées à un endroit à un moment ou un à autre. La virtualisation bufferielle (j'ai inventé ce mot, mais on se comprend ^^), on ne doit pas l'entendre de cette manière : "si c'est virtuel, c'est que c'est faux", mais plutôt comme ça : "si c'est virtuel, c'est que les informations sont transformées", si tu vois ce que je veux dire.

______

J'aurais aussi une petite question à te poser : pourquoi tant de questions à propos des buffers ? Tu as un projet particulier, un examen à rendre, ... ?

Pas nécessairement, certains processus utilise ce principe pour se faire "discret" et consommé peu de "vrais" mémoire vive. Je ne serais pas te dire lesquels. Mais par contre, je sais que ce n'est pas simple à implémenter, et je pense même que seul l'OS, dans une mesure convenable, sache faire ça.

Ok

Je n'ai pas trop compris cette phrase, mais toutes les données doivent bien être stockées à un endroit à un moment ou un à autre. La virtualisation bufferielle (j'ai inventé ce mot, mais on se comprend ^^), on ne doit pas l'entendre de cette manière : "si c'est virtuel, c'est que c'est faux", mais plutôt comme ça : "si c'est virtuel, c'est que les informations sont transformées", si tu vois ce que je veux dire.

jvois ce que tu veux dire , mais avec les différentes explications que je trouve soit c'est pas clair , pas détailler ou se contredise... 

Du coup je sais tjrs pas si une mémoire virtuelle c'est simplement des adresses logiques qui une fois traduites renvoi vers les données, c'est à dire que quand un programme veut accéder à une données il s'adresse à une adresse logique , ni comment ces adresses logique sont stocker, par exemple si elles sont dans un fichier que le programme à créer. Dans ce qu'a ça voudrait dire qu'on pourrait trouver les données dans la RAM sans avoir besoin des adresses logiques ?

parce-que une mémoire virtuelle dans un DD les adresses logiques et les données sont stocker et organiser dans un fichier qui est pagefile.sys qui ensuite sont copiés dans la RAM (pour le programme qui en à besoin). Du coup je sais pas si c'est le même principe en RAM , si la mémoire virtuelle même dans la mémoire vive est un fichier contenant les pages et les données d'un programme qui ensuite sont copiées vers un emplacements de la mémoire vive ? mais ça prendrait encore plus de places nn ? 

J'aurais aussi une petite question à te poser

Oui bien-sur

 pourquoi tant de questions à propos des buffers ? Tu as un projet particulier, un examen à rendre, ... ?

un projet maintenant non 

un examen à rendre, ... ?

Non

-
Edité par Anonyme 17 février 2018 à 2:22:34

Gusus a écrit:

Je vois ce que tu veux dire, mais avec les différentes explications que je trouve soit c'est pas clair, pas détailler ou se contredise... 

Comme je te l'ai déjà dit précédemment, je ne m'y connais pas plus que ça avec les buffers virtuels, mais je pourrais te les expliquer (encore) d'un autre point de vue : la gestion de mémoire en couche :

 

J'espère que mon petit schéma te plaît Il est inspiré d'une de mes sources, voir fin du message.

Comme tu peux le voir, le procédé de gestion de la mémoire, je devrais même dire "des mémoires", suis une tâche difficile autant à expliquer, qu'à faire. Raison pour laquelle, lorsque nous créons des programmes, nous n'avons qu'une infime partie de mémoire à gérer. Le reste est directement ou indirectement géré par le compilateur/l'OS. Le système d'exploitation fournit des APIs, et des fonctions qui s'occupent justement de ça, sous Windows, on a le CRT (C/C++ Library Runtime), et d'autres DLL par exemple.

*(1) API de gestion du tas

Un tas, comme son nom semble l'indiquer, est une partition de mémoire dans laquelle la mémoire est allouée de façon "hasardeuse", contrairement à la pile, où les allocations se font de manière définie et successive.

*(2) API de fichiers mappé en mémoire virtuelle

Alors... Ça c'est compliqué, et je ne pourrais pas garentire ta compréhension. Mais grossièrement, et comme je te l'ai déjà dit, la mémoire virtuelle n'est rien d'autre qu'ne transformation (ou un état si tu préfères) d'adressage mémoire grâce à un fichier d'échange ("fichier" est un bien grand mot). Il va permettre de contrôler les allocations (quand je parle d'allocations, ce ne sont pas les allocations familiales, hein ) entre la mémoire (selon le tas ou la pile) et ton programme, et ses processus. C'est une sorte "sécurité" si tu veux (entrent très gros guillemets, parce que ce n'est pas tout à fait ça non plus).

Je ne voudrais pas que tu confondes certaines choses, mais il y a plusieurs utilisations différentes du mot "virtuelle" lorsque l'on parle de la mémoire. Donc ce que tu aurais pu lire, et qui est en contradiction avec d'autres choses, n'est pas forcément faux.

> Dans ce qu'a ça voudrait dire qu'on pourrait trouver les données dans la RAM sans avoir besoin des adresses logiques ?

Oui. Analogie :

Les habitants d'un immeuble possèdent tous leurs boîtes à lettres, à l'entrée de celui-ci. Le facteur va déposer le courrier dans les boîtes aux lettres correspondantes, mais les habitants (ou quiconque) peuvent fouiller dans les boîtes aux lettres de leurs voisins, sans pour autant savoir où ils habitent.

> si la mémoire virtuelle même dans la mémoire vive est un fichier contenant les pages et les données d'un programme qui ensuite sont copiées vers un emplacements de la mémoire vive ? mais ça prendrait encore plus de places nn ? 

cf: expliqué au-dessus.

> [...] Non [...]

C'est assez rare, je trouve, quand une personne s'accroche tant à la compréhension d'un élément

Si tu veux une autre source sûr qui explique la gestion de la mémoire, en voici une. Voici aussi la documentation Microsoft sur le sujet.

J'espère que cette fois, c'est la bonne xD

N'hésites pas si tu as d'autres questions, ou si tu n'as pas compris certaines choses. Si tu as toujours un peu de mal avec les buffers virtuels, je pense que les 2 liens que je t'ai mis pourraient t'être utile.

Salut , j'ai pas encore eu le temps de tout regarder , mais j'ai une question . es-que c'est le programme qui demande de créer un Buffer Virtuelle ,  ou une Mémoire Virtuelle etc... ? ou c'est l'OS qui s'occupe de tout ça sans que le programme sache quoi que se soit , c'est à dire que lorsque que le programme désire de récupérer la valeur d'une variable par exemple , il ne "voit" pas si c'est une mémoire Virtuelle ou autres ? et es-que dès qu'il y a un flux de données L'OS s'occupe de créer un Buffer si nécessaire sans que le programme fasse quelle que chose ? Bref en gros le programme exécute juste les instruction sans "rien" faire et ne "voit" rien à ce niveau là ?

-
Edité par Anonyme 19 février 2018 à 20:20:55

Ça dépend les cas. Mais le plus généralement, c'est l'OS qui gère tout ça. Cependant, grâce à des API (voir schéma ci-dessus) fourni par celui-ci, les programmes que tu crées y ayant accès, tu peux implémenter (et je dis bien "implémenter") tes propres allocations dans tes propres buffers virtuels et dans les emplacements mémoire que tu veux. C'est assez facile de faire ça en assembleur d'ailleurs.

Sinon les programmes, dans la plupart des cas, n'ont pas besoin de gérer la mémoire au sens propre de l'ordinateur. En assembleur par exemple, lorsque tu crées un programme, celui-ci devra toujours commencer par une instruction d'allocation d'emplacement d'exécution :

org 500h

Ceci indiquera l'adresse de mémoire vive ou débutera l'exécution du programme si tu veux. Si tu veux accéder à une valeur x ou y, il faudra savoir (exactement) à quel endroit elle se situe :

val dw 76h
mov eax, [val]
;...
add [eax + 0], ecx ; --> Adresse de la valeur 'val'

(Mon 8051 est un peu rouillé, et je ne suis pas totalement sur de l'exactitude de ce code, mais c'est pour illustrer.)

Ce code, transcrit en C, donne ceci :

int val = 76;
val += *VALEUR;

Traduit en VB.NET :

dim val = 76
val += VALEUR

Donc, oui et non : un programme peut créer ses propres buffers virtuels, mais généralement, c'est l'OS qui les attribue, et parce que ça dépend aussi du langage; comme tu as pu le voire en assembleur Intel 8051, en C99 et en Visual Basic .net .

Gusus a écrit:

Bref en gros le programme exécute juste les instruction sans "rien" faire et ne "voit" rien à ce niveau là ?

Le microprocesseur se charge de ça, grâce à l'OS qui contrôle le tout, en tant qu'intermédiaire.

-
Edité par vanaur 19 février 2018 à 21:11:36

Ok donc oui si un programme est programmer pour et non pour le contraire ?

Je n'ai pas trop compris le sens de ta phrase. Pourrais-tu reformuler (sans edit, parce que sinon je ne vois pas la notification) ?

Ok, donc oui si un programme est programmer pour créer ses propres Buffers et non pour le contraire ?

(je n'ai toujours pas trop compris, mais on va faire avec ^^)

Comme je te l'ai déjà dit, les buffers sont (pour la majorité des cas, si pas toujours (99.94%)) alloué automatiquement par l'OS pour un quelconque programme. Mais si tu te souviens bien, l'OS lui-même n'étant composé que d'une longue série de programmes, il doit bien y en avoir un ou deux dans le tas qui gère la mémoire par application. Par conséquent, cela dépend fortement des cas, mais oui : un programme peut créer son propre buffer. (C'est plus complexe que ça l'histoire de la série de programmes, mais c'est pour ne pas trop d'embrouiller !)

Je n'ai pas eu le temps pour un long texte, désolé.

ma réponse étais juste pour être confirmer par ta réponse "oui" ou "non" ou une autre réponse . Il n'y avait pas quelques chose à comprendre en plus

ce que je voulais dire par "et non pour le contraire ?" c'est que pour qu'un programme puisse créer sa propre mémoire virtuelle il faut qu'il y ai du code dans le programme pour créer nn ? et qu'a l'inverse c'étais l'OS 

-
Edité par Anonyme 23 février 2018 à 22:59:19

Gusus a écrit:

Ce que je voulais dire par "et non pour le contraire ?" c'est que pour qu'un programme puisse créer sa propre mémoire virtuelle il faut qu'il y ai du code dans le programme pour créer nan ? Et qu'a l'inverse c'étais l'OS

Oui, forcément

________

Donc, le sujet est-il (enfin) [résolu] ?

Ok 

Pas tout à fait xD 

Le lien que tu m'as donné celui-ci https://www.sciencedirect.com/science/article/pii/S0160289602001150 

Le PDF il est bien payant ?

Malheureusement, oui, le PDF est payant (j'avoue ne pas y avoir fait attention, désoler).

Mais normalement, si je m'y tiens aux descriptions du PDF, je t'ai déjà donné pas mal d'informations via ce poste N'oublie pas que je t'ai aussi donné un autre lien, vers une source Microsoft. Il est tout aussi bien je pense.