Сколько памяти необходимо смочь выделить?
Еще одно решение
def make_chunks(data, chunk_size):
while data:
chunk, data = data[:chunk_size], data[chunk_size:]
yield chunk
>>> for chunk in make_chunks([1, 2, 3, 4, 5, 6, 7], 2):
... print chunk
...
[1, 2]
[3, 4]
[5, 6]
[7]
>>>
8 ответов
Столько, сколько ОС хочет вам дать. По умолчанию Windows позволяет 32-битному процессу иметь 2 ГБ адресного пространства. И это разделено на несколько частей. Одна область предназначена для стека, другие - для каждого загружаемого исполняемого файла и DLL. Все, что осталось, можно выделить динамически, но нет гарантии, что это будет один большой непрерывный кусок. Это может быть несколько небольших фрагментов по несколько сотен МБ каждый.
Если вы компилируете с флагом LargeAddressAware, 64-разрядная Windows позволит вам использовать все 4 ГБ адресного пространства, что должно немного помочь, но в целом
- не следует предполагать, что доступная память непрерывна. Вы должны иметь возможность работать с несколькими меньшими выделениями, а не с несколькими большими, и
- Вы должны скомпилировать его как 64-битное приложение, если вам нужно много памяти.
в 32-разрядной версии Windows обычный процесс может занимать максимум 2 ГБ, но с переключателем / 3 ГБ он может достигать 3 ГБ (для Windows 2003).
но в В вашем случае я думаю, что вы выделяете непрерывную память, и поэтому произошло исключение.
Во время проекта ElephantsDream организация Blender Foundation с Blender 3D были аналогичные проблемы (правда, на Mac). Не могу включить ссылку, но проблема с выделением памяти google: blender3d, и это будет первый элемент.
Решение включало отображение файлов. Сам не пробовал, но вы можете прочитать об этом здесь: http://msdn.microsoft.com/en-us/library/aa366556 (VS.85) .aspx
Вы можете выделить столько памяти, сколько позволяет ваш файл подкачки - даже без переключателя / 3GB вы можете выделить 4GB памяти без особого труда.
Прочтите эту статью , чтобы получить хороший обзор того, как думать о физической памяти, виртуальной памяти и адресном пространстве (все три вещи разные). Короче говоря, у вас ровно столько же физической памяти, сколько у вас RAM, но ваше приложение вообще не взаимодействует с этой физической памятью - это просто удобное место для хранения данных, которые находятся в вашей виртуальной памяти. Ваша виртуальная память ограничена размером вашего файла подкачки, а объем, который ваше приложение может использовать, ограничен тем, сколько другие приложения используют (хотя вы можете выделить больше, если вы фактически не используете его). Ваше адресное пространство в 32-битном мире составляет 4 ГБ. Из тех, Ядру выделяется 2 ГБ (или 1 ГБ, если вы используете переключатель / 3BG). Из оставшихся 2 ГБ часть будет использована вашим стеком, часть - программой, которую вы в данный момент запускаете (и все библиотеки DLL и т. Д.). Он будет фрагментирован, и вы сможете получить только столько непрерывного пространства - вот где ваше распределение терпит неудачу. Но поскольку это адресное пространство - всего лишь удобный способ доступа к виртуальной памяти, которую вы для себя выделили, можно выделить гораздо больше памяти и по нескольку раз переносить ее фрагменты в свое адресное пространство.
Раймонд Чен имеет пример того, как выделить 4 ГБ памяти и сопоставить ее часть с разделом вашего адресного пространства.
В 32-разрядной Windows максимальный размер выделяемой памяти составляет 16 ТБ и 256 ТБ в 64-разрядной Windows.
И если вы'
Если nBandBytes равен 466 560 000, вы пытаетесь выделить 1,4 ГБ. 32-разрядное приложение обычно имеет доступ только к 2 ГБ памяти (больше, если вы загружаетесь с / 3 ГБ и исполняемый файл помечен как поддерживающий большое адресное пространство). Вам может быть трудно найти такое количество блоков непрерывного адресного пространства для больших блоков памяти.
Если вы хотите выделить гигабайты памяти в 64-битной ОС, используйте 64-битный процесс.
Вы должны иметь возможность выделить в общей сложности около 2 ГБ для каждого процесса. Эта статья (PDF) объясняет детали. Однако вы, вероятно, не сможете получить один непрерывный блок, даже близкий к этому размеру.
Даже если вы распределяете память небольшими порциями, вы не сможете получить необходимую память, особенно если окружающая программа имеет непредсказуемое поведение памяти или если вам нужно работать в разных операционных системах. По моему опыту, объем кучи 32-разрядного процесса ограничивается примерно 1,2 ГБ.
При таком объеме памяти я бы рекомендовал вручную записывать данные на диск. Оберните свои массивы в класс, который управляет памятью и при необходимости записывает во временные файлы.
Sysinternals VMMap is great for investigating virtual address space fragmentation, which is probably limiting how much contiguous memory you can allocate. I recommend setting it to display free space, then sorting by size to find the largest free areas, then sorting by address to see what is separating the largest free areas (probably rebased DLLs, shared memory regions, or other heaps).
Avoiding extremely large contiguous allocations is probably for the best, as others have suggested.
Setting LARGE_ADDRESS_AWARE=YES (as jalf suggested) is good, as long as the libraries that your application depends on are compatible with it. If you do so, you should test your code with the AllocationPreference registry key set to enable top-down virtual address allocation.