Миф про O(1)

Говорят, что хэш-таблицы обеспечивают поиск за O(1) — константное время, вне зависимости от размера. В теории они идеальны.

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

Я оптимизировал таблицу символов для компилятора. Таблица символов использовала хэш-таблицу с 1024 бакетами, и у нас было примерно 500 символов. Расчёты выглядели отлично: средний размер бакета = 500/1024 ≈ 0,5, поэтому большинство операций поиска должно выполняться за один запрос.

Но профилировщик рассказал иную историю...

В AWS здорово то, что этой платформе уже почти двадцать лет. Печально в AWS то… что ей уже почти двадцать лет. Если вы уже долгое время пользуетесь ею, то вам может быть сложно заметить тем изменений её «фундаментальных» сервисов. Хуже того: даже если вы относительный новичок в AWS, вам всё равно довольно легко найти устаревшие посты, объясняющие всё так, как было раньше, но не сейчас. В своей статье я перечислю часть примеров такой эволюции, которые помогут вам, если вы запутаетесь.

Алгоритм Slug, используемый для рендеринга на GPU шрифтов непосредственно из кривых Безье, был разработан осенью 2016 года, а значит, в этом году мы отмечаем десятилетие его рождения. В середине 2017 года я опубликовал в JCGT статью об этой методике, а вскоре после этого моя компания продала первую лицензию на версию 1.0 Slug Library. С тех пор Slug многократно лицензировался разработчиками видеоигр, а также компаниями, специализирующихся в научной визуализации, CAD, редактировании видео, медицинском оборудовании и даже создании планетариев. Среди наших клиентов Activision, Blizzard, id Software, 2K Games, Ubisoft, Warner Brothers, Insomniac, Zenimax и Adobe. Slug оказался моим самым успешным программным продуктом.

Изначально я создавал Slug с целью улучшения рендеринга текста в C4 Engine, шрифты которого должны выглядеть идеально не только в GUI, но и внутри игровых уровней, где они могут быть очень крупными и отображаться под разными углами. Недавно я использовал Slug в создании редактора формул Radical Pie, в котором, разумеется, необходим крайне качественный рендеринг шрифтов, а также векторной графики для таких обозначений, как скобки, знаки корня и чисто графических элементов наподобие стрелок и выделения математических выражений. Кроме того, Slug используется для рендеринга всего интерфейса пользователя внутри основного окна редактирования и всех диалоговых окон.

В этом посте я расскажу об изменениях в методике рендеринга с 2017 года, когда была опубликована научная статья и выпущена первая версия Slug Library. Завершается статья важным объявлением для тех, кто захочет реализовать алгоритм Slug в собственных проектах.

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

Но есть одно эмпирическое правило, о котором мне рассказали несколько десятков лет назад; с тех пор я не перестаю пользоваться им из-за его раздражающей истинности. Это правило раздражает, потому что кажется, что оно не должно быть верным. Я ни разу не слышал его теоретического обоснования. И тем не менее, оно проявляется постоянно.

Итак, вот оно:

Каждый слой согласований замедляет процесс в десять раз

Знаю, что вы подумали. «Да ладно, в десять раз? Это слишком много, не похоже на правду. Ты, наверно, преувеличиваешь».

Не-а.

Уточню, что здесь учитывается общее время, а не трудозатраты. Почти всё дополнительное время тратится на ожидание.

Вы получили уведомление о непрочитанном сообщении

Это может быть сообщение в Slack (или Teams), мессенджере или электронной почте. Может быть, вас тэгнули в Notion или в документе Office.

Вы открываете его и видите множество абзацев текста или, может быть, список со всеми признаками сгенерированного ИИ послания: заголовки, много форматирования, фразы вида «это не X, это Y», обильно присыпанные длинными тире.

Отправивший вам это сообщение человек, вероятно, потратил на него с десяток секунд. Он попросил чат-бота создать текст и просто переслал его ответ вам в полном виде, не проверив и не проанализировав его.

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

Когда я пишу эту статью, то чувствую себя довольно глупо. На самом деле, это история с моралью «Прежде, чем действовать, изучи вопрос и понимай, в чём заключается твоя цель, потому что иначе потеряешь много времени».

Я продолжаю работать над проектом PSRayTracing. Как ни стараюсь я положить его на полку, время от времени слышу о чём-то «новом» и задаюсь вопросом: «а можно ли засунуть это в мой трассировщик лучей, чтобы выжать из него ещё немного скорости?». На этот раз такой темой стали аппроксимации Паде. Моя цель заключалась в обеспечении более быстрых (и точных) тригонометрических аппроксимаций.

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

