você pode alocar um grande pedaço único de memória (> 4GB) em C ou C ++?

Question

Com grandes quantidades de RAM estes dias eu estava pensando, é possível alocar um único pedaço de memória que é maior do que 4 GB? Ou será que eu preciso alocar um monte de pedaços menores e comutação alça entre eles?

Por que ??? Eu estou trabalhando em processamento de alguns dados openstreetmap XML e esses arquivos são enormes. Atualmente estou streaming desde que eu não posso carregá-los todos em um pedaço, mas eu só fiquei curioso sobre os limites máximos de malloc ou novo.

Answer 1

Resposta curta: Não é provável

Para que isso funcione, você absolutamente faria Have para usar um processador de 64-bit. Em segundo lugar, seria dependem do suporte do sistema operacional para alocar mais de 4G de memória RAM para um único processo.

Em teoria, seria possível, mas você teria que ler a documentação para o alocador de memória. Você também seria mais suscetível a problemas de fragmentação de memória.

Há boas informações sobre o Windows gerenciamento de memória .

Answer 2

Uma cartilha sobre memória physcal e virtual layouts

Você precisaria de uma CPU de 64 bits e O / S construção e memória quase certamente o suficiente para evitar debatendo o seu conjunto de trabalho. Um pouco de background:

Uma máquina de 32 bits (de um modo geral) tem registos que podem armazenar uma de 2 ^ 32 (4294967296) valores únicos. Isto significa que um ponteiro de 32 bits pode enfrentar qualquer um dos 2 ^ 32 posições de memória únicas, que é onde o limite de 4 GB magia vem.

Alguns sistemas de 32 bits, como o sparcv8 ou Xeon têm de MMU que puxar um truque para permitir mais memória física. Isso permite que vários processos para assumir memória totalizando mais de 4 GB no total, mas cada processo está limitado a seu próprio espaço de endereço virtual de 32 bits. Para um único processo olhando para um espaço de endereços virtuais, apenas 2 ^ 32 locais físicos distintos pode ser mapeado por um apontador de 32 bits.

Eu não vou entrar em detalhes, mas Esta apresentação (aviso: powerpoint) descreve como isso funciona. Alguns sistemas operacionais têm instalações (tais como aqueles descritos Aqui - graças a FP acima) para manipular a MMU e trocar diferentes locais físicos para o espaço de endereço virtual sob controle de nível de usuário

.

O sistema operacional e memória mapeada I / O vai ocupar parte do espaço de endereço virtual, de modo que nem todos que 4GB é necessariamente disponível para o processo. Como exemplo, os padrões do Windows para tomar 2GB de presente, mas pode ser definido apenas para tomar 1GB se o parâmetro / 3G é invocado na inicialização. Isso significa que um único processo em uma arquitetura desse tipo de 32 bits só pode construir uma estrutura de dados contíguo de pouco menos de 4 GB na memória.

Isto significa que você teria que usar explicitamente a PAE instalações no Windows ou recursos equivalentes no Linux para trocar manualmente nas sobreposições. Isso não é necessariamente tão difícil, mas vai demorar algum tempo para começar a trabalhar.

Como alternativa, você pode obter uma caixa de 64-bit com muita memória e esses problemas mais ou menos ir embora. Uma arquitectura de 64 bits com 64 ponteiros bit pode construir uma estrutura de dados contíguo com até 2 ^ 64 (18,446,744,073,709,551,616) endereços únicos, pelo menos em teoria. Isso permite que estruturas de dados contíguo maiores para ser construído e gerido.

Answer 3

A vantagem de arquivos de memória mapeada é que você pode abrir um arquivo muito maior do que 4Gb (quase infinito em NTFS!) E ter várias janelas de memória <4Gb para ele.
É muito mais eficiente do que abrir um arquivo e lê-lo na memória, na maioria dos sistemas operacionais que utiliza o suporte embutido paginação.

Answer 4

Isto não deve ser um problema com um sistema operacional de 64 bits (e uma máquina que tem essa quantidade de memória).

Se malloc não pode lidar, em seguida, o sistema operacional irá certamente proporcionar APIs que permitem alocar memória diretamente. No Windows você pode usar o VirtualAlloc API.

Answer 5

que depende de qual compilador C você está usando, e em que plataforma (é claro), mas não há nenhuma razão fundamental pela qual você não pode alocar o maior bloco de memória contígua disponível - que pode ser menos do que você precisa. E, claro, você pode ter que estar usando um sistema de 64 bits para o endereço do que muito RAM ...

Malloc para a história e detalhes

HeapMax em alloc.h para obter o maior tamanho do bloco disponível

Answer 6

Você considerou usando arquivos de memória mapeada? Desde que você é o carregamento em arquivos realmente enormes, parece que este pode ser o melhor caminho a percorrer.

Answer 7

Depende se o sistema operacional irá dar-lhe espaço de endereço virtual que permite abordar a memória acima de 4GB e se os suportes do compilador alocando-lo usando novos / malloc.

Para 32-bit Windows você não será capaz de obter pedaço único maior do que 4 GB, como o tamanho do ponteiro é de 32 bits, limitando assim o seu espaço de endereço virtual para 4GB. (Você pode usar endereço físico extensão para obter mais do que 4GB de memória; no entanto, eu acredito que você tem para mapear a memória no espaço virtualaddress de 4GB yourself)

Para 64-bit do Windows, o VC ++ suporte de compilador ponteiros de 64 bits com limite teórico do espaço de endereço virtual para 8TB. ??

