Хотелось бы создать ветку, где можно будет детально обсудить вопросы работы с оперативной и виртуальной памятью!  На форме есть кое-какие данные на эту тему, но всё разбросано и очень мало! Вот для начала пример, у меня есть 3 массива, два массива размером Х (типа double и byte), и один массив размером x/100(тип byte):    



Когда X=16.000.000, то работает нормально, но если я пытаюсь загрузить массив X=76.000.000, то на double массиве оно выкидывает ошибку - OutOfMemoryException! 

Параметры моей системы таковы Windows XP 32 разряда, 3ГГб оперативной памяти(диск С) и 4 ГГб виртуальной(диск D). 

А теперь вопрос, как правильно работать с памятью, загружать большие массивы, выделять самостоятельно память, можно ли вручную из кода работать с виртуальной памятью (увеличивать, уменьщать)? И как работать с массивами, если в них будет X=1.000.000.000?  

Буду рад услышать все возможные варианты и скидывайте. пожалуйста, сюда всю литературу на эту тему! 

не понял вот это:

при чем диск С к оперативной памяти?

проверил у себя, создал массив double, с x=76.000.000, забил его значениями, все работает, ничего не выпадает, покажи свой код, которые выдает ошибки.

“Недостаточно Памяти” не относится к физической памяти
Цитата: Операционная система даёт процессу 4 Гб «виртуального адресного пространства» - более миллиона страниц, которые могут быть адресованы 32хразрядным указателем.


Копать в сторону 64битных: ОСи и .NET
Цитата: Теперь должно быть уже понятно, почему ошибки «недостаточно памяти» обычно не имеют никакого отношения к тому, сколько у вас физической памяти, или даже сколько у вас памяти доступно. Почти всегда дело в адресном пространстве, которое относительно невелико в 32хбитной Windows, и легко фрагментируется.

И, конечно, многие из этих проблем фактически исчезают на 64хбитной Windows, где адресное пространство в миллиарды раз больше, и, следовательно, его значительно труднее фрагментировать.

Вот информация, которую я накопал: 

http://blogs.msdn.com/ruericlippert/archiv...08/9723963.aspx
http://msdn.microsoft.com/en-us/library/ms683219(VS.85).aspx
http://forum.vingrad.ru/forum/topic-259153/unread-1.html
http://forum.vingrad.ru/forum/topic-268273/unread-1.html
http://msdn.microsoft.com/ru-ru/library/f90ybzkh.aspx
http://blogs.msdn.com/oldnewthing/archive/.../22/218527.aspx

Добавлено @ 16:00
ОЙ, про оперативную я сказал ерудну, конечно никакого диска С!

2 Экскалупатор


Это зависит от количества запущенных процессов, как я это понимаю, код большой, поэтому даже если вырвать часть из него, то скорее всего это не даст ответа на Ваш вопрос, однако, я думаю, что если сделать просто массив без ничего, и при этом, если будет запущено минимальное количество программ, то он сработает, но это не решает проблемы! 

2 Skynin 
 
 Насчёт 64 разрядов полностью согласен, однако, надо решить задачу имеющимися средствами! 

При этом как мне видится, даже если удастся решить данную задачу, то быстродействие сильно упадёт. 

Спасибо Всем, кто высказался, рад буду слышать новые мысли и идеи! 

Это сообщение отредактировал(а) myendlessness - 19.8.2009, 16:10

16млн объектов byte с точки зрения памяти - не так уж и много, но сама цифра наводит на мысли о неправильном пути
неплохо было бы задачу увидеть (только именно саму задачу, а не твой способ её решения)

myendlessness, массивы создаются один раз? Или содаются и убиваются несколько несколько раз, с разными размерами (как в примере)? Действительно ли нужны массивы такого размера? Данные в массивах обрабатываются последовательно? Данные в них загружаются с/сохраняются на диск?

myendlessness, может стоит рассмотреть хранение данных где то в другом месте? в файле например(или еще где) и читать их блоками, это конечно сильно скажется на производительности, но наверное поможет решить задачу имеющимися средствами.

з.ы. можно ли взглянуть на условие? уж очень интересно для чего это все...

О каких условиях идёт речь? о поставленной задаче, которую надо решить?  на данном этапе моя задача понять как наиболее эффективно работать с такими массивами! 

