Гибридные логические часы (HLC, Hybrid Logical Clock)

Немного другая ветвь развития часов Лэмпорта, которая привязывает их к реальному времени, при этом сохраняя корректность

Каждый узел хранит два поля - физическое время (локальное время системы) и логический счетчик а-ля Лэмпорт

Далее:

- локальное событие: узел читает свое текущее системное время. Если это время больше сохраненного физического времени, то обновляем его и сбрасываем логический счетчик на 0. Иначе, то есть если системное время не сдвинулось или пошло назад, хранимое значение времени не обновляем, а лишь увеличиваем счетчик, как в часах Лэмпорта

- отправка сообщения: узел обновляет свои часы по описанному выше алгоритму, после чего прикрепляет пару их значений к сообщению

- получение сообщения: хранимое физическое время узла устанавливается равным максимуму локального времени и времени из сообщения. Если физическое время совпало, то счетчик приравнивается максимуму между счетчиком узла и счетчиком из сообщения, плюс единица. Иначе счетчик обнуляется

Такой алгоритм гарантирует, что HLC всегда возрастают, даже при обратном ходе системных часов.

Главная же особенность подхода - при условии хотя бы примерной синхронизации локальных часов узлов с реальным временем, HLC тоже всегда будут близки к реальному времени, в отличие от часов Лэмпорта или векторных часов. Это позволяет использовать их в системах, где необходимо упорядочивание по реальным таймпштампам, но требуется и надежное логическое время

HLC используются в CockroachDB, YugabyteDB, TiDB, Cassandra, MongoDB, и многих других СУБД

TrueTime, используемый в Google Spanner, их распределенной SQL СУБД

Здесь способ работы со временем разрабатывался под конкретную СУБД, с учетом требований распределенной работы с охватом множества датацентров по всему миру

Время представляется не как конкретное значение, а допустимый интервал реального времени [earliest, latest], в котором операция может быть произведена. Сравнение времени операций производится по этим же интервалам - одна операция строго раньше другой только тогда, когда ее latest граница временного интервала меньше earliest границы интервала другой

На этом построена вся система коммитов транзакций в Google Spanner - когда транзакции присваивается время коммита, система ждет, пока latest граница интервала гарантированно окажется в прошлом, чтобы исключить вероятность непредвиденного появления другой транзакции в этом промежутке времени

Но тут легко заметить один огромный нюанс - вся система построена на надежных определениях границ этих временных интервалов, с привязкой к реальному времени. А мы уже выяснили, что надежно этого не сделать. Как же Google этого добился?

Очень просто - Spanner требует атомные часы в каждом датацентре с GPS ресиверами, и вся система опирается на них)

Поэтому для простых смертных данный подход неприменим

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

Теперь же текст сдан и утвержден, дальше только защита через пару недель - можно слегка выдохнуть и вспомнить про канал.

Из-за страшной нехватки времени решил впервые попробовать ИИ агентов для кода. Впечатления очень смешанные.

Во-первых, само сравнение агентов - пробовал OpenAI Codex на GPT-5.5, Claude Code на Opus 4.7 и GLM-5.1

по субъективным ощущениям, кодекс потупее, но с неплохими лимитами и большей тенденцией прислушиваться к командам.
Клод поумнее, но любит выкручиваться, пытаться извернуться, найти дыры в формулировках и воспользоваться ими. И лимиты выжирает просто мгновенно, иногда меньше десяти минут работы на Pro тарифе - не зря в народе его называют Proбник
GLM приятно удивил - стоит дешевле обоих конкурентов, работает без сетевых манипуляций из РФ, лимиты раза в три больше клода. Чуть тупее клода, чуть умнее кодекса по ощущениям. В итоге больше всего именно им пользовался

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

