Статья отличная, правда; а вот сам TFS — говно говном, уж извините.
Плотно поработал с 2008, не знаю, может в 2010 и подлечили какие-то косяки, но в целом капец. Работа с сорс контролом на уровне VSS6.0 1997го года выпуска, постоянные проблемы с чекаутом, в 2005 стодии то пропадает, то появляются кнопки History и Annotate (типа blame в svn), работа через VPN превращается в ад и израИль.
Веб-интерфейс, кстате, тоже — туши свет; не работа, а #бля стоя в гамаке на лыжах. Про мерж уже сказали: диффы детектит препогано.
Я поясню — если не брать в расчет выбивающиеся из общего ряда «самые дорогие» и «самые дешевые» экземпляры, остальные на мой неискушенный взгляд одинаковы. Но правда такова: людям _хочется_, чтобы была возможность купить втридорога мегакабель, на котором будет показывать супир-хд. Не лишайте их этой радости.
А можно еще заморочиться, найти в сети шаблон процессорного ядра (например, аналога AVRTiny), и прошить его в ПЛИС. И тогда можно будет сравнивать 2 вычислителя.
Конечно, ATMega это не только ценный мех ядро, но и развитая периферия; тем не менее, сравнить вычислительные потенциалы будет возможно.
Плюс еще в том, что в ПЛИС можно прошить различные процессорные ядра, и посмотреть на поведение
А расскажите, чем ваш способ лучше использования Tarantino или Migrator.NET? А то вы во введении напедалили букв руками семь верст до небес, а сравнить с аналогами и не потрудились даже.
Красивая штучка. Пафосный ноутбук от Acer — это, как минимум, необычно.
«Мы живем в мире, полном красок!»..
Не знаю, как они, а мы, похоже, живем в мире, полном долбаных глянцевых бликующих экранов и поверхностей, и всем производителям, кажется, откровенно пофиг. И Packard Bell не стал приятным исключением.
Клеви :) Чем-то походит на 1С.
Сами делаем сейчас похожее решение под кастомный MDM (master data management) для электронных архивов.
Скажите, а как вы решали вопрос миграции данных? Может ли быть так, что после конструирования новой версии существующие данные будут препятствовать обновлению БД — скажем, мешают ключи или констрейнты?
А, т.е. у вас специфика приложения такая, что вы то работаете с множеством больших объектов — линейными списками, то требуется как можно больше адресного пространства под объекты из gen0-2, при том что самих списков нет (иначе память из LOH не была бы так досадно недоступна, т.к. была бы пристроена в дело).
Достаточно странно, но тогда я боюсь, что вы правы: нужна кастомная реализация IList[T] на чанках, что вы и предложили.
Среднестатистическая программа _очень_ редко занимается активными выделениями и освобождениями крупных объектов. Если помещать их вместе с остальными объектами в область поколений, это будет сильно фрагментировать кучу, вызывая ненужные движения GC в generation 0 (eden), которое переведет много 0-ых объектов в 1-ое поколение, куда GC придет гораздо позже. Поэтому крупные объекты размещаются отдельно от мелких.
Конечно, любой алгоритм управления памяти имеет «смертельную стратегию» выделения памяти, на которой он ведет себя худшим образом.
Для алгоритма с LOH, это следующая последовательность:
— большой объект в LOH (~MBs
— маленький объект в LOH (100 Kb)
:loop
— большой объект в LOH (больше предыдущего)
— маленький объект в LOH (100 Kb)
— удаление первого с начала маленького объекта
— jump :loop
Ну и как правильно заметили — предел 85К был установлен ~~10 лет назад. Пора бы уже и пересмотреть )
Теперь вы расскажите, как в Java борются с Permanent Generation Space, а также почему она не может выделять памяти у системы, когда ей не хватает :)
Нет, в этом случае проблема менее острая: списки начинаются с ~~0-вой длины и постепенно ресайзятся, так что фрагментация LOH будет стоять менее остро. По крайней мере, у нас в проектах так.
Кажется, мы друг друга не поняли. Я о том, что в случае хранения списка больших структур (а именно с этим возникают проблемы при использовании List, насколько я понял автора) сам объект вместе со структурами помещается в LOH.
При использовании: Dictionary в LOH помещается только Dictionary, который имеет размер ~~4N как раз за счет непрерывного массива _entries, в котором лежат ссылки, а не сами структуры
Если я не ошибаюсь, там используются buckets (пучки), списки списков, в результате одномерные массивы для индексов имеют характерный размер O(logN). Этого уже вполне достаточно.
Я бы вам посоветовал для этих целей воспользоваться последней vmmap от Руссиновича — чУдная утилитка в деле исследования распределения памяти процесса; понимает CLR.
Относительно адресного пространства — никакой разницы: не влезло — так не влезло, получите-распишитесь OutOfMemory :) Тем более с ростом LOH шансы на это серьезно увеличиваются.
Я просто отвечал товарищу выше, что насчет своп-файла он прав в той части, что из физической памяти этот блоб будет выдавлен.
То, что это, тем не менее, не решает проблемы, повторяться не стал — вы и так ниже все доступно расписали.
Плотно поработал с 2008, не знаю, может в 2010 и подлечили какие-то косяки, но в целом капец. Работа с сорс контролом на уровне VSS6.0 1997го года выпуска, постоянные проблемы с чекаутом, в 2005 стодии то пропадает, то появляются кнопки History и Annotate (типа blame в svn), работа через VPN превращается в ад и израИль.
Веб-интерфейс, кстате, тоже — туши свет; не работа, а #бля стоя в гамаке на лыжах. Про мерж уже сказали: диффы детектит препогано.
Конечно, ATMega это не только
ценный мехядро, но и развитая периферия; тем не менее, сравнить вычислительные потенциалы будет возможно.Плюс еще в том, что в ПЛИС можно прошить различные процессорные ядра, и посмотреть на поведение
Не знаю, как они, а мы, похоже, живем в мире, полном долбаных глянцевых бликующих экранов и поверхностей, и всем производителям, кажется, откровенно пофиг. И Packard Bell не стал приятным исключением.
Сами делаем сейчас похожее решение под кастомный MDM (master data management) для электронных архивов.
Скажите, а как вы решали вопрос миграции данных? Может ли быть так, что после конструирования новой версии существующие данные будут препятствовать обновлению БД — скажем, мешают ключи или констрейнты?
Достаточно странно, но тогда я боюсь, что вы правы: нужна кастомная реализация IList[T] на чанках, что вы и предложили.
Среднестатистическая программа _очень_ редко занимается активными выделениями и освобождениями крупных объектов. Если помещать их вместе с остальными объектами в область поколений, это будет сильно фрагментировать кучу, вызывая ненужные движения GC в generation 0 (eden), которое переведет много 0-ых объектов в 1-ое поколение, куда GC придет гораздо позже. Поэтому крупные объекты размещаются отдельно от мелких.
Конечно, любой алгоритм управления памяти имеет «смертельную стратегию» выделения памяти, на которой он ведет себя худшим образом.
Для алгоритма с LOH, это следующая последовательность:
— большой объект в LOH (~MBs
— маленький объект в LOH (100 Kb)
:loop
— большой объект в LOH (больше предыдущего)
— маленький объект в LOH (100 Kb)
— удаление первого с начала маленького объекта
— jump :loop
Ну и как правильно заметили — предел 85К был установлен ~~10 лет назад. Пора бы уже и пересмотреть )
Теперь вы расскажите, как в Java борются с Permanent Generation Space, а также почему она не может выделять памяти у системы, когда ей не хватает :)
При использовании: Dictionary в LOH помещается только Dictionary, который имеет размер ~~4N как раз за счет непрерывного массива _entries, в котором лежат ссылки, а не сами структуры
Я просто отвечал товарищу выше, что насчет своп-файла он прав в той части, что из физической памяти этот блоб будет выдавлен.
То, что это, тем не менее, не решает проблемы, повторяться не стал — вы и так ниже все доступно расписали.