Код AI Flame Graphs теперь открыт, этот проект поддерживает GPU Intel Battlemage. Это значит, что AI Flame Graphs теперь способен генерировать flame-графики (Flame Graph, граф пламени, диаграмма пламени), охватывающие полный стек GPU — это даёт пользователям новые аналитические данные о производительности игр. Особенно полезным AI Flame Graphs выглядит в связке с FlameScope (это — мой опенсорсный проект, созданный несколько лет назад). Вот — пример профилирования игры GZDoom. Тут показаны результаты визуализации использования CPU и GPU, проведённые с помощью FlameScope и снабжённые комментариями.

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

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

Современный видеоускоритель — это ещё и невероятно сложная система, которая постоянно становится всё сложнее. Новые возможности, вроде сеточных шейдеров (mesh shader) и графов задач (Work Graphs) хорошо описывает фраза «два шага вперёд, шаг назад». С каждой новой возможностью связана некая базовая задача, поддержка решения которой реализована не полностью.

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

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

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

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

Я решил использовать встроенный ассемблер gcc/clang и написать код, который сообщает системе: «Я могу создать 64-битное значение из 32-битного, не выполнив ни одной инструкции».

Компания Trail of Bits уже несколько лет сотрудничает с репозиторием PyPI, помогая добавлять в проект новые возможности и улучшать стандартные параметры безопасности в экосистеме управления пакетами Python.

Последнюю пару лет я переносил со службы домой и обратно «набор рабочих материалов» — видеофайлы и данные проектов, пользуясь внешним SSD-диском стандарта NVMe с интерфейсом Thunderbolt.

Но, когда я синхронизировал данные, это всегда происходило очень медленно. В обычный рабочий день я могу создать новую папку проекта, содержащую 500-1000 файлов. При этом среди них будут дюжины файлов размером 1-10 Гб.

Мой Thunderbolt-диск способен передавать данные со скоростью, значительно превышающей 5 Гб/с, а 10-гигабитное сетевое соединение, имеющееся в моём распоряжении, может выдать 1 Гб в секунду. Недавно я даже обновил диск до Thunderbolt 5, хотя его и нельзя назвать узким местом моей системы.

Я использовал команду rsync следующего вида для копирования файлов с общего сетевого ресурса, смонтированного на моём Mac, на диск, которому я дал имя Shuttle:

C++ уже десятки лет является краеугольным камнем, на котором строятся программы, ориентированные на высокую производительность. Он лежит в основе самых разных проектов, относящихся практически ко всем аспектам человеческой деятельности — от встроенных систем до платформ высокочастотной торговли. Его возможности по совмещению низкоуровневых средств управления вычислительными ресурсами с высокоуровневыми абстракциями превращают его в уникальный инструмент, подходящий для создания программ, при выполнении которых значение имеет каждая микросекунда. По мере того, как язык развивается, новые стандарты, вроде C++23 и ожидаемого C++26, вводят в него функционал, который улучшает и его возможности по созданию высокопроизводительных программ, и продуктивность пользующихся им программистов. Особенно это касается разработки высокопроизводительных служб — систем, которым требуются низкие задержки и высокие значения пропускной способности, которые нуждаются в эффективном использовании ресурсов. Среди них — аналитические системы, работающие в режиме реального времени, игровые серверы и распределённые системы управления базами данных.

На прошлой неделе разработчики CPython выпустили CPython 3.14.0b1. А на этой неделе в Питтсбурге, штат Пенсильвания, начинается конференция PyCon 2025. Оба эти события знаменуют собой важную веху в делах, связанных с разработкой, выпуском и доведением до стабильного состояния релизов free-threaded Python (Python с поддержкой свободной многопоточности — с отключённым механизмом GIL).

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

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

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

«Мы все сделаны из звёздного вещества», — любил напоминать человечеству астроном Карл Саган. Взрывы сверхновых — акты катастрофического самоуничтожения «изношенных» звёзд определённого типа — тесно связаны с жизнью на Земле. Дело в том, что именно в них рождаются тяжёлые элементы, которые можно встретить во всей Вселенной. Большая часть железа в нашей крови, и серы в аминокислотах, возникла в звёздах, взорвавшихся миллиарды лет назад. Но обнаружена и ещё одна, совершенно неожиданная связь между сверхновыми и миром людей. Речь идёт о связи с технологиями, которые нужны для производства компьютерных микросхем, применяемых в современных смартфонах и в других электронных устройствах.

Эта связь проявилась несколько лет назад в череде бесед между мной, Джейсоном Стюартом и моим дедушкой Рудольфом Шульцем. Дедушка был страстным астрономом-любителем, который держал в прихожей, сразу у входа, большой телескоп-рефлектор, который он всегда готов был направить на небо. Когда я учился в старших классах, он подарил мне книгу Стивена Хокинга «Краткая история времени» (Bantam Books, 1988) и на всю жизнь зажёг во мне любовь к физике. Позднее астрономический взгляд на вещи моего дедушки оказался, по счастливой случайности, полезным в моей карьере, о чём я рассказал ему во время одного из наших астрономических вечеров у него дома, в предгорьях Тусона.

