Здравствуйте, newCL, Вы писали:

CL>Какого лешего (пусть будет леший) новая б -го мерзкая (тоже неплохой эффемизм на букву б) аська (да покарает аллах ее создателей до 4 ее колена) жрет 100 (!) метров памяти. Да вы не ослышались джентльмены, 100! Какого хугла хром жрет 100 метров при 2 открытых вкладках (почта и новости).

Извини, я чуть заземлю твой пафос. Вопрос: о какой именно памяти идёт речь?

Я тут недавно разбирался с чудовищным потреблением "памяти" своей программой. Например, при старте она, согласно показаниям системных средств, "потребляет" около 2.5GB и дальше не сокращается. Казалось бы, страшная цифра. Но вот что оказалось:
1) На каждый тред по умолчанию аллоцируется 8MB адресов в пространстве процесса.
2) glibc malloc аллоцирует по умолчанию по 8 64-мегабайтных "арен" на каждое ядро среды выполнения, хотя делает это своеобразно (вначале — по одной арене на тред).
Обе этих аллокации просто отводят адресный диапазон, но не коммитят.

Когда мы начали считать раздельно три цифры
* объём аллоцированной хоть под что-то виртуальной памяти
* суммарный объём грязных страниц
* суммарный объём резидентных страниц
то все эти страшные цифры потребления остались только в первом из них, и измеренеие плоезных цифр (для нас это в первую очередь sum_dirty) свежезапущенного процесса вместо ~2.5GB стало реально показывать 30 MB — это уже для данной программы вполне нормально.

Это я к тому, что рассказывая про страшные цифры, каждый должен знать, что именно эта цифра отражает. Если это объём виртуальной памяти процесса, то это вообще ничего не значит. Ты вспомнил хром? Мой текущий хром (на дебиане) имеет 310M виртуалки, 47MB резидентной памяти, но только 30MB грязных страниц.

[...]

CL> Но когда сопляк, который только-только памперсы снял и PHP свое подтер, выплюнув соску верещит -- "это велосипеды, это байтодрочерство, я не буду этим заниматься, есть более высокоуровневые вещи" мне хочется снять ремень и надавать по той абстракции, от которой отнаследовались мозги в его маленькой головке. А почему? А потому что пока ты (дада, именно ты!) не поежался года 3-4 с байтоложеством, не поэкономил битики, твоя жаба экономии не квакает на слишком большие буффера, то сиди и байтоложь! И не дай бог тебе, сопле очкастой, заикнуться про преждевременную оптимизацию и выскоуровневые абстракции, если ты не хочешь чтобы тебе оторвали твою писсимизацию и затолкали по самые низкие уровни твоей темной абстракции.

Какой слог. Даже жалко, что автор тут не присутствует.
Но всё-таки: что именно он мерял?

Здравствуйте, мыщъх, Вы писали:

М>Run-Time Type Information -- тип в райнтайме. на стадии компиляции о типе ничего не известно. как описать прототип в хидере, если тип динамический?

если о типе во время компиляции ничего не известно, то RTTI бесполезен (не нужен).
нужно знать базовый класс и уметь работать с объектом базового класса.

Здравствуйте, мыщъх, Вы писали:

М>Run-Time Type Information -- тип в райнтайме. на стадии компиляции о типе ничего не известно. как описать прототип в хидере, если тип динамический?

Динамический тип в С? О чем ты?

М>да и динамическая линковска с тем же dll -- никогда не знаешь какие там функции есть

Все функции в dll описываются в хидере.

Здравствуйте, Eugeny__, Вы писали:

E__>Легко.

Ну расскажи, как это сделать в один проход.

E__>То есть, есть инструкция вызова метода а класса Б, количество и тип передаваемых параметров известны, тип возвращаемого значения тоже.

Откуда они известны, если у тебя ровно один проход?

НС>>Да при чем тут рантайм? Статически типизированный компилятор не может работать без сигнатуры в принципе, неважно что там будет в рантайме. Скомпилировать неизвестно какой вызов метода он не способен. А вот С# 4 способен, если это динамик, но это уже совсем другой разговор.

