Тимиркаич

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

И вот тут выяснилось, что запрос, который полностью берёт все данные из кэша в Виниле работает в несколько раз медленнее, чем аналогичный запрос в PostgreSQL. Существенной частью проблемы была реализация serializable: она требовала, чтобы любое чтение учитывалось в transaction working set, и это добавляло значительные накладные расходы. PostgreSQL по умолчанию работает в snapshot isolation, и чтения никаких следов не оставляют.

Так сначала мы приговорили реализацию транзакционного менеджера в Винил, и я реализовал snapshot isolation. Одно это дало прирост в 10-15% в pico_ycsb тестах и убрало огромное количество по большей части вредных read-write конфликтов. Но одно дело реализовать уровень изоляции - snapshot, другое - реализовать кэширование для него.

Кэш в Виниле сделан так, как нигде больше: ни в PostgreSQL, ни в RocksDb, ни в CockroachDB, никто и нигде больше не кэширует строки - все кэшируют страницы, или мутации (изменения). В Виниле кэш хранит готовые к отдаче результаты последней версии данных.
Но при чтении через snapshot isolation у нас нет уверенности, что мы имеем дело с последней версией данных, и кэш наполнить нечем. И вот, чтобы реализовать поддержку кэширования при чтении через снапшот пришлось "приговорить" старый кэш.

В итоге ре-имплементации на определённых сценариях чтения из кэша ускорились в 44 раза. Ссылка на коммит, там немало слов, осознать что нужно поменять и почему было непросто само себе. Ну и кэширование snapshot isolation чтений тоже добавили, да.

Сейчас же я знаимаюсь нативной поддержкой TTL (time-to-live) для Мемтикс и Винил. И пытаюсь разршить уже совсем другое противоречие. Напишу о нём отдельно.

Новая стоимость кода

Можно ли оценивать новую стоимость кода в пересчете на токены? TL;DR: делать в лоб не совсем правильно, единой формулы нет, но в целом оценить можно.

Все LLM по API продаются по выходным/выходным токенам. Есть соблазн грубо оценить стоимость сгенерённого кода через стоимость выходных токенов. Подписки этот подход ломают, но как будто подписочная модель наиболее “честная” для оценок.

Перевод строк кода в токены не такой-то простой, берем такой код:


if (user.status_code === 404) {


В этой строке — 14 токенов по алгоритму BPE:
- отступ в начале строки
- if
- открывающая скобка
- user
- точка
- status
- подчеркивание
- code
- пробел перед оператором
- оператор сравнения ===
- число с пробелом 404
- закрывающая скобка )
- открывающая скобка { с пробелом
- перенос строки

А в сгенерённом коде еще будут комментарии, длинные названия переменных и функций. Поэтому если очень грубо оценивать “стоимость кода в пересчете на выходные токены”, то на 1 строку кода надо брать не 10, а скорее 20 токенов, и 1 млн выходных токенов получится не 100.000 строк кода, а меньше, наверное нормальной оценкой взять 50.000 строк.

Кстати, 50.000 строк — столько приходилось на 1 программиста в Badoo в лучшие годы, кода кодовая база сильно росла. То есть это даже не “в год”, это сколько на 1 сотрудника приходилось строк кода в репозитории. И затем эта цифра снижалась.

А в реальности всё сложнее. В агентном кодинге вход тоже важен, контекст перечитывается, стоимость добавляет и инпут, и процент попаданий в кэш. Допустим есть коэффициент, на который надо умножить цену миллиона выходных токенов. Он не универсальный, зависит и от “обвязки” / агента, и от модели.

Я тут поколдовал с помощником, не буду приводить полный расчет, короче, этот K по оценкам от 3 до 5, причем ниже у американских флагманов, и выше у китайских. Но даже с такими оценками стоимость 50.000 строк кода получается следующей:


Модель Out Real K
Fable 5 $50 $145 2.9
GPT-5.6 Sol $30 $78 2.6
Opus 5 $25 $73 2.9
Sonnet 5 $10 $29 2.9
Qwen 3.8 Max $6 $27 4.5
GLM-5.2 $4.40 $23 5.3
DeepSeek V4 Pro $0.87 $3.2 3.7
DeepSeek V4 Flash $0.28 $1.1 4.0


Выводов не будет, просто оставлю вас с размышлениями о текущей стоимости написания 50.000 строк кода - кодовой базы, которая приходилась на 1 разработчика в проекте с миллиардной капитализацией.

🔥за новую эру “наш код не стоит ничего”
👍за дипсик

#cpp

Back to Back 2026 (который был C++ Zero Cost Conf).

Я выбрал несколько докладов из всех 4х треков. Если доклад не выбран, это не значит, что он плох. Возможно он не зашёл мне темой, а возможно не так интересен, как другие. Навалить вам просто все доклады мне не очень хотелось.

0. 9 миллиардов этажей concurrency. Андрей Аксёнов.

Доклады бывают в разных форматах. Этот доклад не должен глубоко раскрывать тему, на мой взгляд. Он скорее должен дать вам много разных слов, с которыми вы должны пойти разбираться.
Ну и это Андрей Аксёнов со своей подачей. Хулиганской.

1. Трассирую и профилирую — бесплатно. Александр Емеленко.

Александр рассказывает про измерение времени и запись логов жоска эффективно, двигаясь от базовичкового медленного варианта к быстрому наносекундному.

2. Building the tiniest pomodoro app. Miloš Anđelković.

Хороший доклад для понимания техник уменьшения размера ваших бинарных файлов. От отказа от зависимостей и правильной компиляции до переписывания всего совсем иначе.

3. Profile-Guided Optimisation. Taming the pitfalls in the name of performance. Alexander Zaitsev.

Я особо раньше не смотрел доклады про PGO, потому что они сразу куда-то в дебри уходят. Как будто для них нужен уже солидный такой контекст.
А вот тут не так. Тут Alexander рассказывает про базовые понятия, проблемы, кто что умеет, как делать, профит. Такое солидное введение в тему.

4. Google's Highway Library for SIMD Programming — Does It Deliver the Promise? Ivica Bogosavljevic.

Ivica рассказывает про гугловую SIMD либу. В местах, где она хороша (как и заявлено), и где не очень хороша и не справляется со своими задачами (или справляется, но не очень хорошо).

5. Microseconds in Network Code. Artur Soloviev.

Artur рассказывает про несколько вариантов работы с сетью, чтобы было быстро.

6. To 264 and Beyond: Modern Approaches to Distributed Identifier Algorithms. Mons Anderson.

Тут Mons рассказывает про огромное количество (штук 15 может) разных distributed ID. Их устройство, некоторые принципы работы, tips & tricks для разработки своего решения. Плюсы и минусы разных подходов.

Как один из критериев ещё обсуждалась длина закодированого ID. Это важно, ведь если ваши ID в огромнющей системе сделать на байт короче, это может вылиться в Гигабайты экономии.
А ещё это важно, потому что некоторые строки (покороче) попадают в SSO буфер, а некоторые нет. Мета, например, когда-то ровно по причине увеличения SSO буфера переходила на свой fbstring. А потом вернулась на стандартную строку, когда clang научился давать 23 символа в SSO буфере из коробки.
Возможно, вы можете пойти и поменять тип для хранения ваших ID на small_string или как оно у вас называется. И получить какой-нибудь профитик.

Важные навыки менеджера AI эры:
— простыню из нейронки отправлять в ответ заказчику не мгновенно, а выждав хотя бы 10 минут;
— удалять фразу в конце "хотите я доработаю это под конкретного клиента?"

Оригинал

🍻 C++ туса уже на носу — не пропусти!

Господа и дамы, напоминаем: шестая встреча SPb C++ уже в следующий четверг, так что самое время освободить вечер 👇

Когда: 13.08.2026 20:00
Где: Failover Bar, 2-я Советская улица, 18 Санкт-Петербург
Что: SPb C++ Drinkup #6

Наконец-то услышим зачем же плюсы а мире 1С от @bapho_bush