Словом 2025 года в Японии стало слово медведь. Количество столкновений с чёрным уссурийским медведем по сравнению с предыдущем годом удвоилось. 200 человек было ранено, 13 погибло. Окума («большой медведь») — это городок на восточном побережье Японии. Но больше всего население Окумы боится не медведей, а радиации.

Окума — город, расположенный ближе всех к трём реакторам АЭС Фукусима-1, расплавившимся 11 марта 2011 года. В тот день землетрясение магнитудой 9,0 баллов и цунами уничтожили резервные генераторы и насосы системы охлаждения трёх реакторов, загруженных ядерным топливом. В четвёртом реакторе топлива не было, но его здание, заполненное водородом из соседнего блока, взорвалось вместе с тремя остальными.

Волна, обрушившаяся на восточное побережье Японии, привела к гибели 20 тысяч человек, тела многих из них вынесло в море и они не были обнаружены. В окрестностях уничтоженных реакторов резко возросли уровни радиации, и 160 тысяч людей было эвакуировано из Окумы и ещё 11 городов. 20-километровое кольцо вокруг электростанции было объявлено зоной отчуждения. Из-за ужасной снежной бури, накрывшей город цезием-137 и другими радионуклидами, эвакуировали даже Иитате, деревню в 60 километрах к северо-западу.

Пятнадцать лет спустя четыре тысячи работников с трудом пытаются контролировать продолжающуюся катастрофу. Три расплавившихся реактора остаются настолько радиоактивными, что выводят из строя роботов, отправляемых для оценки разрушений. Никто точно не знает, где находится расплавившееся топливо и насколько ниже бетонных постаментов реакторов оно опустилось, вероятно, достигнув почвы. Вода, использовавшаяся для охлаждения реакторов, хранится в тысяче с лишним резервуаров, исчерпавших предел своей ёмкости в 2023 году. Эта охлаждающая вода, которая, по первоначальным утверждениям Tepco, была чистой и сбрасывалась в Тихий океан с 2023 года, оказалась загрязнённой 62 радионуклидами, в том числе цезием, стронцием и плутонием. Два бассейна выдержки, заполненных отработанным ядерным горючим, всё ещё не освобождены. Они шатко держатся поверх первого и второго блоков, представляющих собой взорвавшиеся переплетения металла, готовые упасть и быть смытыми в океан.

Я был одержим процедурными картами с ещё детства, когда кидал кубики на таблицы случайных подземелий из AD&D Dungeon Master's Guide. В этом есть что-то волшебное — ты не проектируешь подземелье, а исследуешь его, помещение за помещением, а кубики решают, попадёшь ли ты в сокровищницу или в тупик с кучей крыс.

Спустя годы я решил создать собственный генератор карт. Он создаёт маленькие средневековые островные миры с дорогами, реками, побережьями, горами, лесами и деревьями. И всё это полностью процедурным образом. Генератор написан на Three.js WebGPU с TSL-шейдерами, примерно 4100 шестиугольников в 19 сетках генерируются за ~20 секунд.

Многие мои читатели называли меня циничным, когда я делал заявления наподобие «вам всегда нужно угождать своему менеджеру» или «большие технологические компании имеют право решать, над какими проектами вы работаете». Алекс Веннерберг привёл веские доводы того, что я циник, в своём посте Software Engineers Are Not Politicians («Разработчики — это не политики»). Вот некоторые выдержки из него:

Я не сомневаюсь, что советы [автора статьи] довольно эффективны для лавирования на верхних уровнях в организации, занимающейся разработкой крупного программного продукта с долгой историей. Но при этом теряется какая бы то ни было концепция пользы. Разве слишком наивно заявлять, что разработчики — это не «просто инструменты в политической игре», а специалисты, цель которых заключается в использовании своего опыта для решения важных задач?

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

Я понимаю, почему люди так думают. Но мне нравится работать в больших технологических компаниях! И я вижу в себе профессионала, решающего важные задачи. А ещё я считаю, что лавирование в компании с целью реализации для пользователей новых фич или улучшений — это превосходный (если не лучший) способ выполнять свою работу качественно.

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

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

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

Поэтому позвольте мне сказать фразу, которая повергнет бывалого резидента Кремниевой долины в больший шок, чем дефекация на Маркет-стрит: не использовать ИИ совершенно нормально.

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

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

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