Я нагенерил 12к строк кода кодексом и клодом. Они проходили все тесты, работали корректно и тд. А потом я заглянул в этот код - и волосы дыбом встали (это учитывая, что были даны четкие указания, как писать. Которые агент проигнорировал). В итоге из этих 12к строк пришлось больше 8к переписать врукопашную - и приложение сразу перестало изнутри походить на шизоидное спагетти, похудело в три раза и ускорилось раз в десять

В общем, не совсем бесполезная хрень, но и совсем не серебряная пуля, которая всех нас заменит)

Отдельные лучи поноса посылаю нашей чудесной системе Антиплагиат. Давно такого маразма не встречал

Это убожество подчеркивает титульный лист и оглавление как плагиат. Да, даже имя научного руководителя я откуда-то украл!

А потом в тексте оно названия глав, подписи таблиц и объяснения алгоритмов помечает как "замаскированную ИИ генерацию"

Какой же я, видимо, негодяй, сгенерировал слово "Введение" в заголовке!

В итоге пришлось текст диссертации урезать со 104 страниц до 81, вырезав львиную долю технических подробностей - и сразу процент "ИИ генерации" упал с 17% до 0%

Забавный абсурд - чтобы пройти антиплагиат с технической работой, нужно вырезать из нее все технические подробности)

Но это и неудивительно, когда каждая проверка стоит немалых денег, и чем больше подсветишь "плагиата" в работах, тем больше студентики будут вынуждены их редактировать, раз за разом снова кидать на проверку, и снова платить. Очень выгодно!

Решил тут раскопать, как устроен рендер в Vintage Story

Я знал, что там C# с OpenGL 3.3 через OpenTK, но захотелось заглянуть под капот посильнее - все же у игры отличная оптимизация при неплохом визуале

Благо все их шейдеры лежат в открытом текстовом виде, и раскопать их довольно просто

Всего около 35 шейдеров

Что было найдено:

- Данные вершин плотно упакованы, одна вершина занимает ровно 4 байта. В шейдерах написано разжатие данных из бит этой запаковки

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

- Если на устройстве доступен OpenGL 4.3, то делается альтернативный рендер через SSBO (в простонародье - storage buffer), который передает в шейдеры данные по квадам, а не вершинам, восстанавливая их уже там по vertex id. Экономит память в 4 раза.

- Три вида тумана для эффектов и оптимизаций

- рендер прозрачных объектов без привязки к порядку отрисовки (OIT) - алгоритм Мешкина для взвешенного смешивания

Продолжаем обзор шейдеров Vintage Story

- 13 видов ветра для разной растительности

- рендер жидкостей и подводного мира через четверть разрешения, отдельный расчет пены

- Объемные облака через DDA. Сами в 2д текстурах, марширующие лучи дают объем

- процедурное северное сияние через многослойный 3д шум

- аж целых 4 метода борьбы с z fighting: сдвиг по w компоненте в данных вершины, перезапись глубины для предметов в руке, ручной оффсет для хайлайтов и отдельный юниформ с оффсетом глубины для первого лица

- плавные LOD

- двойные каскадные карты теней - одна для деталей перед камерой, вторая для дальних объектов

- много пост-процессинга - Bloom, SSAO, FXAA для сглаживания и еще несколько эффектов. Для оптимизации вместо полноэкранного квада рисуется один полноэкранный треугольник, лишнее отсекается вьюпортом

- форвард рендер, с использованием части идей деферреда для постобработки. Три типа освещения, взвешенное смешивание на выходе

Можно было бы еще больше рассказать, но слишком много получится

А после копания в шейдерах Винтажки я сел и подумал - что бы дало переписывание этого рендера на wgpu? В конце концов, она тоже доступна для C# через Silk.NET

Потому что по коду прям видно, что ребята старались, но им на каждом шагу втыкала палки в колеса ограниченность OpenGL 3.3, которая им нужна для портативности

