initialisation tableau = segmentation fault ?!?

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:

---

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 ?

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

merci d'avoir répondu,

qu'appel tu une pile ?

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

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 ^^

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

Citation:

---

Envoyé par Astraya

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 ...

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?

Citation:

---

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:

---

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

---

Citation:

---

Envoyé par Astraya

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 ?

Citation:

---

Envoyé par Astraya

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:

---

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; }

---

Citation:

---

Envoyé par Astraya

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....?

Bonne lecture!! :P

Salut,

Citation:

---

Envoyé par membreComplexe12

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 :D

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 ;)

Super explication :ccool::ccool::ccool::ccool::ccool::ccool:
merci beaucoup

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:

---

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 :aie:)

merci, j'ai bien compris à présent ;)

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:

---

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 !!!

Citation:

---

Envoyé par membreComplexe12

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.

Citation:

---

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", ...)

Citation:

---

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

Citation:

---

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.

Citation:

---

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 :aie:

Citation:

---

Envoyé par koala01

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 ?

Citation:

---

Envoyé par koala01

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 :)

Citation:

---

Envoyé par membreComplexe12

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 ;)

Citation:

---

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,

Citation:

---

Envoyé par Donald Knuth

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 ;)

Citation:

---

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 :aie:

Citation:

---

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 :question:

merci beaucoup pour toutes ces informations :ccool::ccool::ccool:

Citation:

---

Envoyé par koala01

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.

Citation:

---

Envoyé par membreComplexe12

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

---

Pour te donner quelques chiffres, le temps nécessaire pour accéder à une donnée dans la mémoire cache est de l'ordre de quelques nano-secondes. Dans la mémoire RAM, c'est plusieurs dizaines de nanosecondes. Dans le disque-dur, c'est plus long.

C'est un ordre de grandeur, car ces différentes valeurs sont différentes selon le processeur, la mémoire RAM, et le chaque disque dur :)