Про разбиение информации на блоки об этом я думал, но это не имеет смысла, так как производительность значительно упадёт. В общем-то это решение задачи в лоб. Итого, на данный момент мы имеем два решения:

1) Работать на 64 разрядных компьютерах
2) Разбивать на блоки информацию

Какие будут ещё варианты? 
   

myendlessness, "наиболее эффективно" не бывает. Бывает "наиболее эффективно для конкретной задачи". Вдруг тебе там вообще массивы не нужны, хватит потоков. Или нужны именно массивы (сомневаюсь), но ты их выделяешь постоянно, чуть разного размера, и получаешь дикую фрагментацию Large objects heap. Важно не что ты выделяешь, а для каких целей, и как именно. А выделить массив ради выделения большого массива - это не цель.

2 PashaPash 

Сейчас попытаюсь объяснить для чего я делаю! У меня есть Файл формата TIF (грубо говоря большие фотографии (до 5Гб может быть одна)) я его читаю: 
 

И перегоняю в Массив,затем разбиваю ещё на два массива, в одном храняться данные о рисунке, в другом, пиксели! После этого у меня есть библиотека, написанная на С, в которую я передаю эти массивы, а она сжимает (кодирует) эти данные и возвращает мне в сжатом виде. Этот сжатый массив я записываю в Txt файл. Ну если объяснять просто, то механизм такой! 

Сейчас увеличил файл подкачки, отключил пару программ и получилось закодировать X=72.000.000, но думаю, что даже 100.000.000 уже не потянет, да и декодировать уже ресурсов не хватает, выпрыгивает OutOfMemoryException

Добавлено через 9 минут и 7 секунд
Хотел уточнить один существенный момент в библиотеку я передаю не массивы, а ссылки на эти массивы!  

с чего ты взял, что разбивка на фрагменты увеличит время работы?
у тебя вижу:
- чтение по байту: n * ReadByte()
- кодировка (внутри скорее всего - та же побайтовая или почти побайтовая обработка): n * ProcessByte() 
в результате имеем n*2 операций, т.е. с каждым байтом производятся 2 действия, а, стало быть, по большому счёту конкретная последовательность действий не так важна
понятно, что на Interop-операции (вызовы сишной библиотеки) будут огромные накладные расходы, если по байту вызывать, но если компрессить, скажем, по мегабайту, то оверхэды скорее всего будут не заметны

2 mihryak

     Я предположил, что это увеличит время работы! Как я Вас понимаю Вы предлагаете сделать цикл, в котором исходный файл будет обрабатываться частями, например по Мегабайту, то есть - загрузил, сжал, записал и так пока весь файл не обработается?  Я Вас правильно понял? 

Конечно, чтобы окончательно определить будет ли это значительно увеличивать время работы, надо попробовать сделать такой вариант обработки.  

 И ещё вопрос по этой теме, вот у меня файл размером в 16Мб сжимается около 35 сек, в RAR это происходит значительно быстрее в чём может быть причина, кроме самого алгоритма сжатия? Может быть архиватор RAR написан на ассемблере или там проделана хорошая работа по распределению памяти? Или это у меня руки растут из  ... В чём может быть причина? 

правильно

про скорость рара - в двух первых причинах не сомневайся, рару уже более десятка лет, там всё вылизано до блеска
смирись с тем, что обогнать (или хотя бы сравняться) при сопоставимом качестве сжатия тебе его скорее всего не удастся

и определись ещё с тем, что именно ты сравниваешь с раром - только компрессию, выполняемую сишной библиотекой, или компрессию + твоё собственное чтение и обработку tiff'а

Сравниваю компрессию! Вот файл в 1 Мб сжимает с той же скоростью, что и РАР, а вот когда речь идёт о файлах выше 5-10Мб, то уже видно значительное различие! Значит получается, что если хочу добиться быстродействия на больших файлах, то единственный путь это писать на ассемблере, да ещё и с памятью нужно будет думать как работать, что бы было оптимально. Итого получается задача очень непростая? 

Вот в этом:

16 мильенов раз. Накладные расходы огромны. Боюсь даже предположить, что происходит внутри этого ReadByte  Посмотри в рефлекторе реализацию операции GetPixel у битмапа - может запросто отбить охоту пользоваться "простыми" решениями.

И ассемблер - тоже не волшебная палочка. Все, что он помогает сделать - снизить эти самые накладные расходы, но неудачное решение точно также убъет производительность.