Eu suspeito que o mesmo se aplica para Linux / gcc -. 32-bit não permite que você, enquanto que de 64 bits permite que você

Answer 8

Como Rob apontou, VirtualAlloc para Windows é uma boa opção para isso, como é um mapeamento de arquivo anonymouse. No entanto, especificamente no que diz respeito à sua pergunta, a resposta à pergunta "se C ou C ++" pode alocar, a resposta é NÃO ESTE não é suportado mesmo em Win7 RC 64

Na especificação PE / COFF para arquivos EXE, o campo que especifica a reserva MONTÃO e MONTÃO cometer, é uma quantidade de 32 bits. Isto está em linha com as limitações de tamanho físico do implmentation pilha atual nas janelas CRT, que é pouco menos de 4 GB. Assim, não há nenhuma maneira de alocar mais de 4 GB de C / C ++ (technicall as instalações de apoio OS de CreateFileMapping e VirtualAlloc / VirtualAllocNuma etc ... não são C ou C ++).

Além disso, BE CONSCIENTE que existem x86 subjacente ou amd64 construção da ABI conhecida como a página da tabela de. Este irá na verdade fazer o que você está concerened sobre, alocando pedaços menores para seu pedido maior, mesmo que isso seja happining na memória do kernel, há um efeito sobre o sistema como um todo, essas tabelas são finitos.

Se você está alocando memória em tais purportions Grandious, você faria bem para alocar com base na granularidade de alocação (que impõe VirtualAlloc) e também para identificar das bandeiras ou métodos opcionais para permitir que as páginas maiores.

páginas de 4KB foram o tamanho da página inicial para o 386, subsaquently o pentium acrescentou 4MB. Hoje, a AMD64 (Guia de otimização de software para AMD 10h família Processors) tem uma página de tamanho máximo de entrada da tabela de 1GB. Isso significa é para o seu caso aqui, vamos dizer que você acabou de fazer 4GB, seria necessário apenas 4 entradas exclusivas no diretório do kernel para localizar \ Atribuir e permissão memória do seu processo.

A Microsoft também lançou este manual do que articula alguns dos pontos mais delicados da memória do aplicativo e sua utilização para a plataforma Vista / 2008 e mais recentes.

Conteúdo

Introdução. 4

Sobre o Gerenciador de 4 Memória

Espaço de endereço virtual. 5

Alocação dinâmica de Kernel Virtual Address Space. 5

Detalhes para x86 arquiteturas. 6

Detalhes para arquiteturas de 64 bits. 7

Kernel-Mode Pilha de salto no x86 Arquiteturas. 7

Use de excesso de memória Pool. 8

Segurança: Address Space Layout Randomization. 9

Efeito do ASLR em Load Image Endereços. 9

Benefícios da ASLR .. 11

Como criar dinamicamente com base Imagens. 11

I / O de largura de banda. 11

Microsoft SuperFetch. 12

Gravações página de arquivo. 12

Coordenação da Memória Manager e Gerenciador de cache 13

Prefetch-Style Clustering. 14

Grande Gerenciamento de Arquivos 15

Hibernate e Standby. 16

Avançado Modelo de Vídeo 16

Suporte NUMA 17

Alocação de recursos. 17

Padrão Node e Affinity. 18

Interrupção Affinity. 19

NUMA-Aware Funções do sistema para Formulários. 19

NUMA-Aware Funções do sistema para Drivers. 19

Paginação. 20

Escalabilidade. 20

Eficiência e Paralelismo .. 20

Número de página-Frame e PFN banco de dados. 20

Páginas grandes. 21

-Cache Alinhado Piscina Allocation. 21

Máquinas virtuais. 22

Balanceamento de carga. 22

Otimizações adicionais. 23

Integridade do sistema. 23

Diagnóstico de erros de hardware. 23

Código Integridade e Assinatura de driver. 24

A preservação de dados durante verificações de erros. 24

O que você deveria fazer. 24

Para os fabricantes de hardware. 24

Para desenvolvedores de driver. 24

Para desenvolvedores de aplicativos. 25

Para administradores de sistema. 25

Recursos. 25

Answer 9

Se size_t é maior do que 32 bits em seu sistema, você cancelou o primeiro obstáculo. Mas a padrões C ++ C e não são responsáveis ??por determinar se alguma chamada específica para malloc novo ou tem sucesso (exceto malloc com um 0 tamanho). Isso depende inteiramente do OS eo estado atual da pilha.

Answer 10

Como todo mundo disse, recebendo uma máquina de 64 bits é o caminho a percorrer. Mas mesmo em uma máquina de 32 bits da Intel, você pode enfrentar maior do que 4GB áreas de memória, se seu sistema operacional e seu apoio CPU PAE . Infelizmente, 32bit WinXP não faz isso (faz 32 bits Vista?). Linux permite que você faça isso por padrão, mas você será limitado a áreas de 4GB, mesmo com mmap () desde ponteiros ainda 32bit são.

O que você deve fazer, porém, é deixar o sistema operacional cuidar do gerenciamento de memória para você. Entre em um ambiente que pode lidar com tanta RAM, em seguida, ler o arquivo XML (s) no (a) estrutura de dados (s), e deixá-lo alocar o espaço para você. Então operar na estrutura de dados na memória, em vez de operar no próprio arquivo XML.

Mesmo em sistemas de 64 bits, porém, você não vai ter um monte de controle sobre quais partes de seu programa realmente sentar-se na RAM, em cache, ou são paginada para disco, pelo menos na maioria dos casos, uma vez que o sistema operacional e o MMU lidar com isso eles mesmos.