Пользователь Reddit опубликовал в r/rustjerk сгенерированный ИИ пост под названием «Почему наш CTO запретил использовать Rust после одного переписывания кода». Очевидно, что этот рассказ выдуман, но у меня есть история похожая на него в том смысле, что успех проекта на Rust привёл к прекращению использования этого языка в компании.

Несколько лет назад я работал в стартапе-«единороге», во время пандемии развивавшемся невероятно быстро. Его основное приложение было написано на Ruby on Rails, а часть инструментария для работы с видео — на Node.js, но мы никак не применяли быстрые компилируемые языки наподобие Rust и Go. Через пару месяцев после моего прихода в компанию нам нужно было реализовать работающий в реальном времени сервис, который бы позволял нам получать информацию о том, кто из пользователей находится онлайн (то есть в профиле есть зелёная точка) и чем они занимаются (например: N пользователей смотрят презентацию X, M пользователей находятся в разделе маркетинга и так далее). Ничего особо сложного, но мы рассчитывали на изначальный рост до ста тысяч пользователей. Эта цель тоже не особо сложна, но большинство разработчиков согласилось, что Ruby — не лучший выбор для этого.

Зачем вообще этим заморачиваться?

Некоторые образцы malware выполняют различные проверки, чтобы определить, запущены ли они в виртуальной машине. Один из самых частых способов — проверка наличия определённых аппаратных компонентов, обычно не эмулируемых в виртуальных средах. Один из таких компонентов — кулер процессора. Например, malware может проверять наличие кулера процессора, поискав в WMI класс Win32_Fan:

wmic path Win32_Fan get *

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

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

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

Я посвящу этой теме целый пост, потому что она «не помещается в окно Овертона»; чтобы люди хотя бы начали понимать, что я пытаюсь описать, мне обычно приходится показывать видео, которое я выложил под катом.

Как вы, наверно, знаете, из-за наличия в компьютере различных кэшей (L1, L2, L3...) и того, что операции с памятью выполняются с линиями кэша размером примерно 64 байт каждая, для обеспечения максимальной производительности мы должны писать программы, обеспечивающие локальность.

(Разумеется, диск здесь не показан)

Но насколько хорошо вы это осознаёте? Допустим, у нас есть массив чисел с плавающей запятой и массив индексов первого массива. Есть программа, складывающая числа из первого массива в порядке, определяемом вторым массивом. То есть в этом примере мы будем складывать ε + α + δ + ζ + β + γ в таком порядке:

Давайте рассмотрим всего два случая: индексы идут в порядке от первого до последнего или в произвольном порядке. До того, как я начал писать этот пост, я не мог ответить ни на один из следующих вопросов:

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

2. Сколько в среднем тратится на каждый элемент в порядке от первого до последнего?

3. Насколько медленнее произвольный порядок последовательного в случае массивов, умещающихся в RAM?

4. Насколько медленнее произвольный порядок последовательного в случае массивов, не умещающихся в RAM?

5. Достаточно ли стандартного тасования Фишера-Йейтса для массивов перемешанных индексов для получения произвольного порядка?

6. Насколько медленнее порядок от первого до последнего в случае массивов, не умещающихся в RAM, при использовании файлов с отображением в память?

7. Максимально ли быстры файлы с отображением в память?

Если вы уже знаете ответы на эти вопросы, то это замечательно! Если же нет, то делайте ваши предположения и проверьте их, прочитав пост.

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

Вот и всё!

Ниже показан скрипт, сочетающий все мои трюки для выполнения этой задачи. Для его работы необходимо установить yt-dlp, ffmpeg и llm.

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

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

Рассмотрим следующий сценарий:

template<typename T>
struct Base
{
// Есть конструктор по умолчанию
Base() = default;

// Некопируемый
Base(Base const &) = delete;
};

template<typename T>
struct Derived : Base<T>
{
Derived() = default;
Derived(Derived const& d) : Base<T>(d) {}
};
// Это assertion выполняется?
static_assert(
std::is_copy_constructible_v<Derived<int>>);

Почему выполняется это assertion? Очевидно, что скопировать Derived<int> нельзя, ведь при этом мы попытаемся скопировать некопируемый Base<int>. И в самом деле, если попробовать скопировать его, то мы получим ошибку.

