Discussion :

[membreComplexe12]

Bonjour tous,

j'ai un probl�me tr�s bizarre en C++...

j'ai fais un programme "main.cpp" et j'ai seulement initialis� un tableau et �a plante!

voici mon code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
 
#include <iostream>
 
using namespace std;
 
int main()
{
    int tableau[1501][1187];
    cout << "test" << endl;
    return 0;
}

�a fait longtemps que j'ai pas programm� mais l� �a me parait fort quand m�me...

j'ai essay� sous un autre IDE et il me met "segmenttion fault"

qu'es ce que j'ai fais comme b�tise ?

[therwald]

Ton tableau est selon toute probabilit� bien trop gros pour la pile...d'o� l'�chec de son initialisation.

[membreComplexe12]

merci d'avoir r�pondu,

qu'appel tu une pile ?

que faire pour que �a passe ? (car j'ai vraiment besoin de ce tableau...)

[Astraya]

pourquoi vouloir un tableau si enorme?

calculons:
int = 4 octets

int tableau[1501][1187] = 1501*1187*4 = 7,126,748 soit 7 go....

EDIT: 7Mo ^^

[membreComplexe12]

En fait j'ai un fichier r�sultat (�crit en binaire) qui fait cette taille et que je dois lire...

[membreComplexe12]

soit 7 go....

plut�t 7 Mo


au passage, si vous savez comment lire un tableau bidimensionnel �crit dans une fichier texte en binaire (32bits) je suis preneur car je gal�re un peu ...

[Astraya]

Un fichier resultat ok mais �a n'explique pas pourquoi un si gros tableau. Tu dois pouvoir traiter les informations en plus petites parties successive non?

[Astraya]

plut�t 7 Mo

Effectivement ^^
Mais ca ne change pas que c'est trop gros pour la stack. Alloue le dans le heap avec new

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

int * tableau = new int[1501*1187];

[membreComplexe12]

Mais ca ne change pas que c'est trop gros pour la stack. Alloue le dans le heap avec new

je ne comprends pas du tout cette phrase (je suis d�butant)
pourrais tu me traduire �a stp en langage plus compr�hensible pour un novice ?

Tu dois pouvoir traiter les informations en plus petites parties successive non?

tu as tout � fait raison,
c'est ce que je suis en train de r�fl�chir...

en fait j'ai une matrice sauvegard�e en binaire dans un fichier texte et j'aimerai lire cette matrice, et r�ecrire les resultats dans un fichier non binaire...

saurais tu me dire comment faire ceci stp ?


il faut que je modifie ceci mais je ne sais pas trop comment

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
/* fread example: read an entire file */
#include <stdio.h>
#include <stdlib.h>
 
int main () {
  FILE * pFile;
  long lSize;
  char * buffer;
  size_t result;
 
  pFile = fopen ( "myfile.bin" , "rb" );
  if (pFile==NULL) {fputs ("File error",stderr); exit (1);}
 
  // obtain file size:
  fseek (pFile , 0 , SEEK_END);
  lSize = ftell (pFile);
  rewind (pFile);
 
  // allocate memory to contain the whole file:
  buffer = (char*) malloc (sizeof(char)*lSize);
  if (buffer == NULL) {fputs ("Memory error",stderr); exit (2);}
 
  // copy the file into the buffer:
  result = fread (buffer,1,lSize,pFile);
  if (result != lSize) {fputs ("Reading error",stderr); exit (3);}
 
  /* the whole file is now loaded in the memory buffer. */
 
  // terminate
  fclose (pFile);
  free (buffer);
  return 0;
}

Tu dois pouvoir traiter les informations en plus petites parties successive non?

en fait j'ai fais ceci � la base car si j'ai bien compris la fonction "fread "
elle n�cessite de donner la taille de la chose que l'on veut lire et elle renvoi le r�sultat dans un tableau correspondant....?

[Astraya]

Bonne lecture!!

[koala01]

Salut,

je ne comprends pas du tout cette phrase (je suis d�butant)
pourrais tu me traduire �a stp en langage plus compr�hensible pour un novice ?

Bon, on distingue deux espaces m�moire diff�rents (en fait, il y en a plus, mais deux nous int�ressent ici): la pile et le tas (respectivement stack et heap).

Le premier devrait �tre en r�alit� appel� "pile d'appels". C'est un espace m�moire g�r� par le processeur dans lequel il va empiler, entre autres, les informations relatives � la fonction appelante � chaque fois qu'il y a un appel de fonction (pour pouvoir les r�cup�rer une fois que la fonction appel�e est termin�e) ainsi que les variables pour lesquelles on n'a pas recours � l'allocation dynamique de la m�moire.

A chaque fin de fonction, il va d�cider d'ignorer toutes les informations qu'il a mise sur la pile depuis l'appel de la fonction (c'est vraiment comme une pile d'assiettes : tu ne peux � chaque fois acc�der qu'� la derni�re assiette plac�e sur la pile, mais tu peux d�cider d'en retirer dix d'un coup).

