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.