Наткнулся на забавную штуку.

Есть большой класс — кусок query execution, в некотором смысле state machine. Соответственно, в нём есть мембер переменная enum State : int, по которой делают switch и в которую делают store в этом же switch.

А ещё код был примерно такой, и я заметил, что _unused не используется — и удалил:

void* ...;  
int _unused = 0;  
State _state = 0;  
void* ...;  

Прогнал тесты, все такое. Тесты запускаются в релизе с дебажными ассертами, но на физически известной мне машине (которую я мог зафиксировать).

И тут, собственно, причина, почему я пишу: я заметил, что тесты стали проходить медленнее — процентов на 5-10 от обычного времени (42 vs 46 минут). Ну, подумал, может, совпадение, но решил запустить ещё раз с/без патча. Результаты повторились (к сожалению, это было не единственное изменение в PR).

Пошёл смотреть, какие именно тесты стали медленнее, и заметил, что в половине из них разница в пределах погрешности, но многие тесты кверинга стали заметно медленее.
В общем, методом пристального взгляда я нашёл это место и позапускал с _unused и без. И действительно оказалось, что на ryzen 4 (по крайней мере, 7950X) код с чтением и записью 4 байт по адресу с alignment 4 работает лучше, чем с alignment 8.

Есть у кого идеи, почему?
Возможно, это какой-то затуп store-to-load forwarding-a, но как-то неочевидно, почему это происходит именно в таком сетапе.

Если что, store-to-load forwarding — это оптимизация в процессорах, когда ты пишешь в память x (<= 16?) байт, а потом читаешь <= x байт из того же места — можно не ждать завершения записи.
Неудивительно, что, как и многие другие оптимизации процессора, она работает не всегда. Например, чтение меньшего числа байт (по крайне мере с ненулевого оффсета) обычно работает медленнее.

Но в данном случае, казалось бы, разницы быть не должно: пишут и читают одинаковое число байт, по одинаковому оффсету.

Бтв с учетом новостей чет вспомнилось

JeMalloc has long history and it is well maintained and constantly improved.

https://github.com/ClickHouse/ClickHouse/issues/34157

Я не верю, но возможно сюда что-то накоммитят: https://github.com/facebook/jemalloc

Три месяца назад я ушел из YDB, чтобы вместе с коллегами по ArangoSearch создать новую базу данных — SereneDB.

Если описывать очень кратко, то SereneDB, это база данных которая хочет совместить:
1. Продвинутый search-engine, аналог Lucene, только эффективнее и быстрее
2. Сolumnar storage и query execution, сделанные с учетом опыта modern OLAP систем
3. Удобное ACID хранение в RocksDB. На текущий момент аналитический движок это отстающий во времени snapshot транзакционного хранилища.
4. И дать к этому всему доступ из Postgres экосистемы: postgres sql grammar, functions, types, psql, драйвера, pgadmin, и тд.

Мы сейчас нанимаем первых сотрудников — инженеров, чтобы вместе построить эту систему, подробности вакансии по ссылке.

P.S. single-node заопенсурсим в скором времени

https://github.com/orgs/community/discussions/163932
гитхаб наконец-то обновил UI для ПР-ов, по ощущениям правда бодрее стало. Особенно левая панель с file tree.
правда только 300 файлов пока...

https://aws.amazon.com/blogs/aws/introducing-amazon-s3-vectors-first-cloud-storage-with-native-vector-support-at-scale

Звучит конечно прикольно, более дешёвый стор большого количества векторов по которому работает ann поиск.

А есть уже какие-то известные детали реализации/etc?

Я попытался побыстрому найти инфу об интеграции с opensearch в их репе или их knn репе, но безуспешно

Наиболее близкое issue, которое я нашёл, это:
https://github.com/opensearch-project/k-NN/issues/2391

Однако, насколько я понимаю, там речь идёт о внешнем билде индекса, а не о внешнем кверинге

Решил почитать перед сном коммиты в llvm libc++, а то там llvm 21 вышел, думаю может обновиться. И нашел коммит, который фиксит любопытное issue.