E__>Способен, еще и как.

Нет.

E__> Технически — не проблема.

Технически — ради бога. Но де факто компилятор джавы понимает только статически типизированный код, динамиков там нет.

Здравствуйте, netch80, Вы писали:

N>Это я к тому, что рассказывая про страшные цифры, каждый должен знать, что именно эта цифра отражает. Если это объём виртуальной памяти процесса, то это вообще ничего не значит.

Не значит только пока ее хватает. А потом начинает значит со страшной силой. Но я тебе больше скажу — объем даже реально используемой физической памяти тоже нифига не значит, пока ее хватает.

PD>Да, конечно. Да их и не сложно получить совсем. Мой недавний проект (конвертировал с Delphi на С++). Совсем небольшой, 150 Кб исходников. Во время компиляции cl.exe (причем в режиме Debug, так что об оптимизации речи нет) Task Manager показывает Working Set от 15 до 25 Мб.

PD>>> Для С++ почему ? Он вообще не менялся 10 лет
НС>>Язык потому что сложнее.
PD>Сложнее, чем Borland C++ 5.5 ? C++ с тех пор и вплоть до VS2008 включительно вообще не менялся. А BC5.5 работал на машине с 32 Мб памяти.

Оставлю, например, это здесь:
http://en.wikipedia.org/wiki/Compiler_optimization
http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860
http://www.cs.princeton.edu/courses/archive/spr03/cs320/notes/loops.pdf

Но без шансов на понимание.

Помнится, еще в конце 90-х начале 00-х для получения максимальной производительности (например в играх) рекомендовалось делать ассемблерные вставки. Уже где-то с 2003-го рекомендации поменялись на «не заниматься такой фигней, сложно тягаться с компилятором по эффективности генерируемого кода».

Можно было бы, например, посмотреть описание оптимизаций, доступных в GCC, компиляторах Intel'я или Microsoft'а. Но зачем? Это же все магия, доступная в виде гномиков, которые позволят это все делать быстро и незаметно — ну как в Паскале, в пределах 1 мегабайта!

Здравствуйте, Mamut, Вы писали:

PD>>Да, конечно. Да их и не сложно получить совсем. Мой недавний проект (конвертировал с Delphi на С++). Совсем небольшой, 150 Кб исходников. Во время компиляции cl.exe (причем в режиме Debug, так что об оптимизации речи нет) Task Manager показывает Working Set от 15 до 25 Мб.

PD>>>> Для С++ почему ? Он вообще не менялся 10 лет
НС>>>Язык потому что сложнее.
PD>>Сложнее, чем Borland C++ 5.5 ? C++ с тех пор и вплоть до VS2008 включительно вообще не менялся. А BC5.5 работал на машине с 32 Мб памяти.

M>Оставлю, например, это здесь:
M>http://en.wikipedia.org/wiki/Compiler_optimization
M>http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860
M>http://www.cs.princeton.edu/courses/archive/spr03/cs320/notes/loops.pdf

M>Но без шансов на понимание.

M>Помнится, еще в конце 90-х начале 00-х для получения максимальной производительности (например в играх) рекомендовалось делать ассемблерные вставки. Уже где-то с 2003-го рекомендации поменялись на «не заниматься такой фигней, сложно тягаться с компилятором по эффективности генерируемого кода».

M>Можно было бы, например, посмотреть описание оптимизаций, доступных в GCC, компиляторах Intel'я или Microsoft'а. Но зачем? Это же все магия, доступная в виде гномиков, которые позволят это все делать быстро и незаметно — ну как в Паскале, в пределах 1 мегабайта!

Совершенно верно, без всяких шансов на понимание, потому что, видимо, ты уже разучился понимать русский язык. Прочти внимательно еще раз, я сейчас для тебя специально выделил. Впрочем,вряд ли поможет.

Здравствуйте, newCL, Вы писали:

