Здравствуйте, Ikemefula, Вы писали:
I>>>Представь — есть 1гб список и АП 2гб, условно — больше никто не юзает память и АП. Выделяешь список с капасити 1гб, делаешь реверс и отдыхаешь. Вот больше 1гб не получится и вот это уже НЕ фрагментация, а тупо нехватка памяти. Все что сваливается меньше 1гб это фрагментация. EP>>[ | | | | | | | | | | | | | |*|*|*|*|*|*|*|*] EP>>* — занятное List'ом, пробел — свободное. EP>>Попробуй увеличь capacity вдвое — и покажи где тут фрагментация I>Объясняю еще раз — если задаешь правильный капасити не надо ничего увеличивать. Надо 1гб — поставь точно такой же капасити, реаллокаций не будет, а следовательно GC не надо будеть гонять объекты по АП.
var list = new List<Item>();
while (condition())
{
list.Add(current());
}
?
Сколько резервировать будешь?
Да и вообще ты так и не показал, где там фрагментация на диаграмме выше
EP>>>>Где это было, в какой среде? Случаем не в C# <=VS2008? I>>>Начиная с TP5.5-BP7.0, потом TC2.0-BC3.1, Watcom C, потом VS 97 и заканчивая VS 2012, примерно так Вот на ассемблере этого не было, динамику как то не сильно использовал, извини. EP>>Ты же про C# говорил
и его списки? Зачем про Паскаль загоняешь? I>Потому что фрагментация вылазит всегда и везде, когда потребление памяти близко к размеру АП. Когда софт дорастет до границ х64, то там тоже вылезет проблема с фрагментацией. Радикально решить можно будет толко увеличением АП, то есть, переходом на 128 бит, а потом на 256 и так далее. Правда, есть шанс, что солнце погаснет раньше, чем мейнстрим дорастет до такой разрядности.
Не надо тут про Солнце, конкретно отвечай — о какой VS говорил по ссылке.
Большая разница — обжегся ли ты об кривой аллокатор, либо об вполне оправданную фрагментацию (которая не является прямым следствием примитивной политики аллокации).
EP>>А твой ответ показывал полное не понимание: EP>>
V>>>>Если в тесте после грубо 660 метров не удалось выделить память, то это значит, что всего было запрошено порядка 660*3=1980 метров. ЧТД.
i>>>А почему на три надо помножать, если добавляем по одному байту ?
EP>>Тут нет ничего про 1.5x, тут есть "добавляем по одному байту" I>Это специально для vdimas. Я ожидал от него чтото навроде "Ага ! Попался, двоечник !!! байты ни при чем !!!!111расрас" и на тот момент у меня был заготовлен более интересный троллинг
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Ну а что, например, делать с мьютексом? Ждать пока система его разлочит? EP>А если там какая-нибудь синхронизация чуть сложнее тривиальной — один мьютекс система отпустит, а другой нет, и внезапно наступает deadlock
Например, в дотнете есть библиотека TPL — task parallel library. При её использовании можно почти не думать о мьютексах и т.п. Всё автоматически распараллеливается, синхронизируется, освобождается. Почти сказка.
Конечно, внутри TPL используются примитивы синхронизации и прочее. Но у прикладного программиста не болит голова от их использования, потому что они не торчат наружу.
Я не могу ручаться, но вполне вероятно в полностью управляемой среде спрятать от прикладных программеров почти все подобные аспекты.
EP>Или например как создавать свои ресурсы? Как сказать системе что делать при их закрытии?
Создавать как обычно. Что делать при закрытии пишется в специальном методе (будет он зваться деструктор, финализатор или dispose — не важно). Этот метод автоматически вызывается, когда в больше нет ссылок на данный ресурс. И, в отличие от нынешнего GC, не обеспечивающего детерминизм, вполне можно создать альтернативный, которому можно указать, что данный конкретный объект нуждается в мгновенном освобождении, а не когда обычный GC проснётся.
Я отнюдь не ратую всеми силами за управляемые среды. Мне больше по нраву c/c++ и ассемблер: биты, байты, регистры, прерывания... На дотнете сижу вынужденно — что востребовано, то и использую. Я лично считаю, что нынешние управляемые среды со временем умрут. Примерно тогда же, когда умрёт c++. А на смену должно прийти нечто наподобие D — где и полный контроль над железом есть, и сборщик мусора имеется.
Здравствуйте, koodeer, Вы писали:
K>Например, в дотнете есть библиотека TPL — task parallel library. При её использовании можно почти не думать о мьютексах и т.п. Всё автоматически распараллеливается, синхронизируется, освобождается. Почти сказка.
Это всё понятно.
K>Я не могу ручаться, но вполне вероятно в полностью управляемой среде спрятать от прикладных программеров почти все подобные аспекты.
Вряд ли такое возможно в языке достаточно широкого назначения.
EP>>Или например как создавать свои ресурсы? Как сказать системе что делать при их закрытии?
K>Создавать как обычно. Что делать при закрытии пишется в специальном методе (будет он зваться деструктор, финализатор или dispose — не важно). Этот метод автоматически вызывается, когда в больше нет ссылок на данный ресурс. И, в отличие от нынешнего GC, не обеспечивающего детерминизм, вполне можно создать альтернативный, которому можно указать, что данный конкретный объект нуждается в мгновенном освобождении, а не когда обычный GC проснётся.
Детерминизм действительно важен, и поэтому в C# есть using, в Java — try-with-resources , в Python — with — и везде требуется подобие IDisposable.
Возвращаясь к исходного тезису:
K>Dispose-костыли в управляемой среде предназначены в основном для решения проблем с нативным кодом.
Мой поинт в том, что ресурсы существуют сами по себе, а не являются какой-то особенностью native.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Да и вообще ты так и не показал, где там фрагментация на диаграмме выше
"и полном отсутствии всякой фрагментации, у тебя capacity не сможет вырасти в два раза, когда ты уже съел треть памяти, хоть ты тресни."
В очередной раз объясняю — если ты съел треть памяти, то две трети свободно. Если тебе изначально нужны эти две трети — задавай капасити один раз, тогда никаких переаллокаций не потребуется и все данные влезут в память.
I>>Потому что фрагментация вылазит всегда и везде, когда потребление памяти близко к размеру АП. Когда софт дорастет до границ х64, то там тоже вылезет проблема с фрагментацией. Радикально решить можно будет толко увеличением АП, то есть, переходом на 128 бит, а потом на 256 и так далее. Правда, есть шанс, что солнце погаснет раньше, чем мейнстрим дорастет до такой разрядности.
EP>Не надо тут про Солнце, конкретно отвечай — о какой VS говорил по ссылке.
На всех, а еще на джаве, питоне и джаваскрипте.
EP>Большая разница — обжегся ли ты об кривой аллокатор, либо об вполне оправданную фрагментацию (которая не является прямым следствием примитивной политики аллокации).
Я вроде ясно сказал — с фрагментацией регулярно сталкивался начиная с доса и заканчивая всякими виртуальными машинами. Допустим с дотнетом я первый раз столкнулся где то лет 10 назад, тогда я не был в курсе GC и особенностей его хипов.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>Я чучка погорячился про квадратичность, но сути это не меняет. N*log(N) с подключением свопа мало чем отличается для обсуждаемого размера АП. EP>>>Ну ты даже O(N*log(N)) не показал. То о чём ты говоришь это O(N). I>>O(log(N)) аллокаций массива в списке, для каждой из них надо пробежать граф из O(N) элементов I>>Сколько это по твоему ?
EP>Выделенное неверно. EP>Аллокаций действительно O(log(N)), вот только на каждой нужно пробежать по количеству зависящему от номера текущей аллокации, а не от общего числа элементов.
Не боись, я уже понял, с математикой у меня действительно все плохо, хуже некуда
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Весь топик про то, "какие опасные List'ы". Я в своём сообщении попытался разобраться в чём же дело. EP>Вполне вероятно, что дело было в плохом аллокаторе.
Не, проблема не в list как таковом, а в его использовании без чтения документации.
EP>Так разборки начали .NET'чики с боязни больших объектов и List'ов. Видимо они не в курсе что разруливается — пришлось самому пример делать
Эммм... Ikemefula, при всём уважении, на моей памяти отмечается только в КСВ, да и то уже на коне, с опущенным забралом и надкушенным яблоком на щите
Дотнетчиков лучше искать в профильных разделах, мы в основном не буйные
EP>Я же не говорю что так нужно писать код, или что проблему нельзя обойти. Это пример является demo того, что был плохой аллокатор, и многие на нём могли обжечся
Многие — это очень сильно преувеличено. Не, серьёзно — как часто в прикладном коде требуется активно аллоцировать гигабайты в памяти, причём по мааленьким кусочкам да ещё вперемешку с мелкими долгоживущими массивами?
EP>О, кстати. Я спрашивал про аналог C++1998 std::deque — мне пытались впарить LinkedList
под видом деки. Может ты покажешь какую деку обычно используют в .NET — ведь должно же быть что-то стандартное, или распространённое, раз с List'ом такой ужас-ужас.
С List проблем нет, как уже не раз говорилось. В дотнете из коробки есть только однонаправленная Queue<T>, если нужен имено дек — есть готовые реализации, например http://nitodeque.codeplex.com/
A>купи планшет, дешевле будет чем бумагу и картриджи переводить.
Ничего страшного, я могу себе позволить потратиться на бумагу и печать...
А планшеты -- это для нищебродов
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>Я ж говорю — колхоз. Есть вещи более эффективные нежели твои бумажки.
Я же говорю, от задачи зависит. Тупой кодинг автоматизирован довольно хорошо, а я не программист же. Я скорее математик
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>А если требования в коде, то их смержить код сохранив корректные каменты это задача практически нереальная,
Ну кому нереальная, а кто-то что-то умеет, кроме как в два клика окошки открывать.
Это же дело-то известное, если руки кривые, то многое меняется
I>ибо надо заранее планировать каменты так что бы они не мешали мержу.
Ну так комментарии -- это же тоже часть кода. Вообще структуру всего кода надо заранее планировать и менять осознанно...
I>А то будет вот так — кто-то перенес функцию в отдельный файл, а при мерже получится так что структура каментов отличается от структуры нового кода.
Ну, скорее всего, этот "кто-то" будет неправ. Но так же он будет неправ, например, если название функции перестанет соответствовать её семантике.
И чем тут одно лучше другого я
I>Да, я в курсе. У меня есть один знакомый, который очень любит ручную работу. Он на почасовой оплате, смержит руками мегабайт кода за неделю, ему эту недели и оплатят.
мне за мёрж кода вообще не платят,..
Мне платят за лучшие в мире ТТХ моего изделия...
I>Ты похоже вообще в ИТ не работаешь. Документация даже мелких изменений должна быть вне кода, ибо не ты один работаешь с кодом. Тестеры, менеджеры, аналитики будут вынуждены пахать твой код, что бы разобраться ,что же ты там научитывал.
Ну разные бывают IT...
Вот у нас, например, есть обычно какие-т такие весьма внешние проявления фич и баг, а есть внутренние их причины и реализации и одно на другое очень небанально отображается, и тестеры с аналитеками просто не компетентны часто, что бы понять суть изменений...
Кроме того, ты всё время о правках думаешь, а бывает ещё и другой сценарий, когда какие-то варианты рассматривались при проектировании или разработке, и сразу был выбран какой-то один, но он не из одного варианта был выбран, а из нескольких на первый взгляд подходящих, и выбран был осознанно, и обоснованно. И если в коде будет указано, что был такой выбор и его обоснование было таким-то, это сильно сэкономит сиы тем, кто будет потом править если что.
Да, кстати у нас не принято делать необычный выбор необоснованно. Так что либо код должен быть стандартный, либо должно быть обоснование...
Кстати, вот, например, одна из технологий, которую я сейчас поддерживаю, имеет пять актуальных мажорных версий и около 100 минорных. То есть в дереве бранчей в системе контроля версий порядка 100 живых листов, где каждый лист -- отдельная моификация полного комплекта исходников. К этой штуке прилагается самомисная и самоподдерживаемая документация верхнего уровня. Которая имеется в пяти версиях по пяти мажорным версиям кода и куча документации более мелкого уровня, которая лежит в системе контроля версий и имеет те же версии, что и код, и вообще довольно сильно с кодом ассоциирована. Если ты разветвляешь какую-то часть кода, то автоматом разветвляешь и соответствующую документацию. И самая низкоуровневая документация живёт просто в коментах и других исходниках. У нас применяется не тока С++, но и ещё несколько самописных языков, где с комментами немного иная история
Соответственно, чисто по опыту,
1) Популярные у аналитиков инструменты используют форматы документов крайне недружественные автоматическому мёржу.
2) Большинство аналитиков умет писать и поддеривать срукуру документации дружественной к мёржу намного хуже большинства программистов.
Так что комментарии, если за ними вообще следят, исто по опыту, обычно актуальнее и точнее доков...
I>Та же самая, только в твоем случае надо будет не только код с требованиями синхронизировать, а еще и код-каменты со спекой.
Спека -- это истрия из мира аутсорса. Типа сппека есть и я её реализую. А если спека такая, что наша новая версия должна уверенно сбивать новую версию амеркого файтера, а дальше крутись как хочешь, то расклады слегка другие...
Всё зависит от целей. Если твоя цель формально реализовать спеку, то история одна, а если цель попасть в какие-то ТТХ, то совсем-совсем другая...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sinix, Вы писали:
EP>>Весь топик про то, "какие опасные List'ы". Я в своём сообщении попытался разобраться в чём же дело. EP>>Вполне вероятно, что дело было в плохом аллокаторе. S>Не, проблема не в list как таковом, а в его использовании без чтения документации.
Проблема действительно не в List, и чтение документации List'а тут ничем бы не помогло. Так как дефект был в аллокаторе.
S>Дотнетчиков лучше искать в профильных разделах, мы в основном не буйные
Возможно Но пока получается пересекаться только в КСВ
EP>>Я же не говорю что так нужно писать код, или что проблему нельзя обойти. Это пример является demo того, что был плохой аллокатор, и многие на нём могли обжечся S>Многие — это очень сильно преувеличено. Не, серьёзно — как часто в прикладном коде требуется активно аллоцировать гигабайты в памяти, причём по мааленьким кусочкам да ещё вперемешку с мелкими долгоживущими массивами?
В приложении аллокации могут быть размазаны по коду, и не всегда следят что и в каких объёмах аллоцируется, по крайней мере до OOM. Я уверен что такой аллокатор будет всё портить и в других сценариях, например в долгоживущих приложениях.
EP>>О, кстати. Я спрашивал про аналог C++1998 std::deque — мне пытались впарить LinkedList
под видом деки. Может ты покажешь какую деку обычно используют в .NET — ведь должно же быть что-то стандартное, или распространённое, раз с List'ом такой ужас-ужас. S>С List проблем нет, как уже не раз говорилось. В дотнете из коробки есть только однонаправленная Queue<T>, если нужен имено дек — есть готовые реализации, например http://nitodeque.codeplex.com/
Нужен именно O(1) random-access реализованный на чанках, как и std::deque.
По этой ссылке, вроде то что нужно — "This deque provides O(1) indexed access,". Но смущает: "all page views=613" — для такой базовой структуры не слишком надёжно.
Здравствуйте, Abyx, Вы писали:
A>эти фичи практически всегда можно протестировать вручную, а можно протестировать автоматически.
1) функциональное тестирование не является юнит-тестом.
2) Я не против тестов, я за
3) В общем случае доказать работоспособность кода они всё равно не могут
Например, у меня есть бор, в котором хранится словарь естественного языка. В структуре бора есть ограничения, на всякие там вещи типа число детей у узла, скажем и битность ссылки. Доказать что для любого естественного языка хватит тестами трудно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
EP>В приложении аллокации могут быть размазаны по коду, и не всегда следят что и в каких объёмах аллоцируется, по крайней мере до OOM. Я уверен что такой аллокатор будет всё портить и в других сценариях, например в долгоживущих приложениях.
Я всё что мог — написал выше, так что спорить не буду
S>>В дотнете из коробки есть только однонаправленная Queue<T>, если нужен имено дек — есть готовые реализации, например http://nitodeque.codeplex.com/ EP>Нужен именно O(1) random-access реализованный на чанках, как и std::deque. EP>По этой ссылке, вроде то что нужно — "This deque provides O(1) indexed access,". Но смущает: "all page views=613" — для такой базовой структуры не слишком надёжно.
Не, по ссылке реализация "всё в одном внутреннем массиве".
Если нужно именно на чанках — есть BigList в PowerCollections, больше ничего на глаза не попадалось, специально не искал.
Здравствуйте, Sinix, Вы писали:
S>Не, по ссылке реализация "всё в одном внутреннем массиве".
ок, не заметил.
S>Если нужно именно на чанках — есть BigList в PowerCollections, больше ничего на глаза не попадалось, специально не искал.
Вот, уже теплее "all page views=296189". Но судя по тому, что там, как они говорят, эффективные вставки в середину — это не прямой аналог std::deque.
Точно: "Getting or setting an item takes time O(log N), where N is the number of items in the list" против O(1) у std::deque. То есть это, по идее, аналог std::map<std::size_t,T>.
Здравствуйте, Erop, Вы писали:
I>>А если требования в коде, то их смержить код сохранив корректные каменты это задача практически нереальная, E>Ну кому нереальная, а кто-то что-то умеет, кроме как в два клика окошки открывать. E>Это же дело-то известное, если руки кривые, то многое меняется
Да, а если за недельный мерж заплатят денег так и вовсе хорошо.
I>>ибо надо заранее планировать каменты так что бы они не мешали мержу. E>Ну так комментарии -- это же тоже часть кода. Вообще структуру всего кода надо заранее планировать и менять осознанно...
И комментарии это всегда дополнительная нагрузка
I>>А то будет вот так — кто-то перенес функцию в отдельный файл, а при мерже получится так что структура каментов отличается от структуры нового кода. E>Ну, скорее всего, этот "кто-то" будет неправ. Но так же он будет неправ, например, если название функции перестанет соответствовать её семантике. E>И чем тут одно лучше другого я
С функциями это легче контролировать.
E>Мне платят за лучшие в мире ТТХ моего изделия...
Здравствуйте, Erop, Вы писали:
I>>Я ж говорю — колхоз. Есть вещи более эффективные нежели твои бумажки.
E>Я же говорю, от задачи зависит. Тупой кодинг автоматизирован довольно хорошо, а я не программист же. Я скорее математик
Я и говорю что ты не программист, твои каменты это однозначно демонстрируют.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Проблема действительно не в List, и чтение документации List'а тут ничем бы не помогло. Так как дефект был в аллокаторе.
Это не дефект, а свойство аллокатора. Если это называть дефектом, то любая особенность станет дефектом
Для внятного разруливания таких случаев нужны подсказки аллокатору, хоть где угодно, менеджед или нативный аллокатор.
Скажем, если вместо ручного копирования взять Array.resize и сделать так, что бы GC выделял память не последовательно, а скажем, примерно так — если блок находится в большом окне, выделить память в противоположном конце окна, то, внезапно, проблема с фрагментацией исчезнет и можно выделить больше чем N/3, что очевидно — четные аллокации будут в начале фрейма, нечетные — в конце. Середина будет оставаться свободной и выделить можно будет больше половины размера доступного АП.
Здравствуйте, Ikemefula, Вы писали:
E>>Я же говорю, от задачи зависит. Тупой кодинг автоматизирован довольно хорошо, а я не программист же. Я скорее математик I>Я и говорю что ты не программист, твои каменты это однозначно демонстрируют.
Это великолепно. Такое даже не прокомментируешь.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
S>>Если нужно именно на чанках — есть BigList в PowerCollections, больше ничего на глаза не попадалось, специально не искал.
EP>Вот, уже теплее "all page views=296189". Но судя по тому, что там, как они говорят, эффективные вставки в середину — это не прямой аналог std::deque. EP>Точно: "Getting or setting an item takes time O(log N), where N is the number of items in the list" против O(1) у std::deque. То есть это, по идее, аналог std::map<std::size_t,T>.
Биглист это точно отстой. Примитивная, на коленке, реализация деки рвет биглист как тузик грелку как раз потому что биглист это не аналог деки.
Здравствуйте, Ikemefula, Вы писали:
EP>>Проблема действительно не в List, и чтение документации List'а тут ничем бы не помогло. Так как дефект был в аллокаторе. I>Это не дефект, а свойство аллокатора. Если это называть дефектом, то любая особенность станет дефектом
Ну да, и кубическая сортировка — тоже не дефект?
I>Для внятного разруливания таких случаев нужны подсказки аллокатору, хоть где угодно, менеджед или нативный аллокатор.
кубической сортировке тоже можно дать подсказки типа "сделай вот такую перестановку".
I>Скажем, если вместо ручного копирования взять Array.resize и сделать так, что бы GC выделял память не последовательно, а скажем, примерно так — если блок находится в большом окне, выделить память в противоположном конце окна, то, внезапно, проблема с фрагментацией исчезнет и можно выделить больше чем N/3, что очевидно — четные аллокации будут в начале фрейма, нечетные — в конце. Середина будет оставаться свободной и выделить можно будет больше половины размера доступного АП.
Давай, включайся, уже вообще не интересно
Вот тебе картинка, * — это то, что занято list'ом:
[ | | | | | | | | | | | | | |*|*|*|*|*|*|*|*]
внешняя фрагментация нулевая
Покажи как ты увеличишь capacity вдвое
Здравствуйте, Ikemefula, Вы писали:
EP>>Точно: "Getting or setting an item takes time O(log N), where N is the number of items in the list" против O(1) у std::deque. То есть это, по идее, аналог std::map<std::size_t,T>. I>Биглист это точно отстой. Примитивная, на коленке, реализация деки рвет биглист как тузик грелку как раз потому что биглист это не аналог деки.
Поиски распространённого аналога std::deque продолжаются. Ведь что-то должно было вымучиться за 10 лет плохого аллокатора
Вот на ассемблере этого не было, динамику как то не сильно использовал, извини.
Но пока получается пересекаться только в КСВ 