- Доступ к компьют шейдерам позволил бы очень сильно улучшить рендер пайплайн. Например, в оригинале каждый пост-эффект - это отдельный фуллскрин треугольник в отдельном прогоне, который вынужден костылить жалкое подобие компьютов на фрагментном шейдере. Из 13 шагов рендер пайплайна 8 можно сделать настоящим компьютом, избавившись от лишней растеризации, лишних вершин, лишней возни с текстурами и тд. Один только SSAO при переходе на компьюты позволит делать одно чтение текстуры на воркгруппу вместо 9 чтений на пиксель

- Гарантированная доступность сторадж буферов дала бы оптимальный рендер везде, а не только там, где есть OpenGL 4.3 (на устройствах Apple, на части Android смартфонов, в браузере нет). Экономия памяти в 4 раза на ровном месте на каждый квад. Еще бы снялись жесткие лимиты на 8 динамических источников света и 120 анимированных костей

- Существование индиректов дало бы возможность заполнять буфер видимости чанков в компьют шейдере, а потом одним вызовом multi_draw_indirect рисовать все чанки разом прямо с GPU. Сейчас же там CPU батчинг, куллинг и прочее через костыли через обычный multi_draw

- Семплеры в wgpu уже поддерживают аппаратное сравнение глубины. Можно было бы целиком вырезать весь кусок с ручным PCF, который пришлось костылять в оригинале из-за OpenGL

- OIT для прозрачных объектов можно было бы перевести на компьюты и атомарные операции в шейдерах для гарантированно корректного порядка отрисовки

- Объемные облака можно было бы оптимизировать, опять же, через компьюты - отсекать найденные результаты раньше на уровне воркгруппы

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

- Цветокоррекция сейчас там идет на каждый кадр для каждого пикселя с нуля. Опять же, можно было бы сгенерировать 3D LUT компьютом при изменении настроек и дальше просто семплить её, пока не изменится

- Часть операций можно сделать параллельными - например, SSAO и обработку глубины жидкости, Bloom, Blur и god rays тоже. Можно было бы набрать несколько буферов команд на wgpu параллельно и разом их отправить на исполнение

и это я еще не говорю про всякие микрооптимизации вроде замены части юниформ буферов на пуш константы

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

И все это без жертвования кроссплатформой, которая у них нынче есть

К слову, в Винтажке еще с точки зрения архитектуры игры интересное решение есть

У них основные игровые режимы (креатив, выживание и тд) реализованы как моды на движок игры. Через то же самое апи, что дается для модов игрокам

По их словам, так поступили, чтобы удостовериться, что публичное апи для модов всегда будет соответствовать тому, что использует сама игра - не будет соблазна его забросить или сделать какие-то приватные фичи, недоступные модерам

Не то что некая другая кубическая игра, которая официальное стабильное апи уже с десяток лет обещает)

Собственно, Винтажка начиналась как мод на Minecraft, но довольно быстро перестала влезать в его возможности, и после этого они решили написать ее как отдельную игру с нуля

Появилась пара дней свободного времени, решил попробовать допилить что-нибудь в wgpu

В итоге вроде получилось сделать эмуляцию multi_draw_indirect_count для Metal через компьют шейдер, чтобы эта функция была доступна на всех трех бекендах

Сначала хотел сделать без эмуляции через Indirect Command Buffer у Metal, но не взлетело - не вижу способа передать count с GPU, а синхронизация с CPU посреди рендер прогона убьет весь перф

В итоге просто перед рендером вставляю один компьют прогон, который заполняет нужные буферы для вызова обычного draw_indirect под капотом

Закинул PR, посмотрим, что скажут
https://github.com/gfx-rs/wgpu/pull/9659

Наткнулся на забавный баг - в игре ломается скроллинг колесиком мыши - то не скроллит вообще, то скроллит слишком далеко. Причем исключительно на macOS, на других платформах всё нормально

Начал копаться - выкопал. Макось отправляет события скролла двух видов - попиксельные и линейные. И дельты там могут быть с хорошим таким разлётом, намного шире других систем
Плюс для "плавной прокрутки" макось не сразу отрубает события при остановке скролла, а постепенно "скручивает" их дельты до нуля, продолжая посылать ивенты даже когда физически скролл прекратился

