39 votes

Des objets uniques encore limités à 2 Go en CLR 4.0?

Je comprends qu'il y a une limite de 2 GO sur un seul cas dans .NET. Je n'ai pas payé beaucoup d'attention que j'ai principalement travaillé sur les OS 32 bits jusqu'à présent. Sur 32 mais il est plus ou moins une limitation artificielle de toute façon. Cependant, j'ai été assez surpris d'apprendre que cette limitation s'applique également sur 64 bits .NET.

Depuis des collections List<T> utiliser un tableau pour stocker les éléments, ce qui signifie qu'une .NET application en cours d'exécution sur 32 bits sera en mesure de tenir deux fois plus beaucoup de type de référence des éléments d'une liste par rapport à la même application en cours d'exécution sur 64 bits. C'est assez surprenant de l'omi.

Personne ne sait si cette limitation est traitée dans le CLR 4.0 (je n'ai pas de 4.0 installation à la main en ce moment).

53voto

Reed Copsey Points 315315

C'est pire que ce que vous êtes à l'espace de processus, lorsque vous travaillez .NET de 32 bits est beaucoup plus petite que la limite théorique. En 32 bits .NET applications, mon expérience est que vous aurez toujours tendance à commencer à sortir de la mémoire des erreurs quelque part autour de 1.2-1.4 go de l'utilisation de la mémoire (certaines personnes disent qu'ils peuvent obtenir à 1,6... mais je n'ai jamais vu ça). Bien sûr, ce n'est pas un problème sur les systèmes 64 bits.

Cela étant dit, un seul tableau 2 go de types de référence, même sur des systèmes 64 bits, est une énorme quantité d'objets. Même avec 8 octets références, vous avez la possibilité d'allouer un tableau de 268,435,456 les références de l'objet - qui peuvent être très grandes (jusqu'à 2 go, plus si ils utilisent des objets imbriqués). C'est plus de mémoire que jamais vraiment être requis par la plupart des applications.

L'un des membres de l' équipe CLR blogué sur ce, avec quelques options pour des moyens de contourner ces limitations. Sur un système 64 bits, de faire quelque chose comme sa BigArray<T> serait une solution viable pour allouer un nombre quelconque d'objets dans un tableau beaucoup plus que les 2 go de l'objet unique limite. P/Invoke peut vous permettre d'allouer les grandes baies ainsi.


Edit: je devrais avoir parlé, ainsi - je ne crois pas que ce comportement a changé du tout .NET 4. Le comportement n'a pas changé depuis le début de l' .NET.


Edit: .NET 4.5 ont maintenant la possibilité de x64 pour autoriser explicitement les objets à être de plus de 2 go par la mise en gcAllowVeryLargeObjects dans l'application.config.

16voto

Alina Popa Points 121

.NET Framework 4.5 permet de créer des tableaux de plus de 2 Go sur les plates-formes 64 bits. Cette fonctionnalité n'est pas activée par défaut, elle doit être activée via le fichier de configuration à l'aide de l'élément gcAllowVeryLargeObjects.

http://msdn.microsoft.com/en-us/library/hh285054(v=vs.110).aspx

13voto

Trevor Misfeldt Points 151

C'est un gros problème dans le domaine numérique. Toute personne utilisant des bibliothèques de classes numériques dans .NET a ses matrices stockées sous forme de tableaux en dessous. C'est ainsi que les bibliothèques natives peuvent être appelées pour effectuer le calcul numérique. La limite de 2 Go entrave sérieusement la taille des matrices possibles dans .NET 64 bits. Plus ici .

  • Trevor Misfeldt

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X