Последнюю пару лет я переносил со службы домой и обратно «набор рабочих материалов» — видеофайлы и данные проектов, пользуясь внешним 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++ мог бы помешать мне сделать то, что я хочу. Это — то, что я называю «удовольствием».

Это — статья о том, как команда Media Ingestion компании Airbnb создала цифровые открытки для групповых путешествий. Открытки было решено задействовать в летнем выпуске платформы 2024 года. В проекте использовался новый алгоритм подбора материалов под различные туристические направления. Здесь же применялись возможности платформы по обработке изображений и локализованных текстов.

Готовясь к летнему выпуску Airbnb 2024 года, команда Media Ingestion взяла на себя интереснейшую задачу. Она заключалась в разработке надёжной системы для создания цифровых открыток. Это должны были быть открытки, выглядящие, как изделия ручной работы, и при этом отражающие особенности самых разных уголков мира. Отправка открытки — это прекрасный способ приглашать гостей в групповое путешествие, и, в то же время, держать в курсе происходящего семью и друзей. Система требовала нового подхода к сопоставлению открыток со всеми возможными местами проживания, которые гости бронируют на Airbnb. Эта система должна была очень быстро создавать открытки, причём — не только на всех наших клиентских платформах (iOS, Android, Web), но и в разных системах обмена сообщениями, которые находятся за пределами приложения Airbnb. И всё это должно было делаться без отступления от высоких стандартов графического дизайна компании.

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

Netflix продолжает расширять бизнес и диверсифицироваться в различных направлениях, вроде доставки видео по запросу и гейминга. В результате всё важнее становятся технологии, обеспечивающие загрузку временных (темпоральных) данных в системы компании и их хранение. Речь идёт об огромных объёмах данных, измеряемых петабайтами. А задержки доступа к этим данным должны укладываться в миллисекунду. В предыдущих материалах мы рассказывали о нашем слое абстракции для хранения данных типа «ключ-значение», и о платформе, реализующий возможности шлюза данных. И то и другое — это неотъемлемые части подсистемы, отвечающей в Netflix за работу с данными. Система хранения данных типа «ключ-значение» — это гибкое и хорошо масштабируемое решение для работы со структурированными данными соответствующего формата. А шлюз данных — это платформа, которая даёт компании базовую инфраструктуру, обеспечивающую защиту, настройку, развёртывание компонентов, ориентированных на работу с данными.

Наша компания — Netflix — способна организовывать бесперебойную, высококачественную потоковую передачу видео миллионам пользователей благодаря своей надёжной глобальной серверной инфраструктуре. В самом центре этой инфраструктуры лежит множество онлайновых распределённых баз данных. Среди них — Apache Cassandra — NoSQL-СУБД, известная высокой доступностью и хорошей масштабируемостью. Cassandra играет роль опорной технологии для множества самых разных возможностей Netflix: от механизма входа пользователя в систему — до хранения истории просмотренных материалов и до поддержки аналитики реального времени и прямых трансляций.

Со временем появлялись новые базы данных типа «ключ-значение» (Key-Value, KV), владельцы сервисов вводили в строй новый функционал. В результате мы столкнулись с массой сложностей, связанных с неправильным использованием хранилищ данных. Во-первых — разработчикам сложно оперировать такими понятиями, как производительность хранилищ данных, согласованность и устойчивость данных. Ведь речь идёт о взаимодействии со сложной системой глобальных масштабов, представленной множеством хранилищ. Во-вторых — разработчикам приходилось постоянно переучиваться, осваивая новые подходы к моделированию данных и распространённые, но очень важные паттерны доступа к данным. В перечень сложностей, встающих перед разработчиками, входят высокие задержки, которым подвержен небольшой процент запросов, находящихся в «хвосте» распределения задержек (tail latency) и идемпотентность операций. Тут же можно упомянуть и поддержку работы «широких» разделов хранилищ с множеством строк, и работу в условиях, когда для хранения данных применяется единственный «толстый» столбец, и медленную пагинацию ответов. Кроме того — наши системы были связаны с множеством собственных API разных баз данных — с API, которые постоянно развивались, и в которых иногда появлялись изменения, нарушающие обратную совместимость. Всё это привело к тому, что инженеры, в масштабах всей организации, тратили много времени на поддержку и оптимизацию механизмов доступа к данным наших микросервисов.