Здравствуйте, друзья, меня зовут Ерохин Кирилл, я программист‑любитель, и в этом сентябре я втихаря провёл соревнование по алгоритмическому программированию на C/C++ под платформу «Эльбрус» (e2k), собрав 31 участника со всей России, результатами которого я решил поделиться с вами. А Хабр мне в этом поможет, ему не впервой.

Оглавление:

• Предыстория, которую можно пропустить

• Подготовка к соревнованию

  • Целевая аудитория

  • Время проведения

  • Инструментарий

  • Формат проведения

  • Задачи

• Поиск участников

• Презентационная часть

• Создание АНО «СЭРПАС»

• Старт отборочного этапа

• Финальный этап и стрим

• Что дальше?

Предыстория, которую можно пропустить

Для меня, как, наверное, и для многих моих сверстников, знакомство с «Эльбрусами», тогда ещё «Эльбрус-2000», произошло в самом начале нулевых из журналов компьютерной тематики. Какого именно журнала, увы, сейчас вспомнить не могу. Поиск в интернете находит статью «Эльбрус Бабаяна и Pentium Пентковского» в iXBT аж от 5 июля 1999 года.

После такой яркой новости, придавшей импульс горячим обсуждениям в публичном поле, лично для меня настал период затишья: крапива сама себя палкой не побьёт, средняя и старшая школа, выпускные экзамены и поступление в университет сделали своё дело, и тема «Эльбрусов» на время покинула моё информационное поле, тем более информация тогда распространялась куда медленнее, чем сегодня. Да и скорость реализации (читай, финансирования) проекта «Эльбрус-2000» была ожидаемо небольшой. В конце концов у Itanium и Crusoe были Intel, HP, Transmeta, инвестиции и глобальные рынки, а у нас страна только‑только начинала оправляться после 90-х.

Во время учёбы в университете до меня, как и до остальных, стали доходить новости, что «Эльбрус», пройдя через все перипетии судьбы, добрался до реализации в кремнии и конечных изделиях в виде микропроцессора «Эльбрус» и комплекса «Эльбрус-3М1», пусть и в «военке». А значит, у ребят из МЦСТ всё получилось, и, что важнее, удалось сохранить коллектив и компетенции.

За 17 лет разработчики выпустили как минимум 9 процессоров серии «Эльбрус», сменивших 6 поколений микроархитектур. Помимо этого, пусть очень маленькими, но всё же шагами вокруг Эльбрусов развивалось сообщество энтузиастов. В 2020 году появляются группа энтузиастов «Elbrus PC Test», запускающих игры на Эльбрусах (были бы исходники под Линукс), сообщества «Процессоры Эльбрус | Фан‑клуб» и «Эльбрус дома» в Telegram и, конечно же, интернет‑магазин IMAXAI (ныне почивший), через который можно было заказать электронику, разработанную или произведённую в России частным лицам.

Около года назад именно через магазин IMAXAI я и приобрёл материнскую плату «1Э8СВ‑TmITX» со встроенным процессором Эльбрус-8СВ.

Видео от PRO Hi‑Tech, а точнее его концовка про сообщество, которому нужны энтузиасты, любители и программисты, оказалась для меня тем триггером, который в итоге и привёл к идее о проведении соревнования. Идея приобщить ПК на Эльбрусе к использованию сообществом витала в моей голове почти с момента его приобретения, ведь я, как и ты, мой читатель, во всех смыслах человек деловой и занятой, и ПК большую часть дня, по крайней мере светового, простаивал без дела. А для такой экзотики, как 8-ядерный Эльбрус, это недопустимая расточительность.

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

Подготовка к соревнованию

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

Помимо этого, не стоило забывать про презентационную часть. Понятно, что энтузиазм был главной движущей силой в данном мероприятии как для меня, так и для участников, пусть и в меньшей степени. Как заметил один из потенциальных участников: «Сожалею, но я за бесплатно не программирую». В общем, много участников привлечь на «голый» Telegram-канал или VK-группу не получилось бы, и нужно было обеспечить соревнованию красивую «обложку».