В 2006 году АНБ скрыла в криптографическом стандарте Dual EC DRBG математический бэкдор. Агентство отрицало его наличие восемь лет. Затем утечки Сноудена подтвердили его существование.

Двойные эллиптические кривые (Dual Elliptic Curve) используются как безопасные генераторы случайных чисел (RNG). Математический бэкдор позволял правительству США расшифровывать SSL-трафик Интернета (Green 2013)¹.

Эта статья будет технически глубоким исследованием для программистов. Мы реализуем и исходную правительственную научную статью (SP 800-90 2006)², и бэкдор, обнаруженный исследователями Microsoft (Shumow & Ferguson 2007)³.

На моём домашнем компьютере для взлома 28 байт (не бит) при помощи этого бэкдора требуется 2 минуты. Представьте, какой объём Интернет-трафика правительство США могло расшифровывать при помощи суперкомпьютеров Министерства обороны.

Автор статьи Modern SAT solvers: fast, neat and underused утверждает, что SAT-солверы «преступно мало используются в нашей отрасли». [SAT — Boolean SATisfiability Solver, то есть солвер, способный находить присвоения, делающие истинными сложные булевы выражения. Более подробно я писал о них ранее.] Какое-то время назад я задался вопросом, почему: как получилось, что они настолько мощны, но ими никто не пользуется? Многие специалисты заявили, что причина в неудобстве кодирования SAT: они лучше предпочтут работать с инструментами, которые выполняют компиляцию в SAT.

Я вспомнил об этом, когда прочитал пост Райана Бергера о решении «задачи ферзей с LinkedIn» как задачи SAT.

Вкратце опишу задачу про ферзей (Queens). У нас есть сетка NxN, разделённая на N областей, и нам нужно разместить N ферзей так, чтобы в каждом столбце, строке и области находился ровно один. Ферзи могут находиться на одной диагонали, но не соседствовать по диагонали.

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

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

Предупреждение: все выраженные в этом посте мнения исключительно мои и необязательно отражают точку зрения Rust Project (группы контрибьюторов и мейнтейнеров тулчейна Rust).

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

Его звали Филиппо Брунеллески. Он использовал этот аппарат, чтобы нарисовать расположенный рядом с собором баптистерий. Если его биографы не ошибаются, для этого он применил законы перспективы, открытые им приблизительно в 1415-1420 годах. Использование законов перспективы, поразившее случайных прохожих, изменило курс развития западного искусства более чем на 450 лет. Позже оно привело к математическим открытиям, позволившим реализовать эллиптическую криптографию — схему защиты, лежащую в основе биткойна и других криптовалют; сейчас она становится всё более популярным способом шифрования и на других Интернет-платформах.

Но как искусство Ренессанса привело к математическим основам современной криптографии? Эта история растянулась на шесть веков и два континента, прикоснувшись к самой вечности. Персонажами её стали французский военнопленный и два математика, умершие на пике своего развития, один от болезни, другой — от пистолета дуэлянта.

Глубокое обучение гламурно и ажиотажно. Если обучить трансформер (современную языковую модель) на датасете из 22 миллионов ферментов, а затем использовать его для прогнозирования функции 450 неизвестных ферментов, то можно опубликовать свои результаты Nature Communications (уважаемом научном издании). Вашу статью прочитают 22 тысяч раз и она будет в верхних 5% из всех результатов исследований по оценке Altmetric (рейтингу внимания к онлайн-статьям).

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

Functional annotation of enzyme-encoding genes using deep learning with transformer layers | Nature Communications

Limitations of Current Machine-Learning Models in Predicting Enzymatic Functions for Uncharacterized Proteins | bioRxiv

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

Что такое интервальные повторения

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

То же самое относится и к предметам в школе или вузе: нескольких часов в неделю в классе или домашний заданий редко хватает для наработки крепкой базы знаний, особенно в таких предметах с большим объёмом фактов, как история или медицина. Под этим углом можно рассматривать даже ту часть своей жизни, которую мы не считаем связанной с обучением: не казались ли все эти подкасты и статьи с Hacker News полезнее, если бы мы могли вечно помнить полученную из них информацию?