Настройка алиасов (alias, псевдоним команды) была одной из первых задач, которую я решал, редактируя конфигурационные файлы (dotfiles) в Unix-подобных ОС. Вот пример одного из моих очень ранних алиасов:

alias g=git

Благодаря этой конструкции я могу, когда мне это нужно, вызвать, вместо команды git, команду g. Это позволяет сэкономить немного времени при использовании тех команд, к которым я прибегаю десятки раз в день!

# Теперь эти две команды равноценны:
git status
g status

Раньше я задавал псевдонимы команд с помощью команды alias. В конце концов… я ведь создавал то, что называется «alias»!

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

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

Для того чтобы отпраздновать то, что рассылка Product for Engineers набрала 50000 подписчиков, мы решили поделиться пятьюдесятью советами, в которых собрано всё самое важное, что мы узнали о разработке успешных программных продуктов.

Компьютеры имеют дело с числами — с большими и маленькими. При этом компьютерам необходимо оставаться в рамках ограничений, которые на них накладывает их физическая природа (размер регистров процессора и объём оперативной памяти). Следствием этого является тот факт, что процессоры обычно, на самом низком уровне, понимают лишь два типа чисел.

JSON — это широко распространённый формат, применяемый для хранения информации, основанной на обычном тексте. Он поддерживается самыми разными системами, обеспечивая их взаимодействие. Чаще всего это — веб-приложения и большие языковые модели (Large Language Model, LLM). Хотя JSON-данные удобны для восприятия человеком, их сложно обрабатывать, используя инструменты из сфер Data Science (наука о данных) и Data Engineering (инженерия данных).

JSON-данные часто существуют в виде JSON-строк (формат JSON Lines), отделённых друг от друга символами перевода строки (NDJSON, Newline-Delimited JSON). NDJSON используется для представления записей, входящих в состав набора данных. Часто первым этапом обработки данных является чтение файлов формата JSON Lines и преобразование их в объекты DataFrame (датафрейм).

В это материале мы сравним производительность и функционал API, доступных в Python и применяемых для преобразования формата JSON Lines в датафреймы.

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

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

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

Вы когда-нибудь сталкивались с трудностями в попытках извлечь из индивидуальных встреч максимум пользы? Если так — я могу дать вам несколько советов.

Ядро OpenBSD становится уже очень старым — ну просто очень — ему около сорока пяти лет. Оно, следовательно, не любит сюрпризов. Поэтому программы должны сообщать ему о том, где находятся их системные вызовы. В сегодняшнем выпуске «Вежливого программиста» мы поговорим о том, как это делать по всем правилам этикета.

Если вы программируете на C — всё это делается автоматически. Поэтому мы будем писать код только на языке, который совершенно нельзя назвать C, и при этом обойдёмся без линковки с libc.

Представьте, что вы создали пустую, приватную корзину (их ещё называют «бакетами» — от «bucket») AWS S3 в выбранном вами регионе. Каким будет счёт за услуги AWS на следующее утро?

Несколько недель назад я начал работу над прототипом системы индексирования документов для моего клиента. Я создал одну корзину S3 в регионе eu-west-1 и загрузил туда несколько файлов для тестирования. Через два дня я проверил мою страницу выставления счетов AWS, заглянув туда, преимущественно, для того, чтобы проверить, что то, чем я занимаюсь, нормально укладывается в лимиты бесплатного тарифного плана. Но, судя по тому, что я там увидел, ни о какой нормальности речи не шло. Мой счёт превышал $1300, а в консоли выставления счетов были видны сто миллионов PUT-запросов к корзине S3, выполненных всего за один день!

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

Я хочу, чтобы вы задали себе один вопрос и честно на него ответили. Когда в последний раз вы получали настоящее удовольствие от программирования? Оглядываясь назад, я понимаю, что не испытывал подобных ощущений, наверное… уже лет десять. Удовольствия у меня не было ни от JavaScript, ни от Python, ни от Ruby или C — ни от чего. Когда я говорю «удовольствие» — я имею в виду ощущения человека, которого во время работы над неким проектом переполняет искренний восторг. Этот человек постоянно ловит себя на такой мысли: «Ох, ну какая ж круть. Поверить не могу, что моя безумная идея и правда сработала!».

Например, я писал маленькую игру-«рогалик». У меня была такая идея: «Готов поспорить, что у меня получиться воспользоваться этим вашим алгоритмом Дейкстры для соединения комнат при генерировании карты, сначала инвертируя карту, а потом его запуская. Вероятно, мне удастся прокопать отличнейшие туннели между комнатами». То было благословенное время, когда я пытался справиться с этой задачей, и при этом не чувствовал, что C++ мне мешает. Мне тогда удалось решить эту задачу, попутно многому научившись. Потом у меня появилась такая мысль: «Интересно, получится мне взять пользовательский интерфейс, сделанный на FTXUI, и просто напрямую его отрендерить в окно визуализации SFML?». Как и следовало ожидать, у меня всё отлично получилось. И хотя это было не так уж и сложно, я по ходу дела много узнал о том, как в C++ обрабатывается юникод. Ни одна из этих задач лёгкой не была, но все их, в принципе, можно было решить, и я не могу напридумывать себе достаточно много «подводных камней», которыми C++ мог бы помешать мне сделать то, что я хочу. Это — то, что я называю «удовольствием».