Целевая аудитория

Трудностей с определением целевой аудитории не возникло. Определяющими факторами для потенциальных участников были:

• знание базовых для экосистемы Эльбруса языков программирования C/C++ (есть и другие, но с нюансами);

• умение хоть немного работать с Linux;

• совершеннолетие;

• потенциальное наличие свободного времени.

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

Время проведения

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

Инструментарий

С инструментарием всё было сложнее, поскольку под ним подразумевается не только платформа регистрации и взаимодействия с участниками соревнования, но и платформа обработки и учёта их решений. Конечно, есть уйма достойных российских платформ по проведению онлайн‑соревнований по программированию. Но есть нюанс: у нас с вами — Эльбрус (e2k), с которым бэкенд платформ не был знаком и которого физически у них не было. Очевидно, что за просто так, да и за такой короткий срок (3 месяца), да ещё и летом никто бы не взялся адаптировать/интегрировать свой бэкенд с удалённым сервером на Эльбрусе.

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

Помимо этого у ВКонтакте есть очень важная функция, о которой мало кто знает. ВКонтакте позволяет провести идентификацию участника по его имени и фамилии без необходимости организатору мероприятия взаимодействовать с документами, удостоверяющими личность участника, а мне ОЧЕНЬ не хотелось хоть как‑то взаимодействовать с фото/сканами паспортов участников (считай, обрабатывать и хранить их). Эта функция называется «подтверждение данных аккаунта», она даёт «серую галочку» рядом с именем пользователя ВКонтакте. Для меня было важно знать, кто изначально регистрируется на отборочный этап и что именно эти же люди, хотя бы формально, будут участвовать в финальном этапе и займут призовые места. Оперативное общение с участниками соревнования осуществлялось через закрытую группу в Telegram.

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

Такая задача, наверное, не представляет из себя ничего особенного для мидла или сеньора, но я в последний раз программировал на C++ 15 лет назад. Да, после этого я периодически баловался PHP и JS, поэтому у меня сохранились базовые навыки программирования в целом и на Си‑подобных языках в частности, но это нельзя назвать достаточной практикой для поддержания сколько‑нибудь значимого скилла. К счастью, у меня в рукаве был один козырь — это, конечно же, вайб‑кодинг. Стоит признать, что если бы не нейросети, то соревнование бы не состоялось. Запас времени до старта соревнования действительно был большой, но не для программиста‑любителя с 15-летним перерывом в программировании.

В отношении участников ограничения на использование нейросетей также отсутствовали. В этом не было никакого смысла, поскольку соревнование проводилось в онлайн‑формате, и пытаться контролировать это было бы просто глупо, а главное, как сказал мне один человек, «...это уже неизбежное зло в такого рода соревнованиях, и поделать с этим что‑то сложно». Тем более в особые оптимизации конкретно под Эльбрус (e2k) нейросети всё равно не умеют.

Формат проведения

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

После изучения предметной области стало понятно, что, по сути, я хочу провести соревнование по спортивному программированию в дисциплине алгоритмическое программирование, но с небольшим нюансом: в классическом алгоритмическом программировании «краеугольным камнем» является скорость, с которой участник решает задачи, по этой метрике в конечном итоге определяются лучшие и худшие участники. В контексте использования Эльбрусов (e2k) такой подход вряд ли можно считать приемлемым, поскольку необходимость отдельной оптимизации программ при их портировании с x86 на e2k является одной из самых горячих тем для обсуждения в публичном поле. По этой причине для своего соревнования я выбрал «эффективность» решений, а точнее мой доморощенный коэффициент эффективности, в качестве ключевой метрики при определении лучших участников: использование коэффициента эффективности в качестве метрики — решение, безусловно, максимально претенциозное и, при всей своей кажущейся простоте, максимально спорное с точки зрения определения критериев этой самой эффективности.

