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

lexa - 21/Фев/2013 15:49

Программирование

Windows

Вот есть у меня 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 смотр

v_s (not verified) - 21/Фев/2013 15:59

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

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

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

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

lexa - 21/Фев/2013 16:04

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

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

понятно

v_s (not verified) - 21/Фев/2013 16:13

понятно

VMMap.

wizzard0 (not verified) - 21/Фев/2013 16:10

VMMap.

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

lexa - 21/Фев/2013 16:28

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

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

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

Вот не знаю. Внутри VS2012 появился клевый дебаггер дедлоков

wizzard0 (not verified) - 21/Фев/2013 16:35

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

Вот у меня получилось vmmap-ом, что - первый большой аллоц

lexa - 21/Фев/2013 16:38

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

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

Можно попробовать пересобрать qtxml. Но вообще ASLR и всяки

wizzard0 (not verified) - 21/Фев/2013 16:45

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

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

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

Ну как бы особой проблемы нет, без rgb-rendering потребности

lexa - 21/Фев/2013 16:57

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

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

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

_iga (not verified) - 23/Фев/2013 03:50

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

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

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