1. Давно хотел померять std::function альтернативы, так как бенчмарки которые видел были очень outdated.
Взял микробенчмарк из abseil и адаптировал.
Не ноутная amd железка, clang 19, libc++ 19 (abi v2!), около транк для остальных либ

Benchmark                                   Time             CPU   Iterations
-----------------------------------------------------------------------------
BM_TrivialStdFunction                    1.11 ns         1.11 ns    622220945
BM_TrivialAbslFunctionRef                1.10 ns         1.10 ns    637419510
BM_TrivialAbslAnyInvocable               1.85 ns         1.85 ns    377698611
BM_TrivialFollyFunctionRef               1.10 ns         1.10 ns    635925877
BM_TrivialFollyFunction                  2.03 ns         2.03 ns    345277532
BM_TrivialBoostFunction                  1.31 ns         1.31 ns    535099651
BM_TrivialFu2Function                    5.27 ns         5.27 ns    133167133
BM_TrivialFu2UniqueFunction              5.07 ns         5.07 ns    137751417

BM_LargeStdFunction                      11.0 ns         11.0 ns     63490131
BM_LargeAbslFunctionRef                  1.10 ns         1.10 ns    635590925
BM_LargeAbslAnyInvocable                 9.20 ns         9.20 ns     76082731
BM_LargeFollyFunctionRef                 1.10 ns         1.10 ns    635390697
BM_LargeFollyFunction                    11.1 ns         11.1 ns     62981528
BM_LargeBoostFunction                    11.9 ns         11.9 ns     58833683
BM_LargeFu2Function                      10.5 ns         10.5 ns     66229864
BM_LargeFu2UniqueFunction                10.7 ns         10.7 ns     65711158

BM_FunPtrStdFunction                     1.42 ns         1.42 ns    472854986
BM_FunPtrAbslFunctionRef                 1.28 ns         1.28 ns    545957263
BM_FunPtrAbslAnyInvocable                3.77 ns         3.77 ns    185835648
BM_FunPtrFollyFunctionRef                1.28 ns         1.28 ns    545872297
BM_FunPtrFollyFunction                   2.03 ns         2.03 ns    345335520
BM_FunPtrBoostFunction                   1.49 ns         1.49 ns    470280007
BM_FunPtrFu2Function                     5.98 ns         5.98 ns    117100264
BM_FunPtrFu2FunctionView                 1.29 ns         1.29 ns    541223933
BM_FunPtrFu2UniqueFunction               6.35 ns         6.35 ns    110392385

BM_TrivialArgsStdFunction               0.930 ns        0.930 ns    752811771
BM_TrivialArgsAbslFunctionRef           0.934 ns        0.934 ns    752592908
BM_TrivialArgsAbslAnyInvocable           1.11 ns         1.11 ns    630181056
BM_TrivialArgsFollyFunctionRef          0.952 ns        0.952 ns    743261325
BM_TrivialArgsFollyFunction             0.938 ns        0.938 ns    753110708
BM_TrivialArgsBoostFunction              1.12 ns         1.12 ns    627254290
BM_TrivialArgsFu2Function                2.24 ns         2.24 ns    312131551
BM_TrivialArgsFu2UniqueFunction          2.24 ns         2.24 ns    312115556

BM_NonTrivialArgsStdFunction             4.30 ns         4.30 ns    162679265
BM_NonTrivialArgsAbslFunctionRef         4.65 ns         4.65 ns    150336051
BM_NonTrivialArgsAbslAnyInvocable        4.29 ns         4.29 ns    162800037
BM_NonTrivialArgsFollyFunctionRef        4.65 ns         4.65 ns    150487034
BM_NonTrivialArgsFollyFunction           4.29 ns         4.29 ns    163183216
BM_NonTrivialArgsBoostFunction           7.48 ns         7.48 ns     93603218
BM_NonTrivialArgsFu2Function             5.94 ns         5.94 ns    117998045
BM_NonTrivialArgsFu2UniqueFunction       6.12 ns         6.12 ns    118745273

Чтобы понимать погрешность можно смотреть на absl vs folly FunctionRef, там по сути одинаковый код
Удивило что
1. std::function весьма хорош (в минусы запишем то что не умеет в move only lambda, и const/noexcept в сигнатуре)
В случае abi v1, оно все еще неплохо, но уже похуже abseil/folly
2. fu2 такой фу фу (зато умеет в overload-ы, fu2::function_view работает только для function pointer?)
3. absl::AnyInvocable в случае function pointer, хотя вроде бы в их коде есть special case под это

2. Тут в асио был фикс https://github.com/chriskohlhoff/asio/commit/b6110cffea56fee4d0eb1b674d5a5a63f4523413
Чисто случайно узнал, что он пофиксил ишью, которое я создавал давно и даже предлагал фикс https://github.com/chriskohlhoff/asio/issues/1521)
Почему так сложно написать: "привет, я пофиксил <commit-hash>"?
Вообще нужно конечно не пользоваться asio, тут скорее моя вина что какой-то фикс решил в апстрим занести

https://github.com/jemalloc/jemalloc а кто-нибудь знает, почему jemalloc улетел в архив?

При том насколько я понял, овнер убирает архив, делает коммит, и опять ставит архив

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

Есть большой класс — кусок 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++ перестали считать хеш для вставки в пустую хештаблицу