Et pour faire une (très grosse) simplification (il y a d'autres facteurs), c'est plus rapide de trouver une donnée dans un cache de 1Mo que dans un disque dur de 100Go car tu c'est plus rapide de trouver un boulon particulier dans un petit sac que dans un camion.

Edit : J'ai simplifié pour éviter qu'il pose des questions sur les différentes technologies (pourquoi on fait pas un cache de 100Go si ça va plus vite qu'un disque dur ?) avant d'avoir la base.

Citation:

---

Envoyé par ManusDei

c'est plus rapide de trouver une donnée dans un cache de 1Mo que dans un disque dur de 100Go car tu c'est plus rapide de trouver un boulon particulier dans un petit sac que dans un camion.

---

Il y a d'autres facteurs qui dominent largement le problème e la taille. Un disque de 100Go a de forte chance d'être un disque dur mécanique et non SSD. Or c'est infiniment plus long de déplacer une tête de lecture physiquement que de sélectionner un registre électronique, même parmi un grand nombre. (La preuve étant que les SSD (clefs USB, "disques durs" SSD) sont nettement plus rapides que les disques durs mécaniques pour des tailles comparables.

Citation:

---

Envoyé par therwald

Il y a d'autres facteurs qui dominent largement le problème e la taille. Un disque de 100Go a de forte chance d'être un disque dur mécanique et non SSD. Or c'est infiniment plus long de déplacer une tête de lecture physiquement que de sélectionner un registre électronique, même parmi un grand nombre. (La preuve étant que les SSD (clefs USB, "disques durs" SSD) sont nettement plus rapides que les disques durs mécaniques pour des tailles comparables.

---

Et encore, si on veut être tout à fait complet, il faut prendre en compte les caractéristiques du chemin parcouru par les données quand elles doivent aller d'un périphérique à l'autre (en considérant le processeur comme un périphérique pour le coup).

Il faut comprendre que les données au niveau d'un ordinateur ne sont jamais que des successions de 1 et de 0 : le courent passe ou il ne passe pas.

Chaque "partie du système" (le processeur, la RAM ou le support quelconque, le trajet suivi par les information) est susceptible de fonctionner à une fréquence donnée, ou, si tu préfères, pendant un certain temps qui correspond à la division d'une seconde par la valeur de la fréquence (on parle de "cycle").

Si tu as une succession aléatoire de 5 valeurs (0 ou 1) qui doit passer par une même broche, par un même cable (ou équivalent), il faudra 5 cycles minimum pour arriver à faire "passer" les cinq valeurs par le cette broche ou ce cable.

La transmission des données est donc limité à la capacité maximale du "système" le plus lent par lequel elles doivent transiter.

C'est un peu comme si deux tronçons d'autoroutes à cinq bandes étaient reliés entre eux par une route à voie unique limitée à 30 km à cause de la présence d'une école: sur le tronçon "d'entrée", il y a beaucoup de voitures qui peuvent arriver très vite en même temps, mais elles seront toutes "bloquées" à la fin du premier tronçon par le fait qu'il n'y a qu'une voiture qui peut passer, à vitesse très réduite, sur la petite route.

Le deuxième tronçon ne sera donc jamais utilisé au maximum de sa capacité, simplement parce que le nombre de voitures qui arrive dessus est limité, et ce, même si elles peuvent de nouveau rouler à 120km/h.

C'est pour cela qu'il arrive régulièrement qu'un ordinateur donné, bien qu'il dispose du meilleur processeur et de la meilleure RAM possible mais "mal équilibrés" du fait de la vitesse à laquelle les données peuvent transiter de l'un à l'autre, est parfois plus lent et moins performant qu'un autre ordinateur, utilisant un processeur et de la RAM un peu plus lents, mais plus adaptés à la vitesse à laquelle les données peuvent transiter de l'un à l'autre.

Et c'est pour cela qu'un disque dur prévu pour être branché sur un port USB3 ne présentera jamais qu'un taux de transfert équivalent à l'USB1 s'il est branché sur un tel port, ou qu'une clé USB1 ne présentera jamais de taux de transfert supérieur à ce qu'on peut attendre de la part de l'USB1, même si elle était branchée sur un port USB3.

En un mot comme en cent : la capacité maximale de toute chaine n'est jamais supérieure à la capacité maximale du maillon le plus faible ;)

Tout cela pour bien te faire comprendre que l'on peut épiloguer pendant 106 ans sur "ce qui est plus rapide qu'autre chose", on en reviendra toujours au même point : il y a (beaucoup) trop de facteurs à prendre en ligne de compte pour pouvoir se faire une idée précise autre que "au coup par coup".

Le seul point sur lequel le développeur C++ a réellement le contrôle (en dehors d'une organisation des données qui permette une mise en cache plus efficace) est l'algorithme utilisé pour obtenir le résultat escompté.

Tu peux décider de passer par Berlin, Londres, Varsovie et Vladivostok pour aller de Bruxelles à Paris, mais cela te prendra beaucoup plus de temps pour le faire que si tu décidais d'aller de Bruxelles à Paris "en ligne droite".

Le reste, c'est de l'optimisation prématurée, qui ne doit être envisagée qu'à partir du moment où:

• tu es sur d'avoir le "meilleur" algorithme qui soit
• tu as une application fonctionnelle
• tu as fais des tests pour évaluer clairement l'endroit qui pose des problèmes de performances.

Il existe d'ailleurs une règle empirique qui dit que l'on passe 80% du temps d'exécution sur 20% du code.

Cela signifie que tu n'auras qu'un bénéfice très limité à essayer d'optimiser (autrement que par de meilleurs algorithmes) 80% de ton code ;)

merci tous pour ces compléments :ccool:
je vais lire un bouquin là dessus un de ces quatre et regarder la documentation que vous m'avez énoncée.
encore merci
A bientôt