Des objets reste limitée à 2 GO en taille dans le 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).

InformationsquelleAutor Brian Rasmussen | 2009-07-06
  1. 53

    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 la CLR équipe 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.

    • Je suis au courant de toutes les limitations sur 32 bits, mais ce n'est pas vraiment le sujet de ma question. La surprise a été que les choses sont en fait pire sur 64 bits. Je vais jeter un oeil au post de blog. Merci pour le lien.
    • Pas de problème - j'ai juste ajouté que, parce que c'est vraiment pas pire, en 64 bits de 32 bits. La limite théorique est de 1/2 d'objets, mais depuis que vous êtes vraiment limité à un total de 1,4 go d'espace de processus, il n'y a pas moyen de faire un tableau de références de l'objet même près de la moitié de la taille autorisée. (Chaque référence oblige à point à quelque chose, ainsi que la taille de la référence.... si vous vraiment sortir de la pac, la plupart du temps autour de 1/4 go de dollars de références .NET de 32 bits).
    • En réponse à Edit: je crois que vous avez raison. Aussi loin que je peux dire à la limitation a toujours été là et je n'ai pas pu trouver quoi que ce soit indiquant que la limite a été changé. Je peux comprendre pourquoi MS ne peut pas vouloir l'adresse, mais c'est vraiment bizarre que le passage à 64 bits sera réellement le rendement de moins en moins "espace" pour la collection unique de toute façon.
    • Brian: C'est juste un plus (quoique mineur, OMI) inconvénient de 64 bits vs 32 bits. Il existe de nombreuses raisons de ne PAS passer à 64 bits, mais les gens semblent oublier que, pensant que le 64 bits est automatiquement mieux.
    • J'ai lu que les Mono prend en charge 64 bits des tableaux en C# e.g.les tableaux avec plus de 2^32 entrées)
    • Oui, Mono n'a que. Notez que la capacité théorique est là pour tous CLR implémentations (tous les tableaux ont long LongLength de la propriété), mais jusqu'à présent, seuls les Mono effectivement utilisé.
    • Même sur 64 bits avec gcAllowVeryLargeObjects nous sommes limités: "Le nombre maximum d'éléments dans un tableau est UInt32.MaxValue."
    • Oui, mais au moins la valeur personnalisée types peuvent permettre à beaucoup plus de 2 go de tableaux maintenant
    • Cependant, je pense que vous pourriez le faire avec de multiples dimensions - voir msdn.microsoft.com/en-us/library/hh285054%28v=vs.110%29.aspx - "L'indice maximum dans une dimension est"...
    • Je crois que votre chaque mention de gb en ce qui concerne la taille est synonyme de GO, c'est à dire Giga Octets. De mémoire le schéma d'adressage est toujours en termes d'octets, mais je n'ai pas compris votre post en ce qui concerne la taille. Pouvez-vous préciser ou de les rendre compatibles dans le cas où il y a une miss?

    InformationsquelleAutor Reed Copsey
  2. 16

    .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, il doit être activé via le fichier de configuration à l'aide de la gcAllowVeryLargeObjects élément.

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

    • Je n'avais pas remarqué. Merci pour le lien.
    • Encore que 4 GO!? pourquoi ne peuvent-ils pas faire du vrai 64 bits?
    • où voyez-vous de 4 go ?
    • nombre maximum d'éléments dans un tableau est UInt32.MaxValue."
    • k; alors quelle est la taille d'un int[] avec uint.MaxValue éléments?
    • Une taille de la matrice est sizeof(type) * num_elements plus généraux. Dans votre exemple, il serait de 4 * uint.MaxValue ou 17,179,869,180.
    • Si vous êtes limité à 4 go si vous avez besoin d'un byte[]...

    InformationsquelleAutor Alina Popa
  3. 13

    C'est un gros problème dans le champ numérique. Toute personne utilisant le numérique, les bibliothèques de classes dans .NET a leurs matrices stockées sous la forme de tableaux en dessous. C'est donc bibliothèques natives peuvent être appelés à faire de l'arithmétique. La limite de 2 go entrave gravement la taille des matrices possible en 64 bits .NET. Plus ici.

    • Nous avons parlé avec Microsoft au sujet de cette question. Il est peu probable d'être fixée .NET 4.0, mais ils semblaient très réceptifs à la recherche d'une solution. Je pense que nous allons nous retrouver avec de longue tableaux indexés, mais plus probablement une sorte de géant de l'objet blob.
    • Comment fonctionne la performance d'un 65536*65536 tableau de float comparer avec celui de 65536 des tableaux de 65536 flotteurs? La performance de 256 tableaux de 256 flotte sera inférieure à celle de 256*256 tableau, puisque ceux-ci auront une meilleure localité de cache et l'ancien ne sera pas, mais si l'on accède à des lignes d'une matrice qui sont suffisamment localisé à bénéficier de la localité de cache, je pense que l'un, le processeur va être en mesure de cacher l'objet-tableau des références.
    InformationsquelleAutor Trevor Misfeldt