Cet espace m�moire est particuli�rement limit�, de l'ordre de 1 � 2 Mb au maximum.

Si la taille totale des donn�es que tu essayes de mettre sur la pile d'appels, les donn�es vont aller se fourrer � des endroits inattendus qui provoqueront des catastrophes (stack overflow, erreur de segmentation, ...).

Le tas quant � lui repr�sente toute la m�moire accessible par le syst�me : La m�moire r�elle (RAM) + La m�moire virtuelle (swap) et peut donc repr�senter plusieurs Gb de donn�es.

C'est dans le tas qu'iront se loger les donn�es � chaque fois que tu vas faire appel � l'allocation dynamique de la m�moire ( appel de new ou de new[]).

Cet espace m�moire est g�r� non pas par le processeur, mais directement par le syst�me d'exploitation, qui va essayer � chaque fois de trouver un espace m�moire contigu suffisant correspondant � la taille que tu lui as demand�.

Cela implique deux choses:

1. Le syst�me aura beaucoup plus facile � trouver 7Mb d'espace m�moire contigu
2. Si tu ne veilles pas � indiquer au syst�me que l'espace est de nouveau disponible (avec delete), c'est toute la stabilit� du syst�me en lui-m�me qui peut �tre remise en cause.

L'avantage, c'est qu'un pointeur ne fait jamais que quelques bytes (indument traduit sous le nom d'octet en francais) : classiquement, on consid�re (mais ce n'est pas forc�ment vrai) qu'un pointeur est repr�sent� par 4 bytes (32 bits) sur les syst�mes 32 bits et par 8 bytes (64 bits) sur les syst�mes 64 bits.

Comme c'est le pointeur qui prend place dans la pile d'appels, il y a moyen d'en mettre beaucoup plus avant d'atteindre la capacit� maximale de celle-ci

Dans le cas pr�sent, therwald et Astraya te disent, en substance, que 7Mb c'est beaucoup trop gros pour tenir dans la seule pile d'appels et qu'il faut donc recourir � l'allocation dynamique de la m�moire pour que les donn�es aillent se nicher dans le tas

[membreComplexe12]

Super explication
merci beaucoup

[therwald]

Sinon, pour r�pondre � ta question initiale, la pile (stack) est l'espace o� sont stock�es toutes les variables locales et les arguments de fonction. C'est typiquement un espace de quelques kilos ou quelques m�gas, et r�server 7Mo sur la pile a peu de chances de marcher.
Si tu veux avoir plus de m�moire, il faut r�server dans l'autre espace de stockage de C++, le tas (heap). A la base, cela se fait par new (avec lib�ration par delete). Pour �viter cette gestion manuelle de m�moire qui favorise les erreurs, il existe des classes standard pour pas mal d'usages. Dans le cas d'un tableau, une des classes est std::vector, qui cr�e un tableau dynamiquement extensible. (note que cette classe fait bien des new/delete, en tous cas par d�faut, mais en interne, de sorte que tu n'as pas � t'en pr�occuper).
exemple:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

std::vector<int> vect(1000);

r�serve un tableau d'int de taille 1000 (mais si tu ajoutes un 1001 �me �l�ment, l'extension est automatique.)
voir la documentation

EDIT: koala01 d�gaine plus vite que son ombre (ou le mienne en tous cas )

[membreComplexe12]

merci, j'ai bien compris � pr�sent

[membreComplexe12]

j'ai trois autres (grandes) questions:

1) "la pile" (stack) existe car elle est plus rapide que "le tas" (heap) ??
Si non, alors pourquoi ne pas tout mettre dans le "le tas" ?

Si ce que je dis est vrai, alors il vaut mieux peut etre manipuler dans un programme les tableaux sous formes de petites donn�es qui seront stock�es dans le stack et de temps en temps vider dans le heap ?
car si on travail toujours dans le heap on peut perdre en terme de performences ?

2) avez vous un cours � me conseiller qui part de z�ro et qui traite ce genre de choses (qui fait le lien entre la programmation et le mat�riel, m�moires...etc?)
un peu comme ce que vous m'avez expliqu� l� mais plus g�n�ral, sur les temps d'acc�s au disque, diverses m�moires...etc


