Je sais que dans les systèmes 32 bits, la mémoire la plus importante que nous puissions avoir est de 4 Go (2 ^ 32).
C'est faux; il est parfaitement possible qu'un processeur 32 bits utilise plus de 4 Go de RAM, tout comme un processeur 16 bits peut utiliser plus de 64 Ko de RAM. Rappelez-vous que le 80286 16 bits pouvait adresser 16 Mo par son bus d’adresse 24 bits (à l’époque, on considérait qu’il occupait une énorme quantité de mémoire; le 80286 est devenu disponible en 1982 et l’année 1983 a vu l’introduction du premier disque dur 3.5 " , disposant d’une capacité de stockage de 10 Mo , le IBM PC AT , conçu autour du processeur Intel 80286, était doté d’un minimum de 256 Ko de RAM) et le processeur Intel 8086, datant de 1979, disposait d’un espace adresse de 1 Mio (et fournissait le capacité de calcul du PC IBM 5150 d'originepouvant être mis à niveau avec la même quantité de RAM de 256 Ko, bien au-delà de la limite native d’une adresse 16 bits de 64 Ko). Techniques de recherche telles que l' extension d'adresse physique , la commutation de banque (qui, bien que nécessitant une attention particulière de la part du programmeur, étaient courantes dans les premiers PC et les anciens ordinateurs électroniques en raison de la simplicité de sa mise en œuvre; le Apollo Guidance Computer était une conception à commutation de banque ) et des modèles de mémoire segmentés tels que le modèle de segmentation mémoire x86 .
Le facteur limitant ultime en ce qui concerne la quantité de mémoire pouvant être adressée sans recourir à de telles techniques est la largeur du bus d’adresses natif de la CPU , qui est indépendante de la largeur de mot native de la CPU ou de la résolution en bits, comme il est normalement indiqué . Il serait parfaitement possible de créer un processeur qui fonctionne avec des données en morceaux de 64 bits (ce qui en ferait un processeur de 64 bits) même s’il possède un bus d’adresse de 16 bits; Je ne vois pas de réelle application pour quelque chose comme ça, mais ce n'est pas techniquement une contradiction.
Maintenant, beaucoup de gens ne s’embarrassent pas de ces techniques sur les processeurs 32 bits, car à l’époque où ils étaient courants sur les PC, 4 Gio étaient vraiment tout ce dont vous aviez besoin, et les processeurs 32 bits disposaient généralement de suffisamment de bus d’adresses pour ne c'est une préoccupation; même la capacité réduite 80386SX avait un bus d'adressage utilisable 24 bits , ce qui permet 16 MiB d'espace d'adressage en 1988 lorsque la même année a vu la mise en place d' une installation sur le disque dur de 20 Mo . N'ayant pas à vous préoccuper de la segmentation, PAE et des techniques similaires facilitent grandement la vie du programmeur. Le logiciel serveur 32 bits, cependant, était généralement écrit pour gérer plus de 4 Go de RAM.
Et, bien entendu, les logiciels 16 bits utilisaient régulièrement des fichiers de plus de 65 536 octets. Cela prend un peu de réflexion si vous voulez que votre logiciel fonctionne de manière native avec des fichiers trop volumineux pour tenir dans un bloc de mémoire alloué individuellement, mais ce n'est certainement pas impossible.
Mais je ne suis pas sûr de ce que cela implique en termes de fichiers. Je pense que nous pouvons avoir des fichiers de taille arbitraire dans nos disques durs, non? Beaucoup plus que 4Go.
Non, vous ne pouvez pas avoir des fichiers de taille arbitraire , même s’ils sont limités par l’espace de stockage physique disponible: au niveau logique le plus bas, le système de fichiers limite le stockage des fichiers volumineux, simplement parce qu’il doit pouvoir stocker la taille du fichier. déposer quelque part. La limite exacte varie avec le système de fichiers et parfois avec les paramètres. Avec les systèmes de fichiers modernes tels que NTFS, ext4, etc., les limites sont suffisamment élevées pour qu'il soit peu probable que vous les frappiez avec un seul disque, bien que cela puisse être un problème si vous avez une grande baie de stockage. Par exemple, NTFS (le système de fichiers) prend en charge des fichiers d’une taille maximale de 16 EIB, bien que l’ implémentation NTFS dans Windows soit actuellement limitée (artificiellement). jusqu'à une taille de fichier maximale d'à peine 256 To (augmentée de 16 To par la version de Windows 8 et Windows Server 2012).
16 TiB n'est pas une quantité de stockage excessivement grande; vous pouvez y accéder en exécutant, par exemple, 7 disques de 4 To chacun en RAID-6, ce qui est certainement à la portée financière, même des individus.
La même chose a été faite avec différentes éditions de Windows, limitant artificiellement la quantité de RAM utilisable même si l'architecture sous-jacente en permettait l'utilisation beaucoup plus.
Alors, y at-il des mises en garde dans les systèmes 32 bits et les fichiers volumineux? Je suppose que certains programmes 32 bits ne pourraient pas charger des fichiers de plus de 4 Go ou est-ce que je me trompe?
Cela dépend du logiciel et, dans une moindre mesure, de la manière dont il fonctionne avec ses fichiers de données. Par conséquent, si les mots clés sont certains programmes 32 bits, votre hypothèse est presque certainement correcte. Là encore, certains programmes 64 bits risquent de ne pas bien gérer d’énormes fichiers. Je rencontre cela de temps en temps au travail; Par exemple, Microsoft Word 2010 refusera pour moi de charger tout fichier de plus de 512 Mo, même si ma mémoire est bien plus grande que celle qui n’est disponible que si c’est pour essayer de l’utiliser.
Si le logiciel tente de charger le fichier entier en mémoire en une fois (ce qu'il ne devrait vraiment pas faire) et qu'il n'a pas de limites artificielles, le facteur limitant avec les systèmes d'exploitation actuels sera la taille de la mémoire virtuelle disponible. (Remarque: mémoire virtuelle et échange sont deux choses complètement différentes. Vous devez également tenir compte de la surconsommation de la mémoire .) Par contre, le logiciel ne charge en mémoire qu'une partie du fichier à la fois, à condition que le système d'exploitation lui-même facilités pour accéder à des parties du fichier au-delà de la limite de taille de 32 bits de 4 Go et que le système de fichiers peut traiter la taille du fichier, la taille réelle du fichier ne devrait pratiquement pas être un problème, et si c'est le cas, , c’est probablement un bogue logiciel de l’utilisateur.