И что SDL2, что Winit, оба умеют это нормально обрабатывать из коробки - у них есть нормализация, у винита вообще отдельно можно получить LineDelta и PixelDelta для скролла и обработать как хочешь

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

И отсюда такие вот приколы с дробными дельтами, когда до порога скролл вообще не работает, зато потом резко скачет дальше, чем нужно

Решил лично попробовать-таки свою идею с wasm для встраивания скриптов/плагинов/модов в нативные приложения

Итоги изысканий выложил здесь - https://github.com/Bromles/wasmtime-wit-demo

Хостовая часть на Rust, но вообще может быть на любом языке, поскольку wasmtime имеет сишный интерфейс

Дальше минимальное апи плагинов описывается в wit файле, с двусторонним интерфейсом - хост вызывает функцию у плагина, плагин вызывает функцию хоста

И есть примеры плагинов на тех языках, которые я смог успешно подружить со сборкой в нужный сорт wasm

Код везде был написан одинаковый, но вот тулчейны у языков разные, поэтому размер итоговых wasm файлов плагинов после билда тоже совсем разный. Ниже список языков и размеры плагинов на них

- C - 13 кб
- C++ - 13 кб
- Nelua - 13 кб
- Rust - 16 кб
- Odin - 44 кб
- Nim - 52кб
- Zig - 863 кб
- C# - 2.6 мб
- Go - 2.7 мб
- Js - 12.5 мб
- Python - 18.4 мб

У FreePascal, Dart, Ruby, Swift, Java и Kotlin поддержка либо в разработке, либо в нестабильных альфа-версиях, поэтому добавлять их не стал. Ближе всех Kotlin, там уже в бета-версии, и FreePascal, где уже вмержено, но еще не релизнуто.

Еще не все языки из этого списка одинаково просто билдились - где-то понадобилась всего одна команда, где-то немного возни с докером, а где-то нужно автопатчить сгенерированные сишные исходники

Фактически это означает, что любой из вышеназванных языков можно использовать для написания скриптов/плагинов/модов к приложениям, умеющим исполнять wasm и предоставляющим интерфейс в виде wit файлов

Например, именно так сделаны расширения в Zed

Пока я думал и эмулировал multi_draw_indirect_count, другой человек запилил нормальную реализацию multi_draw_indirect на Метале в wgpu, все же прикрутив туда ICB (использовал подход, который я сразу отмел как невалидный, а он оказался рабочим в итоге)

https://github.com/gfx-rs/wgpu/pull/9640

И сейчас он же, вместе с остальными, пытается поддержку multi_draw_indirect_count затащить в веб стандарт

привел конкретные цифры - он смог добиться 60 фпс на айфоне и 120 фпс на маке в известной AR Portal демке только через multi_draw_indirect вызовы - без них, даже с компьютами, получается на треть меньше перфа на ровном месте. И говорит то, о чем говорил и я давно уже - для современного рендера компьюты, MDI и подобное уже являются необходимостью, а не продвинутыми фичами (умеют его, к слову, даже DirectX 11 и OpenGL)

https://github.com/gpuweb/gpuweb/issues/1354#issuecomment-4678441040

Тоже, кстати, с wasm на нативе развлекается)

Обсуждаем там с контрибуторами, что делать с моим PR - может оставим как временную реализацию

Обнаружил https://github.com/nasa/spacewasm

Интерпретатор wasm, удовлетворящий требованиям для космических полетов, для исполнения критического кода на борту космических кораблей

сделан NASA на Rust

Ну теперь смешарик. Осталось только международной версии диплома дождаться

Может через год-два в аспирантуру пойду, кандидатом этих ваших наук становиться

Но пока немного подышу, проекты старые выкопаю, поработаю спокойно