?

Log in

AlexWWolf's live journal

Свежие записи

Январь, 1, 2015

2015 - год быка

Верхняя запись
Поделиться
 Это специальная, вынесенная наверх запись - для того, чтобы можно было в комментах задать мне вопрос на произвольную тему. Или просто чего-нибудь написать. Ну и пусть будет деление по годам.

Июль, 22, 2015



Снято в Москве, Белорусский вокзал, поезда пригородного сообщения.

Июль, 10, 2015

Цитата дня

Поделиться
xxx: хранить в полях значения через запятую и парсить их на лету - суть устилание пола граблями. Добавьте таких строк пару миллионов и попробуйте сделать выборку. Даже объяснять ничего не надо будет, грабли сами прилетят и все растолкуют.

(r) bash.im

Июнь, 17, 2015

Хотя выделение множества мелких объектов - тест не профильный для ранее представленного page pool allocator, тем не менее, решил его провести. И вот не очень ожидаемые результаты:

PagePoolAllocator
Мин. время аллокации, мс.0
Макс. время аллокации, мс.2
Сум. время аллокации, мс.44782
Средн. время аллокации, мс., до тыс. долей0.001
Private bytes после аллокации~3 Гб

Результаты освобождения памяти:
PagePoolAllocator
Мин. время деаллокации, мс.0
Макс. время деаллокации, мс.0
Сум. время деаллокации, мс.39660
Средн. время деаллокации, мс., до тыс. долей0.001

Получается, оптимизации для мелких объектов в CSmallObjectAllocator дали очень небольшой результат. Что ж, пока все-таки оставлю в использовании два аллокатора - возможно, потом удастся довести оптимизацию до должного уровня.

Июнь, 15, 2015


Page pool allocator достаточно универсален, что работать с самыми разными объектами. Обратная сторона этой универсальности - довольно большой расход памяти на служебную информацию. На каждый заголовок занятого блока расходуется по 32 байта (для сборки x64). Если мы имеем дело с небольшими объектами, перерасход памяти может получиться весьма значительный. Например, для указателей x64 - в 5 раз. Если же этих объектов весьма много, то этот перерасход может стать критическим.

Таким образом, потребовался специализированный аллокатор для больших объемов однотипных мелких объектов. К сожалению, тут пришлось сойтись на компромиссе между экономным расходованием памяти и скоростью работы. Совсем без заголовков занятых блоков обойтись не удалось, однако размер этого заголовка удалось снизить до 16 байт (адрес исходной страницы памяти, завернутый в структуру). Основная идея архитектуры аллокатора - использовать набор связанных страниц и на каждой странице - битовую карту занятых и свободных блоков. Один байт карты описывает 8 блоков.

В остальном, он такой же, как и предшествующий аллокатор, так что код приводить не буду. Главное - результаты тестирования. Для выделения памяти (те же 44739242 объекта по 24 байта в массиве):

CSmallObjectAllocator
Мин. время аллокации, мс.0
Макс. время аллокации, мс.2
Сум. время аллокации, мс.36247
Средн. время аллокации, мс., до тыс. долей0.001
Private bytes после аллокации~2.5 Гб

Результаты освобождения памяти:
C++
Мин. время деаллокации, мс.0
Макс. время деаллокации, мс.0
Сум. время деаллокации, мс.32238
Средн. время деаллокации, мс., до тыс. долей0.001

Итого:
  • Скорость выделения памяти сопоставима со стандартной для C++
  • Экономия памяти - наилучший результат для всех трех тестов
  • Освобождение памяти - на два порядка в среднем лучше, чем у стандартного C++ delete, хотя и хуже, чем у C#

Вывод: отличный результат, с учетом того, что фрагментация памяти здесь отсутствует.

Для передачи данных через сеть используется концепция потока данных: массива байт неопределенной, изменяющейся длины. При этом становится затруднительно использовать аллокаторы, рассчитанные на фиксированную длину объекта данных. Для решения возникших проблем, я написал класс CChunkedBuffer, использующий ранее написанный page pool allocator.

Продолжение здесь...Свернуть )

Июнь, 7, 2015

Рассмотрим один интересный частный случай: выделение множества однотипных мелких объектов. А именно: выделение и освобождение 1 Гб памяти в виде объектов по 24 байта. Число 24 здесь, в общем-то, взято с потолка - основная идея в том, что это мелкие объекты, но не настолько мелкие, как базовые типы данных.

Продолжение здесь...Свернуть )

В качестве вывода мы получаем чудную-дивную картину: менеджер памяти C++ показывает скорость работы меньше на 1-3 ПОРЯДКА (!!!), чем менеджер памяти C#. В указанных условиях, разумеется.

Май, 7, 2015

Пару недель назад закончил разработку собственного менеджера памяти (он же кастомный аллокатор, custom allocator) для C++. Ну, то есть я думал, что закончил. Как показали первые попытки его использования, работа сделана примерно наполовину, но об этом потом и отдельно.

Написан он на основе статьи на GameDev. Поясню, зачем эта штука вообще нужна: это для борьбы с фрагментацией памяти на высоконагруженных системах. К слову сказать, прогнал я для него простейшие тесты и, как минимум, убедился, что он работает. Так что выкладываю далее код с некоторыми комментариями. Если вдруг будут идеи как сделать лучше - рад буду услышать критику.

Продолжение здесьСвернуть )

Апрель, 14, 2015

Цитата дня

Поделиться
xxx: Что делать если кот пробежал по клавиатуре и в программе всплыла ошибка которую я ни разу не видел и не выходит повторить?
yyy: Устроить кота на работу тестировщиком.

(r) bash.im

Март, 19, 2015

Жизненное

Поделиться
Вчера какой-то парень зашел при мне в аптеку и попросил жидкий азот. Поржал.

жж счетчик - lj counter

Разработано LiveJournal.com