différence tableau int[n] #C /Objc-C

prepa75prepa75 Membre
07:19 modifié dans API AppKit #1
Bonjour,

je me pose une question(d'ailleur j'espère être dans la bonne section...) pourquoi lorsque je cré un tableau C de type int[10] par ex je suis limité à  un nombre de case presque 4X inférieur à  un même tableau en Obj-C ?

je vous donne un ex pour être clair :

valeur max : int[130000000] en obj-C avant d'avoir un dépassement de mémoire
valeur max : int[500000000] et des poussières en C...

quelqu'un pourrai me dire comment remédié à  ça ou au pire à  m'expliquer pourquoi il y a une telle différence ?

merci par avance.

Réponses

  • AliGatorAliGator Membre, Modérateur
    07:19 modifié #2
    Je vois plusieurs explications possibles :
    - sizeof(int) n'a pas la même valeur dans les deux cas. C'est très possible si tu n'utilises pas les mêmes options de compilation (flags de GCC) pour compiler l'un et l'autre des programmes, ou genre un en 32 bits et l'autre en 64 bits, ...
    - Dans la même veine, si tu n'utilises pas les mêmes options de GCC dans les deux cas il se peut que l'un des cas limite la taille de la HEAP à  une valeur et l'autre à  une autre
    - Tu as comparé un programme C avec juste un main() et un programme ObjC incluant du Cocoa (donc avec NSApplicationMain() dans le main.m du projet Cocoa), or ce dernier a déjà  tout le runtime Cocoa, la gestion des événements et la RunLoop chargé en mémoire du coup par ce mécanisme sous le capot, que n'a pas un programme C avec juste un main(). Du coup t'as déjà  un bout de mémoire de pris avec tout ça donc il t'en reste moins pour créer ton tableau

    N'oublie pas que int[N] va allouer en dur (mm pas de façon dynamique donc) un semble contigu d'octets, donc N octets qui se suivent... Faut trouver une zone de la mémoire qui soit vide sur assez d'octets pour stocker autant de "cases" !
    De manière générale, ce n'est pas une super idée que de créer des tableaux C aussi conséquents.
  • prepa75prepa75 Membre
    07:19 modifié #3
    Merci Ali pour tes réponses aussi détaillées,

    En effet je ne compilais pas de la même manière et j'ai pu réduire un peu l'écart...

    J'avais oublier le coup de la RunLoop, en effet en #C il n'y a que la main() donc plus de place 

    en effet comme tu le dit ce n'est pas une super idée de blindé la ram, j'ai donc opté pour écrire dans un fichier les données dont j'ai besoin...comme ça je les récupèrent directement et je ne rempli pas ma mémoire  8--)

  • AliGatorAliGator Membre, Modérateur
    07:19 modifié #4
    Et à  ton avis, elles vont où les données le temps de les charger et les lire depuis le fichier ?
  • prepa75prepa75 Membre
    07:19 modifié #5
    oui oui je suis d'accord avec toi mais je fait des passes de remplissage en fait... je me suis mal exprimé  :P
  • AliGatorAliGator Membre, Modérateur
    07:19 modifié #6
    Si tu as autant de données que ça (là  vu les nombres que tu avances et les solutions vers lesquelles tu semble te tourner ça a l'air important), orientes-toi tout de suite vers une solution dédiée plutôt, genre sqlite3 qui est assez orienté pour ce genre de trucs.
  • prepa75prepa75 Membre
    07:19 modifié #7
    Merci pour l'info Ali,je crois que je vais m'y mettre sérieusement parsque j'ai des milliard de Nombres (je suis toujours sur mon algo des Nombres Premiers  :P ) et je suis en train de bricoler des boucles qui augmentent considérablement les temps de calculs...
Connectez-vous ou Inscrivez-vous pour répondre.