Вот здесь хорошая выжимка, но если совсем кратко:
1) в llvm 20 сделали abi break на кучу стандартных контейнеров, заметили спустя полгода, что делать с llvm 20 пока не решили) А ещё с gcc фикс не работает так как баг в gcc.
2) [[no_unique_address]] для одинаковых типов, но разных филдов работает весьма неочевидным образом, если вы тот самый любитель поликонваться динамически будьте аккуратны хотя почему вы при этом используете llvm libc++ для меня загадка


Ну и раз уж что-то пишу, по-моему стоят упоминания
1) в abseil поменяли load factor с 7/8 на 27/32
2) в той же самой llvm libc++, multimap/set::find оптимизировали и он перестал возвращать тоже самое что lower_bound
3) ещё из забавных оптимизаций: в abseil и в llvm libc++ перестали считать хеш для вставки в пустую хештаблицу

Вообще вот странная штука, больших проектов на C++, C, Rust которые делают базы данных или около довольно много (например стартапы, да и в bigtech).
Но при этом тех которые делают хотя бы следующие вещи:
1. Запускают свои тесты с 4 санитайзерами
2. Имеют coverage репорт
3. Имеют perf тесты и репорт

Как будто единицы, почему так?
(ну достаточно часто есть какой-то минимальный, криво сделанный сабсет описанного)

Это же что-то в целом довольно базовое, в целом для любого проекта.
Базы данных это вроде бы что-то довольно низкоуровневое, где цена багов/регресии может быть высока.
Да и делается не так сложно.
Я бы еще понял если бы сейчас был какой-нибудь 2015, но сейчас 2025.
В общем где эта, "культура разработки"?

Привет, мы частично заопенсорсили текущий код нашего проекта -- SereneDB. Это оказалось тяжелее чем хотелось бы :) https://github.com/serenedb/serenedb

Большую часть ближайших тасок будем делать в опенсорсе. В целом проект ещё далековат от релизного состояния, но "бета" с первыми публичными бенчмарками планируется к концу февраля.

Пара интересных моментов, которые можно посмотреть уже сейчас, связаны с архитектурой:

=> pg wire protocol (postgres drivers and tools like psql)
=> libpq_query parser (postgres query syntax)
=> axiom query frontend (runner + optimizer)
=> velox query execution
=> rocksdb | search

На мой взгляд, наиболее любопытны два аспекта:

axiom -- библиотека оптимизатора для velox, которую недавно начала делать meta. Мы активно подключились к разработке, примерно половина коммитов за последние 3 месяца наши. Кстати в нашем форке есть пока отсутствующие у них "фичи": window функции, cross джоины, etc. Да, проект пока ещё совсем сырой, но мне кажется библиотека оптимайзера это классная идея, так как если с execution оно более менее устоялось, с оптимайзерами все не так однозначно

Второй аспект, но не по значению, поисковый движок, который изначально был сделан по дизайну lucene, но со временем эволюционировал во что-то ближе к гибриду с колоночным базам данных.

Кстати если вы не особо разработчик баз данных, у нас есть разные прикольных чисто инженерные моментов:
1) build from source (кроме libc, там пока не густо), как следствие например мы можем легко пропатчить libc++ и используем memory sanitizer
2) А ещё именно это позволяет легко получать static binary
3) И да у нас C++26, clang, llvm стек в общем
4) А для concurency юзаем YACLib
5) Да и в целом есть много прикольных решений про которые расскажем немного позже, например, сериализации структур с помощью boost pfr или кастомные локфри iobuf-ы

В любом случае буду рад всем кто поддержит наш пока небольшой проект с помощью PR/issue/звёздочек!

Мы тут написали небольшой пост про свой iobuf который юзаем для реализации postgres протокола:
https://www.serenedb.com/blog/io-buffer

tldr: как мне кажется ключевых моментов три
1) он chunked => отсутствуют большие аллокации/копии данных
2) он простое wait-free
3) в него можно записать что-то потом (uncommitted, в блоге написано подробнее), это важно чтобы сначала сериализовать что-то и только потом записать размер этого в префиксе.


Вообще изначально думали заюзать folly iobuf или absl cord, но коллега очень не хотел мьютекс в таком простом кейсе добавлять :)

Собственно код самого буфера и проекта по ссылке
https://github.com/serenedb/serenedb
Буду рад всем кто поддержит нас с помощью PR/issue/звёздочек!