Q: /3GB switch и карта памяти

Вот есть у меня RawDigger в его 32-битной виндовой ипостаси.

И есть одна и та же виндовая машина, Win7-64 бита.

Линкую с поддержкой/без поддержки /3GB (/LARGEADDRESSAWARE у линкера) и скармливаю один и тот же файл (80-мегапиксельный с задника). На 64-битной винде программе с поддержкой /3GB дадут 4GB, а без такой поддержки - 2Gb.

Дальше начинаю собирать и так и сяк и вижу, что вариант без поддержки 3GB получает от системы по рогам когда потребление памяти у него (Peak Working Set по таск-менеджеру/процесс-эксплореру) вовсе не 2Gb, а ~1.1. А вариант с поддержкой - дорастает до 1.2Gb (многовато, да, но примерно столько и расходуется на всякие глупости, чтобы при смене настроек не перечитывать файл).

Вопрос: а чем-то можно в винде посмотреть "использованное адресное пространство"? Ну то есть я догадываюсь, что ~800M пропали по причине фрагментации, а как-то можно мэпу хипа глянуть?

Может есть какой-то правильный маллок, которому можно пометить аллоцированное (именами, или по номерам строк в файле), а он потом карту нарисует?

Потому что сдается мне, что 80Mpix можно и без /3GB смотреть, надо только аллокации в правильном порядке делать.

Comments

>> Потому что сдается мне, что 80Mpix можно и без /3GB смотреть

80мпикс рав я смотрел и даже конвертировал вообще на старом ноуте с пределом памяти в 2Гб физически.

PS. не знаю о том ли я понял.

Конвертации нужно меньше памяти, чем RawDigger-у.

RD хранит результаты промежуточных шагов обработки, чтобы их быстро показать. Конвертору это не нужно.

понятно

VMMap.

Ага, клевая штука. Спасибо

А вот того же самого, но с раскраской по времени "вот в этот момент строчка N в файле K захотела 200M хипа"?

Понятно, что это библиотека должна быть. Я готов :)

Вот не знаю. Внутри VS2012 появился клевый дебаггер дедлоков (Concurrency Visualizer), может что-то и для памяти есть - но еще не встречал.

Вот у меня получилось vmmap-ом, что
- первый большой аллоцированный блок - начинается по адресу примерно 256M от начала
- а по адресу 607d0000 (1.6Gb) уже живет DLL-ка (конкретно, QtXml4d )
Т.е. всего сплошного адресного пространства ~1.35G. Небогато.

В /3GB варианте - помимо этих 1.3 есть еще 2Gb начиная с 0x7fff0000

Можно попробовать пересобрать qtxml.

Но вообще ASLR и всякие проги, вгружающие DLL в чужие процессы, не дают ни разу гарантий больших последовательных кусков :/

(TeamViewer, плагины всяких антивирусов, писалки видео, плюс если вы используете common shell dialogs, то к вам еще вгружается всё, что у юзера в шелл экстеншенах наставлено - Dropbox, Tortoise*, etc)

Ну как бы особой проблемы нет, без rgb-rendering потребности в памяти падают в несколько раз т.е. даже с 80-мпикс жить можно

Я просто пытался понять, отчего обещают 2гига а дают 1.1

> Можно попробовать пересобрать qtxml.

Достаточно обработать его rebase.exe (editbin.exe /rebase).

Это если Тутубалину действительно нужна непрерывная память, что странно (обычно большая непрерывная область памяти требуется лишь для всяких shared memory объектов).

У меня очень большие malloc-и (для рассматриваемых 80Mpix - 2x160, 2x240 и 640M).

В фрагментированной памяти есть большой шанс не аллоцировать, даже если формально памяти достаточно.

не знаю как в винде, а в юнихах маллок нынче аллоцирует память не в data сегменте, а за ним

Напрягая памать, что делал когда-то в винде...
Была тулза, называлась как-то "working set tool". Можно попробовать туда копнуть

На всякий случай: для 32б может сказаться полезным PAE

Вот тут:
https://www.exelisvis.com/Support/HelpArticleDetail/ArticleId/3346/Overc...
абзац
Forced Memory Fragmentation In window-based Windows Applications

Ну и ещё пару ссылок:
http://bugslasher.net/2011/01/15/memory-exhaustion-even-if-a-large-enoug...
оттуда
http://msdn.microsoft.com/en-us/library/aa366750%28VS.85%29.aspx
и http://i-web.i.u-tokyo.ac.jp/edu/training/ss/lecture/new-documents/Lectu...
Но получается, что на семёрке всё должно работать изначально.
Надо копать.

Ну у меня реально большие куски. Типа 2x 150M (байер, байер после вычитания черного), 230M (RGB render), 320M (битмеп), 640M - процессинг.

В 1.2G места это сложно разместить.

sysinternals vmmap
http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx

В свое время пришлось специально приседать в некоторых алгоритмах, чтобы куски выделялись поменьше. Аналогично все заканчивалось недалеко за 1 Gb.

Add new comment