CL>Здравствуйте, Pavel Dvorkin, Вы писали:

CL>а в том проекте на делфе, который вы конвертировали, использовался делфячий RTTI?
CL>металкассы?

Эти были и доставили мне хлопоты. Остальных тут не было. Это был просто расчетный проект + GUI, который, к счастью перевести не требовалось, а если бы требовалось, то я, конечно, просто написал бы его сам.

CL>case в записях?

Или я что-то не понял, но ИМХО это добро было еще в TurboPascal.

CL>директива absolute?

Может, я опять не понял, но описание переменной с absolute было еще опять же в TurboPascal. Мы таким образом к видеобуферу добирались в MS-DOS

var
VideoBuffer: Pointer absolute $b800:$0000; // пишу по памяти, так что сорри, если не совсем так

Кроме того, в 1999 году под Delphi 5 я участвовал в проекте, где были (мы их сами использовали)

метаклассы
виртуальные конструкторы

Насчет "делфячая диспетчеризация сообщений" — не в курсе, о чем речь идет. Сообщения Windows и их обработка в Delphi ? Если да — конечно была, там был серьезный GUI. Если что-то иное — значит, я не в курсе.

CL>строки в качестве буфера?

Это просто не понял. AnsiString были, конечно.

Машина 1999 года — Pentium -1, 166 MHz, 32 Mb.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>>Это я к тому, что рассказывая про страшные цифры, каждый должен знать, что именно эта цифра отражает. Если это объём виртуальной памяти процесса, то это вообще ничего не значит.
НС>Не значит только пока ее хватает. А потом начинает значит со страшной силой.

Описанные мной политики glibc это случай 64 бит. Мне сложно себе представить, чем там исчерпать виртуальные адреса.
Аналогично, стартовые затраты типа 100MB, если это просто адресное пространство — фигня даже в 32 битах.

НС> Но я тебе больше скажу — объем даже реально используемой физической памяти тоже нифига не значит, пока ее хватает.

Это несерьёзная постановка вопроса. Реально используемая физическая (она же резидентная) память, в отличие от собственной виртуальной процесса, отжирает место и у других процессов, и у кэшей.

M>>Оставлю, например, это здесь:
M>>http://en.wikipedia.org/wiki/Compiler_optimization
M>>http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860
M>>http://www.cs.princeton.edu/courses/archive/spr03/cs320/notes/loops.pdf

M>>Но без шансов на понимание.

PD>Совершенно верно, без всяких шансов на понимание, потому что, видимо, ты уже разучился понимать русский язык. Прочти внимательно еще раз, я сейчас для тебя специально выделил. Впрочем,вряд ли поможет.

Плевать. Можешь использовать эти ссылки на ответ на любой твой «ах, пачиму канпилятар паскаля работаит в 1 Мб, а саврименныи канпиляторы С++ ни умеют».

Современный C++ даже Edit & Continue уже умеет. Но это достигается искючительно магией, ага.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В каком смысле не переплюнул?

В смысле организации метаинформации. Я ее когда-то давно ковырял — очень эффективно можно заливаеть в память нужную область файла целиком (АПИ модуля) и потом только индексы расставлять.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>С — не особо долго. Медленнее ТурбоПаскаля

Медленне раз в 10-20 для программ в десяток тыщ строк. Для более больших — еще больше разница. Успел покомпилять на IBM XT...

НС>>Но при всем при том прототипы функций все равно нужно описать в хидере.
М>Run-Time Type Information -- тип в райнтайме. на стадии компиляции о типе ничего не известно. как описать прототип в хидере, если тип динамический?
М>да и динамическая линковска с тем же dll -- никогда не знаешь какие там функции есть. допустим, в новой оси появилась новая фича. в старой dll такой функции нет. линкуем динамически
а ты точно тот самый мыщъх aka крис касперски?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Да, конечно. Да их и не сложно получить совсем. Мой недавний проект (конвертировал с Delphi на С++). Совсем небольшой, 150 Кб исходников. Во время компиляции cl.exe (причем в режиме Debug, так что об оптимизации речи нет) Task Manager показывает Working Set от 15 до 25 Мб.