В основу формулы расчёта коэффициента эффективности я заложил простой принцип: «10% прироста скорости стоит не более 20% увеличения потребления памяти». Я понимал, что в реальной жизни в зависимости от конкретной ситуации и условий такая метрика может быть как достаточно релевантной, так и классической «средней температурой по больнице», которая что-то показывает и ничего по существу не отражает, но времени искать что-то более точное и не менее универсальное банально не было. В мире встраиваемых систем и IoT штраф за каждый дополнительный использованный мегабайт огромен (ОЗУ распаяна на плате, ее мало и она медленная), а для мира распределённых (облачных) вычислений с условно бесконечной возможностью расширения объёма ОЗУ (инвесторы же «банкуют», она нам ничего не стоит, лол!) штраф за увеличение потребления памяти минимален. Однако у выбранного мною подхода есть огромное преимущество, которые перевешивает всё остальное, она проста в расчёте и восприятии, а это для массового мероприятия с относительно небольшим порогом входа куда важнее.

Если у тебя, дорогой читатель, есть более логичный, точный и элегантный способ определения эффективности вычислений (кода), я очень прошу поделиться им со мной и остальными читателями в комментариях.

Было решено разделить соревнование на два этапа: отборочный (групповой) и финальный (плей‑офф). При этом в мелких деталях у обоих этапов были свои отличия от принятых стандартов.

На решение всех 4 задач для обоих этапов я выделил 7 суток специально, чтобы участники смогли всё распланировать, спокойно работать и параллельно учиться. Приступить к решениям, получив SSH‑ключ и условия задач, можно было, выбрав день старта в период с 1 по 12 сентября. Предварительно, конечно же, нужно было получить допуск, протестировав SSH‑подключение к ПК на Эльбрусе и правильно настроив IDE.

Задачи

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

Задачи отборочного этапа должны:

• быть достаточно простыми для студентов‑программистов 18–24 лет, только вернувшихся с летних каникул;

• хорошо поддаваться классическим оптимизациям (распараллеливание, работа с кешем, оптимизация циклов, выравнивание структур данных, выбор подходящих типов переменных и так далее).

В итоге я решил остановиться на самых базовых задачах линейной алгебры:

• Задача 1: решение СЛАУ;

• Задача 2: вычисление определителя матрицы;

• Задача 3: перемножение двух матриц.

Они были знакомы даже второкурсникам, они прекрасно оптимизируются, и я сам смогу их решить, установив тем самым значения констант T⁰ и M⁰ на основе своих решений для вычисления коэффициента эффективности E. Также стоит заметить, что при решении задач нельзя было использовать высокопроизводительные библиотеки и API для вычислений (EML, Imath, Boost, BLAS, LAPACK и так далее), их я либо удалил, либо не устанавливал в систему вовсе, а самостоятельно участники не могли их установить. Конечно, можно было взять исходники оригинальных библиотек и встроить в своё решение, фактически портировав их на e2k, и, тем самым, усложнив себе исходную задачу в разы.

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

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

Поиск участников

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

На ближайшие два месяца свободное время было занято марафонами по переписке с потенциальными участниками, которые состояли из знакомства, краткого описания соревнования и предложения в нём поучаствовать. Конечно, примерно каждый третий собеседник игнорировал моё обращение, либо сразу банил меня с жалобой, поэтому в принудительном «мьюте» я висел регулярно. Особенно тяжко в этом плане было в WhatsApp, в нём около половины (55%) собеседников игнорировали либо сразу банили, в Telegram и ВКонтакте всё было куда более дружелюбно, только четверть (28%) и треть (35%) соответственно не хотели предоставлять мне аудиенцию. Видимо, сказалась в целом не самая хорошая репутация WhatsApp в отношении спама.

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

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

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

По итогу удалось собрать 127 потенциальных участников соревнования, чьё количество было немного больше до открытия фактической регистрации в августе. Часть участников, ранее согласившихся на участие, когда я написал им повторно, были очень удивлены, поскольку дважды успели забыть и про соревнование, и про меня. Кто‑то из них отказывался, а некоторые и вовсе не отвечали. Лето есть лето, как говорится, «Обещать — не значит жениться». Из‑за этого пришлось дополнительно делать марафон по добору участников в августе, по результату которого и получилась цифра в 127 потенциальных участника.

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

