Вот есть у меня 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 смотр
>> Потому что сдается мне, что 80Mpix можно и без /3GB смотреть
80мпикс рав я смотрел и даже конвертировал вообще на старом ноуте с пределом памяти в 2Гб физически.
PS. не знаю о том ли я понял.
Конвертации нужно меньше памяти, чем RawDigger-у. RD хранит
Конвертации нужно меньше памяти, чем RawDigger-у.
RD хранит результаты промежуточных шагов обработки, чтобы их быстро показать. Конвертору это не нужно.
понятно
понятно
VMMap.
VMMap.
Ага, клевая штука. Спасибо А вот того же самого, но с раскр
Ага, клевая штука. Спасибо
А вот того же самого, но с раскраской по времени "вот в этот момент строчка N в файле K захотела 200M хипа"?
Понятно, что это библиотека должна быть. Я готов :)
Вот не знаю. Внутри VS2012 появился клевый дебаггер дедлоков
Вот не знаю. Внутри VS2012 появился клевый дебаггер дедлоков (Concurrency Visualizer), может что-то и для памяти есть - но еще не встречал.
Вот у меня получилось vmmap-ом, что - первый большой аллоц
Вот у меня получилось vmmap-ом, что
- первый большой аллоцированный блок - начинается по адресу примерно 256M от начала
- а по адресу 607d0000 (1.6Gb) уже живет DLL-ка (конкретно, QtXml4d )
Т.е. всего сплошного адресного пространства ~1.35G. Небогато.
В /3GB варианте - помимо этих 1.3 есть еще 2Gb начиная с 0x7fff0000
Можно попробовать пересобрать qtxml. Но вообще ASLR и всяки
Можно попробовать пересобрать qtxml.
Но вообще ASLR и всякие проги, вгружающие DLL в чужие процессы, не дают ни разу гарантий больших последовательных кусков :/
(TeamViewer, плагины всяких антивирусов, писалки видео, плюс если вы используете common shell dialogs, то к вам еще вгружается всё, что у юзера в шелл экстеншенах наставлено - Dropbox, Tortoise*, etc)
Ну как бы особой проблемы нет, без rgb-rendering потребности
Ну как бы особой проблемы нет, без rgb-rendering потребности в памяти падают в несколько раз т.е. даже с 80-мпикс жить можно
Я просто пытался понять, отчего обещают 2гига а дают 1.1
> Можно попробовать пересобрать qtxml. Достаточно обработат
> Можно попробовать пересобрать qtxml.
Достаточно обработать его rebase.exe (editbin.exe /rebase).
Это если Тутубалину действительно нужна непрерывная память, что странно (обычно большая непрерывная область памяти требуется лишь для всяких shared memory объектов).
У меня очень большие malloc-и (для рассматриваемых 80Mpix -
У меня очень большие malloc-и (для рассматриваемых 80Mpix - 2x160, 2x240 и 640M).
В фрагментированной памяти есть большой шанс не аллоцировать, даже если формально памяти достаточно.
не знаю как в винде, а в юнихах маллок нынче аллоцирует памя
не знаю как в винде, а в юнихах маллок нынче аллоцирует память не в data сегменте, а за ним
VMMap http://technet.microsof
VMMap
http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx
Напрягая памать, что делал когда-то в винде... Была тулза, н
Напрягая памать, что делал когда-то в винде...
Была тулза, называлась как-то "working set tool". Можно попробовать туда копнуть
На всякий случай: для 32б может сказаться полезным PAE
На всякий случай: для 32б может сказаться полезным PAE
Вот тут: https://www.exelisvis.com/Support/HelpArticleDetail
Вот тут:
https://www.exelisvis.com/Support/HelpArticleDetail/ArticleId/3346/Overc...
абзац
Forced Memory Fragmentation In window-based Windows Applications
Ну и ещё пару ссылок: http://bugslasher.net/2011/01/15/memor
Ну и ещё пару ссылок:
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 (байер, байер
Ну у меня реально большие куски. Типа 2x 150M (байер, байер после вычитания черного), 230M (RGB render), 320M (битмеп), 640M - процессинг.
В 1.2G места это сложно разместить.
sysinternals vmmap http://technet.microsoft.com/en-us/sysint
sysinternals vmmap
http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx
В свое время пришлось специально приседать в некоторых алгоритмах, чтобы куски выделялись поменьше. Аналогично все заканчивалось недалеко за 1 Gb.
Post new comment