Мечта об универсальной таблетке стала причиной исследований в сфере проглатываемой электроники: маленьких капсул, предназначенных для мониторинга и даже лечения болезней изнутри желудочно-кишечного тракта (ЖКТ). Ставки высоки: заболевания ЖКТ осложняют жизнь десяткам миллионов людей по всему миру; среди них такие болезни, как воспалительные заболевания кишечника, целиакия и синдром избыточного бактериального роста. Для их диагностики пациентам часто приходится проходить запутанный лабиринт из анализов крови, томографии и инвазивной эндоскопии. В то же время, способы лечения могут привносить серьёзные побочные эффекты, потому что лекарства действуют на всё тело, а не только на проблемные участки.

Если капсулы смогут выполнять бóльшую часть этой работы — упрощать диагностику, обеспечивать прицельное лечение и избавлять пациентов от необходимости инвазивных процедур — то, возможно, они окажутся способны преобразовать сам процесс ухода. За последние двадцать лет исследователи изобрели большой инструментарий проглатываемых устройств, и часть из них уже находится в клиническом использовании. Эти капсулообразные устройства обычно содержат в себе датчики, электрические цепи, источник питания, а иногда и коммуникационный модуль, заключённые в совместимую с живыми тканями оболочку. Но к следующему важному шагу подготовка всё ещё ведётся: это будут автономные капсулы, способные и выполнять контроль, и действовать, высвобождая лекарства или беря образцы ткани.

«Простота — требование, необходимое для обеспечения надёжности», — Эдсгер Дейкстра

Невидимая структура данных

В каждой программе используется стек — стек вызовов. Каждый вызов функции записывает в стек кадр, каждый возврат извлекает его. Он настолько фундаментален, что мы редко о нём задумываемся.

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

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

Переполнение стека? Очередь должна была находиться в куче, а не в стеке.

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

Как же мы устранили проблему? Заменили очередь на основе связанного списка кольцевым буфером — очередью на основе массива фиксированного размера, получив при этом отсутствие динамического распределения, предсказуемое использование памяти и десятикратный рост скорости.

«Что есть "реальность"? И как определить её? Весь набор ощущений: зрительных, осязательных, обонятельных — это сигналы рецепторов, электрические импульсы, воспринятые мозгом.» — Морфеус, фильм «Матрица»

Если процессор — это мозг компьютера, то может ли он быть ещё и частью некой виртуальной реальности? Симулированная память, программно-определяемая периферия, искусственно сгенерированные прерывания...

Моим первым компьютером был 286 с 1 МБ ОЗУ и жёстким диском на 50 МБ (если я правильно помню). Поэтому я решил взять процессор 286 и попробовать симулировать остальную часть компьютера вокруг него. Или хотя бы сделать так, чтобы он мог запускаться и выполнять какой-то простой ассемблерный код.

Два года назад я купил два процессора Harris 80C286-12. Мои воспоминания довольно туманны, но кажется, буква C в их маркировке важна, потому что она означает меньшую чувствительность к точности таймера (12 в конце означает, что процессор предпочитает работать на 12 МГц), и что на нём даже допустимо пошаговое выполнение.

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

3 февраля 1967 года навсегда вошло в анналы истории музыки. В этот день Джими Хендрикс пришёл в лондонскую Olympic Studios для записи песни с использованием нового компонента. Эта песня — Purple Haze, а компонент — гитарная педаль Octavia, специально изготовленная для Хендрикса звукоинженером Роджером Майером. Педаль стала ключевым элементом сложной цепочки аналоговых элементов, формирующих окончательный звук, включая акустику самой студии. Звук записи был настолько новым, что когда они отправляли плёнки для ремастеринга в США, то приложили к ним письмо с объяснением, что дисторшн в конце — это не сбой, а намеренный эффект. Спустя несколько месяцев Хендрикс провёл своё легендарное электрогитарное выступление на Monterey International Pop Festival.

Благодаря Purple Haze стало очевидно, что электрогитару можно использовать не только как струнный инструмент со встроенными звукоснимателями. для удобного усиления звука, но и как полнофункциональный волновой синтезатор, сигналом с которого возможно манипулировать. Современные гитаристы могут воссоздать созданную Хендриксом цепочку при помощи отдельных плагинов в DAW-программе, но когда всё буферизируется и дискретизируется, магия зачастую пропадает. Я захотел разобраться, может ли более систематический подход улучшить качество и дать понимание того, как Хендрикс создал свой революционный звук.

