Limite de taille d'un tableau - Page 1

J'ai besoin d'un tableau d'int qui va de 0 à 0xFFFFFFFF, or impossible d'initialiser un tel tableau, que ce soit avec calloc, malloc ou bien en constante, comment faire pour pouvoir avoir un tel tableau?

Passer en 64 bits.

Et acheter un paquet de RAM, aussi.
(Parce qu'avec des int sur 32 bits, il fait 16 Go, ton tableau).

(0 ~ 0xFFFFFFFF -> 2³² ints = 4 294 967 296 ints
32 bits par int -> 4 octets par int
4 294 967 296 * 4 = 17 179 869 184 octets = 16 Go)

#68kteux#

sauf que les ints font 32 bits partout sauf sur ti68k

non mais mieux, certains compilos 68k ont aussi des ints de 32 bits, d'ailleurs quand on compile un cross compilateur gcc "de base", il faut lui donner une option spéciale pour qu'il fasse des ints de 16 bits ^^

ti a décidé d'utiliser bcp de nombres de 16 bits (parce que ça suffit largement dans la plupart des cas), donc tigcc a des ints de 16 bits, pour éviter d'écrire "short" partout!

d'ailleurs je me demande quelle est la règle officielle pour définir la taille des "int" (et de toute, j'utilise toujours des uint32_t, int16_t, etc... maintenant )

squalyl (./11) :
d'ailleurs je me demande quelle est la règle officielle pour définir la taille des "int"

Je crois que la seule règle est "au moins 16 bits".

ça sert dans quel cas un tableau de 2^32 ints sinon ?

il me semble que la règle c'est quelque chose du genre
char <= short <= int etc...
(enfin vu de très loin, ça doit ressembler à ça )

le int doit faire la taille du bus d'adresse non? ce qui n'est plus respecté pour les archi 64bits.
sinon ya long >= int.

JackosKing (./15) :
le int doit faire la taille du bus d'adresse non?

Non. C'était censé être la taille native du CPU, en géneral la taille du bus de données (pas d'adresses), mais pour les CPUs 64 bits, ce n'est plus rentable (gaspillage de mémoire, donc mauvaise utilisation du cache etc.), d'où la convention LP64.

12> une méga table de hachage?

En fait, il a pas besoin de RAM pour allouer ca, si?

non mais déja dans malloc() on met un size_t et ça fait wordsize (cf stdint.h) donc il aura besoin d'une plate forme x86_64 pour pouvoir allouer ça même si il a 16 gigas de swap (en plus je crois bien que chaque processus linux x86/win32 a 2 GB d'espace d'adressage, alors c'est mort )

Il existe, au moins sous windows (et ça m'étonnerait que ça ne soit pas le cas sous linux (enfin je sais que linux gère plus de 4Go en 32 bits si le cpu le permet, mais je sais pas de quelle manière)), des extensions pour gérer plus de mémoire (pagination à la demande...) que ce que l'espace d'adressage ne permet, mais il reste qu'il faut toujours la mémoire pour allouer le tableau
Mais à mon avis pour poser la question de ./1 c'est que d3us ne comprend pas bien ce qu'il fait / cherche à faire.

Zerosquare (./3) :
Et acheter un paquet de RAM, aussi. (Parce qu'avec des int sur 32 bits, il fait 16 Go, ton tableau).

Zephyr (./13) :
ça sert dans quel cas un tableau de 2^32 ints sinon ?

en fait c'est jusqu'à 0x07FFFFF, j'aurais ptet du relire mon sujet avant de coder (en plus ca serait plutot des char pour le coup)
sinon, c'est pour une simulation d'un proc coldfire avec 128MO de mémoire

GoldenCrystal (./20) :
Mais à mon avis pour poser la question de ./1 c'est que d3us ne comprend pas bien ce qu'il fait / cherche à faire.

je viens juste de comprendre que j'avais vu un peu gros dans ma ram c'est tout

tain mais lol

GoldenCrystal (./20) :
Il existe, au moins sous windows (et ça m'étonnerait que ça ne soit pas le cas sous linux (enfin je sais que linux gère plus de 4Go en 32 bits si le cpu le permet, mais je sais pas de quelle manière)), des extensions pour gérer plus de mémoire (pagination à la demande...) que ce que l'espace d'adressage ne permet, mais il reste qu'il faut toujours la mémoire pour allouer le tableau

Ce sont 4 GO maximum par processus en 32 bits, et seulement avec un noyau avec le patch 4G-4G (qui force des espaces d'adressage séparés pour noyau et programmes utilisateur), normalement ce sont 3 GO maximum par processus, 1 GO réservé au noyau.

Ok apparemment il existe aucun API standard pour ça sous linux... c'est ballot.

hu?

ah, sinon, 128 Mo c'est déja plus raisonnable

GoldenCrystal (./24) :
Ok apparemment il existe aucun API standard pour ça sous linux... c'est ballot.

De quoi tu parles ?

Mon dieu !!!!!
Passes en 64 bits et arrête ces conneries d'un autre age

Effectivement, on n'a pas besoin de ces bidouilles parce qu'on a une version 64 bits viable.

C'est un peu exagéré comme argument... il y a un an linux 64 bits commençait à peine a fonctionner correctement (j'en ai fais les frais donc oublie tout de suite les discours foireux... En fait y'avait que le noyau qui fonctionnait sûr à 100%...), et debian 64 bits n'existait pas (plus...) parce que aucun mainteneur officiel...
Pour le reste moi j'ai un PC 64 bits, toi aussi peut être (ah non tu as windows millenium c'est vrai...), plein de gens aussi, mais là ou on met plus de 4 Go dans une machine c'est sur des serveurs, pas sur la machine de M tout le monde... Et je suis pas certain qu'a l'époque tout le monde ait eu envie de changer quasi intégralement le matériel juste pour augmenter la mémoire accessible alors que c'était déjà le cas en 32 bits...