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

Я продолжаю работать над проектом 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. Во второй части статьи мы расскажем о лежащей в основе этой подкоманды инфраструктуре и её эволюции. В третьей части мы познакомим вас с тематикой инструментов анализа с «самообслуживанием», которые помогают мейнтейнерам модулей и организациям кодироовать собственные правила и рекомендации.

Вместе с релизом в 1999 году исходного кода Quake был выпущен файл readme.txt, написанный Джоном Кармаком. Особый интерес в нём вызвало одно предложение:

Также для сборки файлов на языке ассемблера требуется Masm. Можно изменить #define и выполнять сборку только с кодом на C, но версии с программным рендерингом при этом потеряют почти половину скорости.

Quake был вдвое быстрее благодаря написанному вручную ассемблерному коду? Давайте разберёмся, так ли это, как это работает, и какими были самые важные оптимизации.

«Массив — самая важная структура данных в computer science», — Дональд Кнут (вольное изложение цитаты)

Простейшая структура данных

Массивы настолько просты, что мы иногда воспринимаем их, как нечто само собой разумеющееся. Смежная память, доступ за O(1): что тут ещё оптимизировать?

Всё.

Я работал над конвейером обработки пакетов сетевого коммутатора. Код был простым: считываем пакеты из кольцевого буфера (массива), обрабатываем их и записываем результаты в другой массив. Всё просто, правда?

Но производительность была ужасной. Мы обрабатывали 100 тысяч пакетов в секунду, хотя оборудование должно было справляться с 1 миллионом.

Профилировщик показал нечто странное:

$ perf stat -e cache-misses,instructions ./packet_processor

Performance counter stats:

450,000 cache-misses

1,000,000 instructions

450000 промахов кэша на 1000000 команд? То есть промах происходил раз в 2-3 команды. При простых операциях с массивами это не имело никакого смысла.

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

Первые исполняемые файлы Quake (quake.exe и vquake.exe) программировали на HP 712-60 с NeXT и кросс-компилировали при помощи DJGPP, запущенного на DEC Alpha server 2100A. В июне 1996 года, после выпуска игры, id Software, озабоченная стагнацией NeXT, решила поменять стек разработки.

Сразу после выпуска Quake мы перешли на оборудование Intergraph с Windows NT.

- Джон Кармак^[1]

Следующие версии Quake (winquake.exe, glquake.exe) и QuakeWorld (qwcl.exe и qwsv.exe) разработаны и скомпилированы в Windows NT с помощью Visual C++ 4.X.

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

Известная ткачиха Мэрилу Шульц из племени навахо недавно закончила сложный ковёр, состоящий из толстых белых линий на чёрном фоне, испещрённых красновато-оранжевыми ромбами. Хоть это творение может показаться абстрактным, в нём представлена внутренняя схема крошечного кремниевого чипа таймера 555. Этот чип имеет сотни областей применения, от звукового генератора до контроллера автомобильных дворников. Когда-то 555 был самой продаваемой в мире интегральной схемой, счёт шёл на миллиарды устройств. Но как чип превратился в ковёр?

CI (непрерывная интеграция) ценна только тогда, когда проваливается. Когда она проходит успешно, то становится просто оверхедом: того же результата можно было добиться и без CI.

Что такое Continuous Integration?

Разработка ПО следует по цикличному итеративному паттерну. Разработчики вносят изменения, коммитят их в систему управления версиями, развёртывают их для пользователей и повторяют этот процесс. Этап continuous integration (CI) расположен между коммитами и развёртыванием, это выполнение автоматизированных проверок каждого коммита. Если проверка проходит успешно, мы говорим «CI пройдена», после чего изменение развёртывается. Если проверка проваливается, мы говорим «CI не пройдена», и изменение не развёртывается.

Если вы опытный разработчик, то, возможно, думаете: «Ну это само собой!». Чтобы по-настоящему осознать предназначение CI, нужно посмотреть, что происходит с CI и без неё.