3) concernant mon probl�me de base,
pourriez vous m'expliquez comment modifier ce bout de code
afin de r�cup�rer mes donn�es qui sont sous forme de flottant mais enregistr� en binaire et les convertir en flottant et enregistrer en ascii (en nombres quoi..)

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <iostream>
#include <fstream>
int main()
{
   using std::ifstream;
   using std::ofstream;
   using std::ios;
   ifstream ifs("in.xyz",  ios::binary);
   ofstream ofs("out.xyz", ios::binary);
 
   //
   char c;
   while (ifs.get(c))
   {
       ofs.put(c);
   }
        return 0;
}

comme un flottant est cod� sur 4octets il faut que je fasse 4 ifs.get(c) � la suite, puis apr�s que je concat�ne et que je traduise en "float" et qu'ensuite j'enregistre ce float avec "fprintf" ?

je vous remercie pour votre aide !!!

[koala01]

j'ai trois autres (grandes) questions:

1) "la pile" (stack) existe car elle est plus rapide que "le tas" (heap) ??

C'est souvent le cas.

Si non, alors pourquoi ne pas tout mettre dans le "le tas" ?

Parce que le processeur ne peut acc�der � l'ensemble de la m�moire qu'au travers de quelques �l�ments constitutifs qui lui sont propres (pointeur d'adresse, accu, pile d'appels, cache "L1","L2","L3", ...)

Si ce que je dis est vrai, alors il vaut mieux peut etre manipuler dans un programme les tableaux sous formes de petites donn�es qui seront stock�es dans le stack et de temps en temps vider dans le heap ?

C'est impossible sans passer par l'assembleur

car si on travail toujours dans le heap on peut perdre en terme de performences ?

Les temps d'acc�s sont, effectivement, plus lents quand on est dans le tas que dans la pile, c'est pour cela que le processeur dispose de diff�rents niveau de cache.

Ce sont des espaces m�moire, g�r�s par le processeur, dont je n'ai pas parl� l� tantot qui permettent de charger les donn�es qui se trouvent dans le tas sous la forme de "lignes" et de "pages", mais qui ne font �galement que maximum 1 � 2 Mb (si je ne me trompe pas), lorsqu'il "charge" la m�moire du tas, que la donn�e � laquelle il devra acc�der apr�s la donn�e dont il a besoin maintenant se trouve dans la m�me ligne / page de cache.

Mais, encore une fois, on se retrouve au niveau de la "magie interne" du processeur et il n'est possible d'en tenir compte (et encore) qu'en assembleur.

2) avez vous un cours � me conseiller qui part de z�ro et qui traite ce genre de choses (qui fait le lien entre la programmation et le mat�riel, m�moires...etc?)
un peu comme ce que vous m'avez expliqu� l� mais plus g�n�ral, sur les temps d'acc�s au disque, diverses m�moires...etc

Je n'en ai pas sous la main, et je ne suis m�me pas sur qu'il existe un cours sp�cifique sur le sujet.

Les informations que l'on peut g�n�ralement retrouver sur le sujet sont soit particuli�rement g�n�rale (par exemple : l'acces disque est plus lent que l'acc�s RAM qui est plus lent que le cache, qui est plus lent que la pile), mais les valeurs en elles-m�mes sont beaucoup trop sensibles � �norm�ment de param�tres mat�riel (taille des bus de donn�es, temps de latences, etc) pour qu'il soit possible d'�tre beaucoup plus pr�cis que cela

[membreComplexe12]

C'est impossible sans passer par l'assembleur
Les temps d'acc�s sont, effectivement, plus lents quand on est dans le tas que dans la pile, c'est pour cela que le processeur dispose de diff�rents niveau de cache.

si dans le tas c'est plus rapide que dans la pile on peut imaginer manipuler dans un programme que des tableaux statiques (donc allou�s dans le tas)
de taille moyenne pour faire des calculs et lorsque les calculs sont finis et que
l'on veut par exemple stocker les r�sultats (ou faire un certain type de calcul plus important) alors on fait une boucle pour vider tous nos tableau statiques dans un tableau dynamique... ?

si on fait beaucoup de petits calculs et que l'on stock que de temps en temps les donn�s dans la pile alors on peut imaginer y gagner en performence...

par contre, es ce g�nant si on a tendance � surcharge le tas ?
quelles cons�quences �a peut avoir sur l'execution d'un programme ?

Les informations que l'on peut g�n�ralement retrouver sur le sujet sont soit particuli�rement g�n�rale (par exemple : l'acces disque est plus lent que l'acc�s RAM qui est plus lent que le cache, qui est plus lent que la pile),