Далее следовала процедура допуска (тестирования SSH‑подключения и настройки IDE), которая была доступна сразу после регистрации участника и продолжалась до середины сентября. При этом ничего не мешало получить его непосредственно перед стартом решения задач. По завершению периода допуска его не прошло 15 человек из зарегистрировавшихся по разным причинам: у кого‑то учеба, работа или личные обстоятельства, а кто‑то банально заболел.

Презентационная часть

Создание АНО «СЭРПАС»

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

Официальная структура нужна была в первую очередь мне, призовые‑то я планировал платить из своего кармана, и летающие по СБП сотни и десятки тысяч рублей с точки зрения как самих банков, так и налоговой могли выглядеть очень неоднозначно, и давать им лишний повод для беспокойства в мои планы не входило. Помимо этого, такая структура нужна была и для будущих партнёров (жертвователей, грантодателей, меценатов). Нужно было смотреть правде в глаза: один я в финансовом плане не смогу эффективно развивать историю с соревнованиями, а смогу только дать хороший начальный импульс. «Не рановато?» — спросишь ты, уважаемый читатель. «Самое время!» — отвечу я тебе, дорогой друг.

Так уж сложилось, что в своей профессиональной деятельности у меня есть практический опыт работы в областях, связанных с развитием продуктов, брендов и их позиционированием на B2B‑рынке, в каждой по чуть‑чуть. И то, что лучше всего уяснил в их отношении, можно описать поговоркой «Лучше рано, чем поздно».

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

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

• юридическом (он знает, как правильно оформить документы?);

• финансовом (у него есть долги и исполнительные производства?);

• административном (он вообще способен выполнять взятые обязательства, не загуляет?).

А если дорогой читатель и сам имеет долгий опыт работы с фрилансерами, он и сам всё это прекрасно знает (а то и больше).

При работе же с юридическими лицами всё меняется до наоборот:

• юридические лица регулярно проверяются как минимум налоговыми органами, а НКО ещё и Минюстом;

• бухгалтерская отчётность большинства компаний уже давно является публичной информацией (ресурс БФО);

• их связи на уровне учредителей и генеральных директоров проверяются ещё проще, под ключ, с блокировками счетов, статусом банкротства, судами и прочей информацией (List‑Org).

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

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

В качестве организационно‑правовой формы я выбрал АНО, поскольку задачи вести предпринимательскую деятельность, накапливать капитал и выплачивать себе дивиденды у меня не было. Профессионально реализуюсь и зарабатываю деньги я в другом месте. Да и работать с партнёрами в будущем на порядок будет проще (кто готов делать благотворительный взнос в ООО?).

При выборе названия я руководствовался простыми принципами:

• в соответствии с принятыми нормами название АНО должно отражать предмет его деятельности, хотя бы косвенно;

• сокращённое название АНО должно быть кратким, благозвучным и не выглядеть как случайный набор заглавных букв, это просто непрезентабельно. АНО ЦСРКСТ, АНО ЦРВБД и АНО АСРСИППС не дадут соврать;

• доменное имя и короткие имена в основных соцсетях и мессенджерах, соответствующие сокращённому названию АНО на латинице, не должны быть заняты.

Старт отборочного этапа

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

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

Со стартом соревнования меньше работы лично для меня не стало, как бы я не надеялся на обратное.

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

Во‑вторых, как бы я ни старался с тестированием своей доморощенной утилиты для контрольных прогонов решений, багов в ней было припрятано достаточно. Благо количество участников, стартовавших на первой неделе сентября, было невелико (как бы сильно я ни уговаривал всех не стартовать в самый последний момент). По этой причине мне удалось залатать все баги инструментария без значительного влияния на ход отборочного этапа, хотя участникам, стартовавшим первыми и ставшим фактически бета‑тестерами, пришлось давать дополнительное время для компенсации потерянного на борьбе с багами времени.

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