TL;DR:

1,005 миллиарда веб-страниц

25,5 часа

$462

По какой-то причине уже долгое время никто не писал о том, что требуется для краулинга большой части веба: последним обнаруженным мной источником был пост Майкла Нильсена за 2012 год[1].

Очевидно, что за это время много изменилось. Всё стало больше, лучше и быстрее: у CPU появилось намного больше ядер, на смену жёстким дискам пришли твердотельные накопители NVMe, скорости ввода-вывода которых сравнимы со скоростями RAM, существенно выросла ширина сетевых каналов, существенно расширился список типов инстансов EC2 и так далее. Но в чём-то ситуация и усложнилась: гораздо бóльшая часть веба стала динамической, а контент теперь более тяжёлый. Как поменялось состояние Интернета? Теперь узкие места стали другими, и для создания своего Google по-прежнему нужно около 41 тысячи долларов? Мне захотелось это узнать, поэтому я собрал и выпустил собственный веб-краулер¹ в условиях похожих ограничений.

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

Это история о том, как DatatypeFactory.newInstance() поставил на колени наш высокопроизводительный Java-сервис, и об удивительно простом решении, позволившем полностью избавиться от проблемы.

Я написал игру для Game Boy Color, которая рендерит изображения в реальном времени. Игрок управляет источником света и вращает объект.

Поиграть в неё можно здесь: https://blog.otterstack.com/posts/202512-gbshader/data/teapot.html

Посмотреть код и скачать ROM можно здесь: https://github.com/nukep/gbshader

«Связанные списки — это goto структур данных.», — авторство приписывают разным системным программистам.

История из учебника

Все студенты, изучающие computer science, узнают о связанных списках на первом курсе по структурам данных. Их описание звучит привлекательно:

Преимущества (согласно учебникам):

- Вставки и удаления за O(1) в известных позициях

- Динамический размер: увеличиваются и уменьшаются согласно необходимости

- Пространство не тратится впустую: можно распределять ровно столько, сколько нужно

- Гибкость: простота реализации стеков, очередей и других структур

Недостатки (согласно учебникам):

- Поиск за O(n): необходим обход, начиная с головы списка

- Лишняя память: указатели добавляют оверхед

- Невозможность произвольного доступа: нельзя выполнять переходы в произвольные позиции

Вывод из учебника: «Используйте связанные списки, когда требуются частые вставки/удаления и не нужен произвольный доступ».

Вроде бы звучит разумно?

Проверка реальностью

А вот, чего учебники нам не говорят: связанные списки — это почти всегда плохой выбор.

Не потому, что ошибочен анализ «О» большого, в нём всё правильно, а потому, что он неполон. Он забывает про оборудование.

На прошлой неделе я попросил Claude устранить однострочный баг. Ему понадобилось 23 тысячи токенов. Потом тот же баг я попросил устранить Gemini. Он потратил 350 тысяч токенов. Да уж, на такое невозможно закрывать глаза.

Поэтому я написал Context Lens — трассировщик контекста, перехватывающий вызовы LLM API, чтобы показать, что же на самом деле находится в окне контекста с разбивкой по этапам. Я подключил его к четырём инструментам кодинга и дал им одну и ту же задачу. Результаты оказались настолько разными, что я решил написать об этом статью.

Вопрос

При работе с этими моделями мы платим за токены. Токены — это довольно сложная тема. По сути, это блоки информации; 1 токен приблизительно равен 4 символам английского текста. Чем больше токенов передаётся в модель, тем больше мы платим.

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

Итак, нам нужно быть аккуратными с нашим окном контекста, а для построения этого окна используются токены. Я задался вопросом: как инструменты справляются с этим ограничением? Насколько умно они его обрабатывают?

В релизе 1.26 языка Go, выпущенном в этом месяце, есть полностью переписанная подкоманда go fix. Go fix использует набор алгоритмов для обнаружения возможностей улучшения кода; часто для этого применяются более новые фичи языка или библиотеки. В этом посте мы сначала покажем, как использовать go fix для модернизации кодовой базы на Go. Во второй части статьи мы расскажем о лежащей в основе этой подкоманды инфраструктуре и её эволюции. В третьей части мы познакомим вас с тематикой инструментов анализа с «самообслуживанием», которые помогают мейнтейнерам модулей и организациям кодироовать собственные правила и рекомендации.