en fait c'est �a que je recherche.
j'aimerai bien trouver un cours pour d�butant (mais qui qui se complexifie crescendo) qui permet de faire un point sur le mat�riel qui compose un ordi (processeur, disque dur, Ram, bus....) et qui explique comment un programme utilise ces diff�rents mat�riels
- lorsqu'on fait un variable ou elle est sauvegard�e, pourquoi l� et pas ailleurs... quand on �crit sur le disque pourquoi c'est long...
- j'aimerai bien aussi comprendre c'est quoi un bus, un temps de latence, de la m�moire cache, pourquoi il y en a plusieurs.... pourquoi on a plusieurs petits processeurs plut�t qu'un seul plus gros....etc

as tu une id�e de livre/cours assez g�n�ral sur tout ceci et qui fasse un peu le lien avec la programmation ? (et qui soit pour un d�butant)
ce n'est pas grave si �a ne'explique "qu'en surface" c'est deja pas mal pour moi

[koala01]

si dans le tas c'est plus rapide que dans la pile on peut imaginer manipuler dans un programme que des tableaux statiques (donc allou�s dans le tas)
de taille moyenne pour faire des calculs et lorsque les calculs sont finis et que
l'on veut par exemple stocker les r�sultats (ou faire un certain type de calcul plus important) alors on fait une boucle pour vider tous nos tableau statiques dans un tableau dynamique... ?

Tu ne m'as pas compris, c'est la pile qui est, a priori, plus rapide que le tas

si on fait beaucoup de petits calculs et que l'on stock que de temps en temps les donn�s dans la pile alors on peut imaginer y gagner en performence...

Oui, Mais cela nous emmene dans le monde de la micro optimisation.

Or,

Premature optimization is the root of all evil

(l'optimisation pr�matur�e est la source de tous les maux)

Il est int�ressant, pour sa culture g�n�rale, de savoir ce genre de choses, mais tu gagneras �norm�ment � travailler d'abord sur tes algorithmes en eux m�me pour les rendre le plus efficace possible

par contre, es ce g�nant si on a tendance � surcharge le tas ?
quelles cons�quences �a peut avoir sur l'execution d'un programme ?

Cela peut mener carr�ment au plantage de tout le syst�me : l'application seule dans le meilleur des cas, le syst�me d'exploitation (avec reboot obligatoire) dans le pire des cas

en fait c'est �a que je recherche.
j'aimerai bien trouver un cours pour d�butant (mais qui qui se complexifie crescendo) qui permet de faire un point sur le mat�riel qui compose un ordi (processeur, disque dur, Ram, bus....) et qui explique comment un programme utilise ces diff�rents mat�riels
- lorsqu'on fait un variable ou elle est sauvegard�e, pourquoi l� et pas ailleurs... quand on �crit sur le disque pourquoi c'est long...
- j'aimerai bien aussi comprendre c'est quoi un bus, un temps de latence, de la m�moire cache, pourquoi il y en a plusieurs.... pourquoi on a plusieurs petits processeurs plut�t qu'un seul plus gros....etc

as tu une id�e de livre/cours assez g�n�ral sur tout ceci et qui fasse un peu le lien avec la programmation ? (et qui soit pour un d�butant)
ce n'est pas grave si �a ne'explique "qu'en surface" c'est deja pas mal pour moi

En fait, ce que tu cherches, c'est un cours d'architecture mat�rielle.

Peut etre trouveras tu ton bonheur dans la section qui y est consacr�e du forum

[membreComplexe12]

merci beaucoup pour toutes ces informations

[jblecanard]

Ce sont des espaces m�moire, g�r�s par le processeur, dont je n'ai pas parl� l� tantot qui permettent de charger les donn�es qui se trouvent dans le tas sous la forme de "lignes" et de "pages", mais qui ne font �galement que maximum 1 � 2 Mb (si je ne me trompe pas), lorsqu'il "charge" la m�moire du tas, que la donn�e � laquelle il devra acc�der apr�s la donn�e dont il a besoin maintenant se trouve dans la m�me ligne / page de cache.

Mais, encore une fois, on se retrouve au niveau de la "magie interne" du processeur et il n'est possible d'en tenir compte (et encore) qu'en assembleur.

Ce n'est pas tout � fait vrai, il est possible d'en tenir compte, c'est ce qu'on appelle le cache-friendly code.

En revanche, l� ou Koala a quand m�me raison, c'est que c'est d'un niveau un peu trop avanc� pour que tu puisses l'exploiter pour le moment. C'est le genre de micro-optimisations qu'on ne va r�aliser que sur du code qui fonctionne d�j� mais qui a besoin de tr�s hautes-performances.