Так, достаточно слабым местом инструментария оказался способ определения пикового размера потребления памяти программой (решением). Количество метрик, отвечающих за выражение того или иного количества памяти, потребляемой или зарезервированной в Linux, у неподготовленного программиста (то есть меня) легко может вызвать оторопь: VSZ (VmSize), PSS, RSS, USS, VmHWM, VmPeak, а помимо этого есть ещё память, занимаемая статическими переменными, которая не определяется предыдущими метриками. Для её определения нужно потрошить сам бинарник на предмет размеров сегментов data и bss (спасибо на замечание одного из участников соревнования). Добавлять такой функционал в инструментарий было поздно, да и вряд ли я справился даже с помощью нейросетей, поэтому пришлось вручную проверять эти сегменты консольной командой size. В итоге я решил остановиться на варианте RSS + data + bss при определении размера памяти, потребляемой программой (решением) участников.

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

Из IDE участники ожидаемо отдавали предпочтение VS Code (27), хотя и другие варианты они тоже не обделили вниманием — Neovim (3) и CLion (1). Стоит отметить, что как VS Code, так и CLion достаточно легко настраиваются для удалённой отладки и компиляции программ под e2k через SSH и gdbserver.

Самым занятным же было то, что большая часть участников отборочного этапа, в общем‑то, ничего толком и не знала про процессоры «Эльбрус» и архитектуру e2k до соревнования. Ответ «Знаю только, что они существуют» в опроснике при регистрации выбрали 20 из 31 участника, а «Периодически видели новости про них» 9 участников, 1 участник «Регулярно интересовался материалами о них», а 1 участник даже «Имел реальный опыт работы с Эльбрусами». Забегая вперёд, можно сказать, что этот нюанс не помешал участникам (в основном студентам) оптимизировать скорость вычислений своих решений и выжать из железа значительную часть своего потенциала.

Для расчёта коэффициента эффективности (вычислений) E^выч участников для каждой задачи требовалось определить две константы: базовое время решения задачи T⁰ и базовый размер памяти, использованный программой M⁰. Фактически ими стали метрики моих собственных решений, максимально медленные, в один поток и без намёков на оптимизацию. Их было удобно использовать в качестве стартовых точек отсчёта для результатов участников.

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

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

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

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

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

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

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

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

Финальный этап и стрим

Итак, отборочные успешно завершились, и 16 лучших участников прошли в финальный этап, а мне предстояло в считанные дни разобраться с тем, как пользоваться OBS Studio, и договориться о проведении лайвкодинг‑сессии по оптимизации программы решения одной из задач отборочного этапа.

Конечно, я заранее начал договариваться с опытными специалистами о проведении лайвкодинг‑сессии, и к моменту завершения отборочного этапа всё было оговорено, но, как это часто бывает, в дело вмешался случай. За пару дней до стрима выяснилось, что «ведущий» лайвкодинг‑сессии не сможет принять участие в стриме, и мне пришлось оперативно обратиться к разработчику процессора (МЦСТ) и попросить предоставить своего штатного специалиста для проведения лайвкодинг‑сессии. К счастью, ребята не отказали в помощи, и мне на помощь оперативно пришла Эльвира Шарипова, программистка из магистратуры МИФИ, которая подготовила прекрасную сессию, записав получасовое видео, в котором она буквально разжевала практически каждый свой шаг в ходе оптимизации кода под e2k. Да, лайвкодинг‑сессия была на стриме в записи, я же не сумасшедший — в свой первый в жизни стрим вообще всё стримить вживую без подстраховки.

Начавшись в 18:00, стрим, в который вошли затянувшееся введение про Эльбрусы и само соревнование, лайвкодинг‑сессия, подведение итогов финала и общение с участниками соревнования, продлился два с половиной часа. Он завершился, и впервые за несколько месяцев я смог выдохнуть, почувствовав свалившуюся гору с плеч. Я запорол несколько первых секунд лайвкодинг‑сессии Эльвиры из‑за того, что запутался в интерфейсе OBS Studio, и позже мне, конечно же, пришлось редактировать запись перед тем, как выложить её в открытый доступ.

