Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Опять терминологический спор. Ну ок: как показывает простейший тест естественна фрагментация стала намного благоприятней в следствии замены дубового аллокатора начиная с VS2012 EP>Теперь списков на x86 меньше боишься?
Я их никогда не боялся Даже c идеальным GC в проложениях, критичных к расходу памяти, надо быть в курсе, как расходуется память. И тоже самое в С++, Джаве и где угодно — надо знать инструмент которым работаешь.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>"Проблема актуальная для больших приложений в архитектуре навроде x86, где АП ограничено — всего 2гб, но в силу естественной фрагментации размер непрерывного отрезка АП может быть намного меньше, в 10 и более раз" EP>>>Как показывает простейший тест естественная фрагментация стала действительно "естественной", а не следствием дубового аллокатора, только начиная с VS2012 I>>Естественная фрагментация это следствтие работы системы в естественных условиях в конкретном случае: рантайм, винда, данные пользователя и тд и тд.
EP>Опять терминологический спор. Ну ок: как показывает простейший тест естественна фрагментация стала намного благоприятней в следствии замены дубового аллокатора начиная с VS2012 EP>Теперь списков на x86 меньше боишься?
Подумай тем местом, что между ушами. В правильной стратегии аллокации c использованием GC эта проблема всё равно возникнет, только всего чуток позже, самую малость.
При этом, нагрузка на GC будет зависеть от
1. количества аллокаций
2. количества объектов вообще
Если N объектов в списке коррелирует с Е количеством объектов в системе, то на ровном месте получается плохая зависимость, т.к. время работы GC это O(E+V), где E количетсво объхектов, V количество ссылок между ними.
Итого, N коррелирует с E и это значит, что нагрузка на GC будет практически N^2. Список в любом случае будет вызывать фрагментацию, хоть убейся, этого не избежать. Даже всякие схемы уплотнения ничего радикально не меняют.
Задав капасити, можно обработать список равный размеру свободной памяти. Без этого будет втрое меньше и это фрагментация в чистом виде.
То есть, эта проблема общая для любых приложений на любых языках, которые расходуют память в объемах сравнимых с размером адресного пространства.
Для случаев без GC все получается гораздо хуже, именно с этой конкретной проблемой, дефрагментации у тебя нет и быть не может. То есть, все еще хуже чем с GC.
Отсюда следствие — как бы ты ни приседал с аллокацией , эта же проблема возникнет в любом языке, для любого контейнера на массиве, в котором grow factor == 2 без реаллокации, и в который добавление идет по одному элементу без задания начальной капасити. В идеальном случае можно выделить AП/3. Реально будет максимально доступное окно поделить на три. Все проги без GC уже сваливаются. GC продолжит сопротивляться, будет гонять объекты по адресному пространству, что влечет за собой жосцкий своп. Все что сможет GC, теоретически, ужать хипы так, что бы окно было одно единственное и после этого кинет OOM.
Здравствуйте, Ikemefula, Вы писали:
I>Задав капасити, можно обработать список равный размеру свободной памяти. Без этого будет втрое меньше и это фрагментация в чистом виде.
Это не фрагментация, это в первую очередь отсутствие памяти. Даже при полном отсутствии всякой фрагментации, у тебя capacity не сможет вырасти в два раза, когда ты уже съел треть памяти, хоть ты тресни. Тебе уже это на протяжении нескольких страниц объясняли
I>То есть, эта проблема общая для любых приложений на любых языках, которые расходуют память в объемах сравнимых с размером адресного пространства.
Ты рассказывал про конкретные приложения, которые падали в неожиданных местах, и приходилось долго чесать репу, так?
Где это было, в какой среде? Случаем не в C# <=VS2008?
I>Для случаев без GC все получается гораздо хуже, именно с этой конкретной проблемой, дефрагментации у тебя нет и быть не может. То есть, все еще хуже чем с GC.
Как будто в .NET <4.5.1 есть дефрагментация LOH
I>Отсюда следствие — как бы ты ни приседал с аллокацией , эта же проблема возникнет в любом языке, для любого контейнера на массиве, в котором grow factor == 2 без реаллокации, и в который добавление идет по одному элементу без задания начальной капасити. В идеальном случае можно выделить AП/3. Реально будет максимально доступное окно поделить на три.
Молодец, возьми с полки пирожок.
Какое озарение будет следующим?
I>Все проги без GC уже сваливаются. GC продолжит сопротивляться, будет гонять объекты по адресному пространству, что влечет за собой жосцкий своп.
Здравствуйте, Ikemefula, Вы писали:
I>Итого — в два три клика можно получить необходимую информацию и не надо загаживать код каментами, которые в обязательном порядке надо апдейтить, ибо если каменты не отображают реальное положение дел, это создает еще большую проблему.
А так без кликов, просто в ноутпаде всё видно...
Кстати, почему ты считаешь, что доки проще апгрейдить, чем комментарии? Их ещё и размножать потом надо будет с версиями кода, и мёржить...
Хорошо, если у тебя какой-то простой тупо-программистский код. А если у тебя какая-то наукоёмкая область или там куча эвристик каких-то в коде есть? Ты всё ещё уверен, что параллельное дереву версий исходников дерево версий подробной документации по всем эвристикам и доказательствам -- это хорошо?
По идее документация нужна что бы разбираться в системе в целом, в архитектурных решениях и т. д. а вот как раз мелкие решения всякие, принятые "по месту" в документации очень редко оказываются адекватно описаны...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>Если N объектов в списке коррелирует с Е количеством объектов в системе, то на ровном месте получается плохая зависимость, т.к. время работы GC это O(E+V), где E количетсво объхектов, V количество ссылок между ними. I>Итого, N коррелирует с E и это значит, что нагрузка на GC будет практически N^2.
1. "Сегодня утром пролетело 4 птицы, значит завтра будет дождь" — Я не уследил за твоими напёрстками откуда у тебя получилось "практически N^2"
2. Миллионный List из Point3D — это тоже ужас-ужас в квадрате?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Речь идёт про загаживание LOH большими объектами, с которым дела обстояли плохо вплоть до VS2008.
Стоит начать хотя бы с понимания того факта, что рантайм (и поведение GC) от версии студии практически никак не зависит. Свежевышедшая vs2013 по прежнему позволяет писать под рантайм образца 2005 года.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Речь идёт про загаживание LOH большими объектами, с которым дела обстояли плохо вплоть до VS2008. НС>Стоит начать хотя бы с понимания того факта, что рантайм (и поведение GC) от версии студии практически никак не зависит.
Это очень важный факт, который меняет в корне всю дискуссию. Когда делал примеры — выбирал максимально доступный Runtime.
Расскажи лучше как в VS2008 выбрать .NET 4.0
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Задав капасити, можно обработать список равный размеру свободной памяти. Без этого будет втрое меньше и это фрагментация в чистом виде.
EP>Это не фрагментация, это в первую очередь отсутствие памяти. Даже при полном отсутствии всякой фрагментации, у тебя capacity не сможет вырасти в два раза, когда ты уже съел треть памяти, хоть ты тресни. Тебе уже это на протяжении нескольких страниц объясняли
Алё ! При правильном капасити не надо никуда вырастать — выделяешь столько, сколько надо и всё. Представь — есть 1гб список и АП 2гб, условно — больше никто не юзает память и АП. Выделяешь список с капасити 1гб, делаешь реверс и отдыхаешь. Вот больше 1гб не получится и вот это уже НЕ фрагментация, а тупо нехватка памяти. Все что сваливается меньше 1гб это фрагментация.
I>>То есть, эта проблема общая для любых приложений на любых языках, которые расходуют память в объемах сравнимых с размером адресного пространства.
EP>Ты рассказывал про конкретные приложения, которые падали в неожиданных местах, и приходилось долго чесать репу, так?
Мне ни разу не приходилось долго думать, что бы задетктить фрагментацию, но долго приходилось анализировать граф объектов, что бы выяснить, как его можно оптимизировать.
EP>Где это было, в какой среде? Случаем не в C# <=VS2008?
Начиная с TP5.5-BP7.0, потом TC2.0-BC3.1, Watcom C, потом VS 97 и заканчивая VS 2012, примерно так Вот на ассемблере этого не было, динамику как то не сильно использовал, извини.
I>>Для случаев без GC все получается гораздо хуже, именно с этой конкретной проблемой, дефрагментации у тебя нет и быть не может. То есть, все еще хуже чем с GC.
EP>Как будто в .NET <4.5.1 есть дефрагментация LOH
Там про GC вообще, а не конкретный.
I>>Отсюда следствие — как бы ты ни приседал с аллокацией , эта же проблема возникнет в любом языке, для любого контейнера на массиве, в котором grow factor == 2 без реаллокации, и в который добавление идет по одному элементу без задания начальной капасити. В идеальном случае можно выделить AП/3. Реально будет максимально доступное окно поделить на три.
EP>Наконец-то ты смог осилить вот эту задачку
Молодец, возьми с полки пирожок. EP>Какое озарение будет следующим?
Удивляюсь, как ты читать умеешь. У вектора grow factor 1.5, откуда 3 взялось ? Хотя, может ты 1.5 до 2х округляешь, извини, не в курсе новых тенденций в арифметике
I>>Все проги без GC уже сваливаются. GC продолжит сопротивляться, будет гонять объекты по адресному пространству, что влечет за собой жосцкий своп.
EP>Что там у тебя будет GC по LOH'у гонять?
Не по LOH, а по адресному пространству. Гонять — объекты. Или у тебя другие варианты есть ?
Здравствуйте, Erop, Вы писали:
E>А так без кликов, просто в ноутпаде всё видно...
Это и есть колхоз времен коллективизации.
E>Кстати, почему ты считаешь, что доки проще апгрейдить, чем комментарии? Их ещё и размножать потом надо будет с версиями кода, и мёржить...
Не надо ничего размножать — доки находятся в единственном экземпляре на сервере в вики, конфлюэнце или шарепоинте. Надо модифировать фичу — берешь за основу старую версию, копируешь в фолдер новой версии и пишешь туда все что тебе надо.
E>Хорошо, если у тебя какой-то простой тупо-программистский код. А если у тебя какая-то наукоёмкая область или там куча эвристик каких-то в коде есть? Ты всё ещё уверен, что параллельное дереву версий исходников дерево версий подробной документации по всем эвристикам и доказательствам -- это хорошо?
Для наукоемкой особенно актуальна интеграция VCS, трекера и документации, иначе вспотеешь контролировать все вырожденые случаи. для тупо технического проекта вообще никакой документации может не быть, потому что как правило все и так в теме или все есть в гугле.
E>По идее документация нужна что бы разбираться в системе в целом, в архитектурных решениях и т. д. а вот как раз мелкие решения всякие, принятые "по месту" в документации очень редко оказываются адекватно описаны...
Мелкие вещи тоже надо тестировать. Объясни, каким раком тестировщики смогут покрыть твою мульку ручными/автоматическими тестами ?
Здравствуйте, Marty, Вы писали:
M>Когда и как часто надо дергать за Dispose-костыли, апологеты GC нам тут конечно ничего не скажут, это не в их интересах
Dispose-костыли в управляемой среде предназначены в основном для решения проблем с нативным кодом.
Здравствуйте, Erop, Вы писали:
I>>То есть, ты сам для себя в коде напоминалки пишешь ? А кому они нужны кроме тебя ? E>Ага, а ещё доказательства его работоспособности и т. п.
эм... вообще-то доказательством работоспособности может быть только (юнит)тест
Здравствуйте, Ikemefula, Вы писали:
I>Представь — есть 1гб список и АП 2гб, условно — больше никто не юзает память и АП. Выделяешь список с капасити 1гб, делаешь реверс и отдыхаешь. Вот больше 1гб не получится и вот это уже НЕ фрагментация, а тупо нехватка памяти. Все что сваливается меньше 1гб это фрагментация.
[ | | | | | | | | | | | | | |*|*|*|*|*|*|*|*]
* — занятное List'ом, пробел — свободное.
Попробуй увеличь capacity вдвое — и покажи где тут фрагментация
EP>>Где это было, в какой среде? Случаем не в C# <=VS2008? I>Начиная с TP5.5-BP7.0, потом TC2.0-BC3.1, Watcom C, потом VS 97 и заканчивая VS 2012, примерно так Вот на ассемблере этого не было, динамику как то не сильно использовал, извини.
и его списки? Зачем про Паскаль загоняешь?
I>>>Для случаев без GC все получается гораздо хуже, именно с этой конкретной проблемой, дефрагментации у тебя нет и быть не может. То есть, все еще хуже чем с GC. EP>>Как будто в .NET <4.5.1 есть дефрагментация LOH I>Там про GC вообще, а не конкретный.
А зачем не про конкретный, если топик начался с конкретных List'ов и конкретного C#'а?
I>>>Отсюда следствие — как бы ты ни приседал с аллокацией , эта же проблема возникнет в любом языке, для любого контейнера на массиве, в котором grow factor == 2 без реаллокации, и в который добавление идет по одному элементу без задания начальной капасити. В идеальном случае можно выделить AП/3. Реально будет максимально доступное окно поделить на три.
EP>>Наконец-то ты смог осилить вот эту задачку
Молодец, возьми с полки пирожок. EP>>Какое озарение будет следующим? I>Удивляюсь, как ты читать умеешь. У вектора grow factor 1.5, откуда 3 взялось ? Хотя, может ты 1.5 до 2х округляешь, извини, не в курсе новых тенденций в арифметике
Не, не прокатит отмазка. У вектора grow factor не оговорен стандартом
А твой ответ показывал полное не понимание:
V>>Если в тесте после грубо 660 метров не удалось выделить память, то это значит, что всего было запрошено порядка 660*3=1980 метров. ЧТД.
i>А почему на три надо помножать, если добавляем по одному байту ?
Тут нет ничего про 1.5x, тут есть "добавляем по одному байту"
Здравствуйте, Ikemefula, Вы писали:
I>Не надо ничего размножать — доки находятся в единственном экземпляре на сервере в вики, конфлюэнце или шарепоинте. Надо модифировать фичу — берешь за основу старую версию, копируешь в фолдер новой версии и пишешь туда все что тебе надо.
Это и есть размножать... Если потом понадобится ещё и мержить правки в коде, то надо будет не забыть смёржить и доки, да ещё и сделать это корректно, кстати...
I>Для наукоемкой особенно актуальна интеграция VCS, трекера и документации, иначе вспотеешь контролировать все вырожденые случаи. для тупо технического проекта вообще никакой документации может не быть, потому что как правило все и так в теме или все есть в гугле.
Ну кто потеет, а кто без проблем контролирует...
I>Мелкие вещи тоже надо тестировать. Объясни, каким раком тестировщики смогут покрыть твою мульку ручными/автоматическими тестами ?
Это никак не связано с тем, что ты где-то должен объяснить поддерживающим код коллегам ПРИЧИНЫ принятых в коде решений...
Про тестировать -- тема отдельная.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Abyx, Вы писали:
A>эм... вообще-то доказательством работоспособности может быть только (юнит)тест
Про проблему останова слыхал? Так вот, одно из следствий состоит в том, что никакой тест не может гарантировать работоспособности. Но в некоторых случаях некоторые специально написанные алгоритмы можно доказать ФОРМАЛЬНО, это если требуется такой уровень надёжности.
Юнит-тест вообще для другого нужен, он ловит неожиданную порчу интерфейсов и отступления от контрактов, но с какой-то вероятностью, а не достоверно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>Это и есть колхоз времен коллективизации.
Я, кстати, часто распечатки вообще читаю, ну, например, выхожу из дома в лес, сажусь на пинёк и читаю, что там у нас такого интересного напрограммировалось, что всё так неожиданно плохо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Это очень важный факт, который меняет в корне всю дискуссию. Когда делал примеры — выбирал максимально доступный Runtime. НС>Нет, это демонстрация того, что ыт полностью не в теме.
Ещё один
Давай, рассказывай, где именно не в теме. Может "полностью не в теме" про LinkedList
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Если N объектов в списке коррелирует с Е количеством объектов в системе, то на ровном месте получается плохая зависимость, т.к. время работы GC это O(E+V), где E количетсво объхектов, V количество ссылок между ними. I>>Итого, N коррелирует с E и это значит, что нагрузка на GC будет практически N^2.
EP>1. "Сегодня утром пролетело 4 птицы, значит завтра будет дождь" — Я не уследил за твоими напёрстками откуда у тебя получилось "практически N^2"
Элементарно — на добавление N элементов надо будет переместить N элментов в АП
EP>2. Миллионный List из Point3D — это тоже ужас-ужас в квадрате?
Здравствуйте, Ikemefula, Вы писали:
I>>>Если N объектов в списке коррелирует с Е количеством объектов в системе, то на ровном месте получается плохая зависимость, т.к. время работы GC это O(E+V), где E количетсво объхектов, V количество ссылок между ними. I>>>Итого, N коррелирует с E и это значит, что нагрузка на GC будет практически N^2. EP>>1. "Сегодня утром пролетело 4 птицы, значит завтра будет дождь" — Я не уследил за твоими напёрстками откуда у тебя получилось "практически N^2" I>Элементарно — на добавление N элементов надо будет переместить N элментов в АП
Подробнее.
EP>>2. Миллионный List из Point3D — это тоже ужас-ужас в квадрате? I>Не в курсе что это такое
Здравствуйте, koodeer, Вы писали:
M>>Когда и как часто надо дергать за Dispose-костыли, апологеты GC нам тут конечно ничего не скажут, это не в их интересах K>Dispose-костыли в управляемой среде предназначены в основном для решения проблем с нативным кодом.
Например таких?
using (var connection = new SqlConnection(connectionString))
{
// ...
foo_may_throw();
// ...
}
Вот на ассемблере этого не было, динамику как то не сильно использовал, извини. 