Системы интервального повторения (spaced repetition) — один из самых проработанных решений этой проблемы. Это компьютерные программы, которые, по сути, показывают флеш-карточки с подсказками, на основе которых нужно вспомнить информацию, написанную на обратной стороне карточки.

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

BEIR — это бенчмарки поиска информации, ориентированные на сценарии использования в формате «вопрос-ответ».

Мой хобби-проект SearchArray добавляет в Pandas полнотекстовый поиск. Поэтому естественно, чтобы ощутить трепет от моих потрясающих навыков разработчика, я решил использовать BEIR для сравнения SearchArray с Elasticsearch (с тем же запросом + токенизацией). Поэтому я потратил субботу на интеграцию SearchArray в BEIR и измерение релевантности и производительности с корпусом MSMarco Passage Retrieval (8 миллионов документов).

Барабанная дробь...

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

Я считаю, что при работе с Go в контексте нашей отрасли внедрение зависимостей (dependency injection, DI) часто имеет плохую репутацию из-за DI-фреймворков. Но сама по себе DI как техника довольно полезна. Просто её объясняют слишком большим количеством ОО-жаргона, что приводит к ПТСР у тех, кто перешёл на Go, чтобы сбежать из культа банды четырёх.

В этой статье мы расскажем о том, как GitLab выявил и устранил «бутылочное горлышко» производительности в 15-летней функции Git, что повысило эффективность, обеспечив возможность применения более надёжных стратегий резервного копирования и снижения рисков.

Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.

В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.

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

Сегодня я решил изучить новую библиотеку Cloudflare OAuth provider, которую, судя по заявлениям, почти полностью написали при помощи LLM Claude компании Anthropic:

Эта библиотека (в том числе и документация по схеме) была по большей мере написана при помощи Claude — ИИ-модели компании Anthropic. Результаты работы Claude были тщательно проверены инженерами Cloudflare, уделившим особое внимание безопасности и соответствию стандартам. В исходный результат было внесено множество улучшений, в основном тоже при помощи промптов Claude (и с проверкой результатов). Промпты модели Claude и созданный ею код можно посмотреть в истории коммитов.

[…]

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

Я и сам в последнее время достаточно много писал подобным образом код при помощи «агентских» LLM. И я тоже специалист по OAuth: я написал API Security in Action, многие годы был членом OAuth Working Group в IETF и ранее работал техлидом, а затем архитектором безопасности в ведущем поставщике решений OAuth. (Также у меня есть степень PhD в сфере ИИ, полученная в группе изучения интеллектуальных агентов, но ещё до возникновения современного ажиотажа вокруг машинного обучения). Поэтому мне было очень любопытно, что же создала эта модель. И сегодня, сидя на паре совещаний, я решил изучить результаты. Дисклеймер: я лишь вкратце просмотрел код и нашёл несколько багов, а не выполнял полный анализ.

Недавно я работал над достаточно большим проектом на Rust. К моему удивлению, мне никак не удавалось заставить тесты работать правильно.

Команда cargo test запускала выполнение всех тестов в репозитории, но спустя пару миллисекунд все тесты завершались сбоями из-за не очень знакомой мне ошибки:

Io(Os { code: 24, kind: Other, message: "Too many open files" })

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

Пару дней назад я написал пост о тритонах, в котором упомянул чрезвычайно ядовитого американского тритона. Но тогда у меня не было ни места, ни времени объяснить, почему он настолько ядовитый. И, разумеется, меня немедленно забросали кучей* комментариев и писем с вопросами. 

^*тремя

Что ж, ладно, расскажу. Самый ядовитый тритон в мире — это Taricha granulosa, желтобрюхий тритон. Скромное маленькое земноводное, эндемичное для северо-запада тихоокеанского побережья Северной Америки, к западу от Каскадных гор примерно от округа Санта-Круз (Калифорния) до Юго-Восточной Аляски.

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

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

Давайте начнём с чего-то близкого нам: цен на недвижимость. Большие дома стоят больше, маленькие — меньше. Подобный паттерн можно заметить даже без анализа: чем больше места, тем дороже.

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

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

Теперь представьте, что вы продаёте свой дом. Его площадь 1850 квадратных футов (~172 квадратных метра) — больше среднего, но явно не особняк. Вы видели, почём продаются дома в вашем районе, но цены колеблются. Какой будет справедливая цена?