[...]

PD>Совершенно верно, без всяких шансов на понимание, потому что, видимо, ты уже разучился понимать русский язык. Прочти внимательно еще раз, я сейчас для тебя специально выделил. Впрочем,вряд ли поможет.

Проблема в том, что компиляция в debug (с выключенными оптимизациями) или в release — это не два разных компилятора. Это один и тот же, у которого строится одинаковое дерево разбора, но в случае release сборки на него напускается значительно больше разных действий. По крайней мере так у gcc, clang и тех, кого я хоть как-то рассматривал в деталях.
Поэтому те замеченные тобой 15-25MB (даже если у них заметная часть это аллоцированная, но не закоммиченная память) это результат разбора совсем другими технологиями, чем те, что использовались во времена одномегабайтных машин. Да, это цена за возможность использования тех средств, которые ты в случае debug не используешь.

Здравствуйте, netch80, Вы писали:

N>Проблема в том, что компиляция в debug (с выключенными оптимизациями) или в release — это не два разных компилятора. Это один и тот же, у которого строится одинаковое дерево разбора, но в случае release сборки на него напускается значительно больше разных действий. По крайней мере так у gcc, clang и тех, кого я хоть как-то рассматривал в деталях.
N>Поэтому те замеченные тобой 15-25MB (даже если у них заметная часть это аллоцированная, но не закоммиченная память)

Это Working set, а сколько там аллоцировано и закомичено — я не смотрел. Надо полагать, больше. Сейчас проверить не могу.

Здравствуйте, Pavel Dvorkin, Вы писали:

N>>Проблема в том, что компиляция в debug (с выключенными оптимизациями) или в release — это не два разных компилятора. Это один и тот же, у которого строится одинаковое дерево разбора, но в случае release сборки на него напускается значительно больше разных действий. По крайней мере так у gcc, clang и тех, кого я хоть как-то рассматривал в деталях.
N>>Поэтому те замеченные тобой 15-25MB (даже если у них заметная часть это аллоцированная, но не закоммиченная память)

PD>Это Working set, а сколько там аллоцировано и закомичено — я не смотрел. Надо полагать, больше. Сейчас проверить не могу.

"Working set" — это Обстракция. Это термин, который каждый понимает по-разному. Я бы его не использовал.

Здравствуйте, netch80, Вы писали:

N>"Working set" — это Обстракция. Это термин, который каждый понимает по-разному. Я бы его не использовал.

Это не абстракция. Это совершенно четкий параметр : количество страниц процесса, находящееся в данный момент в ОП.

Эти данные можно получить даже в юзермоде.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684946(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684949(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683478(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683239(v=vs.85).aspx

Подробности — у Соломона-Руссиновича.

Здравствуйте, Pavel Dvorkin, Вы писали:

N>>"Working set" — это Обстракция. Это термин, который каждый понимает по-разному. Я бы его не использовал.
PD>Это не абстракция. Это совершенно четкий параметр : количество страниц процесса, находящееся в данный момент в ОП.

А. То есть это resident set. А не какой-то абстрактный working set.

PD>Подробности — у Соломона-Руссиновича.

Я, конечно, понимаю стремление MS всё обозвать по-своему, но потом приходится бороться с последствиями этого.

Здравствуйте, netch80, Вы писали:

N>А. То есть это resident set. А не какой-то абстрактный working set.

Называй как хочешь. Я привык к понятию working set (рабочее множество, рабочий набор).

N>Я, конечно, понимаю стремление MS всё обозвать по-своему, но потом приходится бороться с последствиями этого.

Вот тут ты не прав. Я этот термин знал раньше, чем узнал о существовании MS . Вроде как здесь прочитал

Дейтел Г. Введение в операционные системы. М.: Мир. 1987.

Здравствуйте, netch80, Вы писали:

См. еще тут

http://cs.mipt.ru/docs/courses/osstud/10/ch10.htm