Призовой фонд в размере 215 000 ₽ в итоге был разыгран между 5 участниками: тремя призёрами финального этапа и двумя участниками, отличившимися в отборочном этапе. Призёрами финала стали:

1. Николай «kirpatik» Либельт ННТУ’26, бакалавр, 115 000 ₽

2. Рустам «t138szx» Ванчугов ВятГУ’24, бакалавр, 66 500 ₽

3. Ильсур «@flexus7» Гумеров ИТМО’26, магистр, 27 000 ₽

4. Данила «Kir‑Dykov» Баин ЯрГУ’26, магистр

Отличившиеся в отборочном этапе участники:

• Павел «@ockop6uhka» Федоренко РГУ им.Косыгина«25, бакалавр, 5 000 ₽

• Дмитрий «Crestfallen» Кощей ДВГУПС«26, бакалавр, 1 500 ₽

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

Также я не могу не поблагодарить ребят, которые «пиарили» соревнование в своих соцсетях:

• Максима «imaxai» Горшенина и его канал imaxairu;

• Ребят из PRO Hi‑Tech и их канал prohitec;

• Ребят с из Elbrus PC Play и их канал elbrus_pc_test;

• Сообщество Русский процессор «ЭЛЬБРУС» и их группу elbrus_mcst;

• Антона «@toxblh» Палгунова и его канал toxblh_linux и проект PLAFON;

• Сообщество «Эльбрус Дома».

Перечень официальных документов по соревнованию:

Скрытый текст

• Положение

• Регламент

• Список зарегистрированных участников

• Задачи отборочного этапа

• Итоговый протокол отборочного этапа

• Задача финального этапа

• Итоговый протокол соревнования

Обезличенные исходные данные участников (включая отказавшихся и проигнорировавших) в табличном виде: https://www.serpas.ru/contest/sca25/sca25_dataset.xlsx

Решения участников, пожелавших опубликовать свои исходники: https://gitflic.ru/project/serpas/sca25/file/?file=solutions&branch=master

Что дальше?

А дальше будет весенний сезон соревнования в марте 2026 года, подготовку к которому я уже начал, ведь программа‑минимум — обеспечить не менее 100 активных участников в отборочном этапе, а, судя по моей же статистике прошедшего соревнования, мне придётся написать примерно 1400 потенциальным участникам.

А если в марте 2026 тебе, мой дорогой читатель, будет от 18 до 24 (или около того), то приглашаю принять участие в соревновании «Кубок СЭРПАС Весна 2026». Предварительная регистрация на него откроется уже в этом декабре, а пока можно подписаться на группу во «ВКонтакте» или на Телеграм‑канал, где будет освещаться ход подготовки к соревнованию. Там вы точно не пропустите момент начала предварительной регистрации.

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

P. S. Некоторые читатели ожидаемо могли поторопиться и записать меня в фанаты каких‑то конкретных российских брендов, компаний или их продукции. Однако спешу заметить, что мне интересны все достойные отечественные разработки в области программного и аппаратного обеспечения, а уж какая из этих разработок попала первой ко мне в руки — ну тут уж дело случая. Это, в свою очередь, не означает, что я, как полоумный, вопреки здравому смыслу, пользуюсь везде и во всём только «отечественным», действуя по принципу «в каждой бочке затычка». Но непосредственный фокус моих публичных изысканий будет направлен именно на то, что разработано или произведено людьми, с которыми я родился и живу в одной стране. А если в продаже (хотя бы на B2B‑рынке) появится процессор общего назначения ещё с какой‑нибудь любопытной архитектурой, то я и на нём проведу соревнование, чего уж теперь‑то стесняться. Первый шаг, как ему и подобает, был самым трудным, а дальше всё пойдёт по накатанной.

P. S. S. Обязательно посмотрите запись стрима на YouTube, VK Видео или RuTube, хотя бы ради лайвкодинг‑сессии и общения с участниками, они по итогу вышли куда живее, чем «сухой» подсчёт результатов и определение победителя.

И нет, проживание на Эльбрусе не оплачивается.

---

Не забудьте подписаться на Телеграм‑канал и группу во «ВКонтакте» сообщества.