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

Все части цикла статей о создании DOOM:

• Первая ← Вы здесь
• Вторая
• Третья
• Четвёртая
• Пятая
• Шестая
• Седьмая
• Восьмая
• Девятая

Когда я был маленький, то на меня снизошла милость божЫя и ниспослала мне две книжки. Одна книжка была про бейсик для студентов каких-то там ВУЗов, а вторая - «Паскаль в иллюстрациях». По одному из абзацев первой книжки я в принципе научился программировать в пятом классе - там был мозголомающий отрывок с программой, заставляющей нолик летать по экрану, отталкиваясь от стенок. Вторая книжка, отданная мне соседом-алкашом, познакомила с алгоритмами. На дворе стояли 90-е — начало компьютерной эры человечества. Компьютера у меня при этом не было — я видел его пару раз в неделю на компьютерном кружке, ведущей которого была вчерашняя или даже сегодняшняя студентка, отпирающая и запирающая дверь — большего от неё нам и не требовалось.

Привет, Хабр.

Меня зовут Андрей Белобров. Я тимлид одной из команд, разрабатывающих приложения для умных девайсов Сбера.

На прошедшей недавно конференции Салют, OS DevConf! я выступил с докладом, в котором рассказал, как мы с командой разрабатываем приложения на С++ для умных устройств с виртуальным ассистентом. А также о том, как инструменты статического и динамического анализа помогают поддерживать единый стиль и высокое качество кода в проекте.

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

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

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

Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт. Можно уволить программиста и на его место придет другой и через условные месяц-два-полгода начнет закрывать таски не хуже. Если увольняется дизайнер, его монстр, пушка или контент повисает без хозяина и без "видения". Если её не перехватил сосед (а у соседа свой монстр), то в большинстве случаев его работа просто уходит в стол и монстра пишут заново на тех же ассетах и принципах, но заново.

Если увольняется арт-директор, который несет "видение" проекта, то проекту становится очень плохо, в большинстве случаев визуально он изменится до неузнаваемости, хотя ассеты могут быть те же самые. Программисты делают всё, кроме самой игры: рендер, звук, физику, сеть, AI, инверсную кинематику, поиск пути и т.д. Можем подискутировать в комментариях.

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

Упомянутая в заглавии книга (далее H&H) - это про железо [15]. Я - про программирование, но на базе "железной модели" конечного автомата. И там и там математическая основа одна. Все это, действительно, крутая железная концепция, помогающая поставить не только синтез цифровых схем, но и программирование на совершенно другие рельсы, определяющие его будущее.

Параллелизм у программистов нынче в моде. Но, видимо, они (программисты) совсем не в курсе, что разработчики железа давным-давно погружены в эту тему. А потому им (я все про программистов) есть у кого поучиться. Но, похоже, некие амбиции-заскоки этому  мешают. Но, если вы этим не страдаете, то прочитайте книгу H&H и дойдите, ну, хотя бы до 4-й главы. Попробуйте реализовать одно-два упражнения, используя свой, программистский инструментарий - всякие там корутины, потоки и весь сопутствующий этому террариум. Убедитесь в его полном бессилии. И тогда, может, это заставит кое-что пересмотреть, переосмыслить. Только представьте: логический элемент - отдельный процесс, десятки, сотни, тысячи элементов - множество параллельных процессов, и все это в вашей ладошке (это я про смартфон) и даже работает!

Но пришло время исполнять обещанное (см. предыдущую часть темы в [1]). И пусть количество "плюсов" пока не достигло заданной планки, но ... если каждый "минус" считать за два "плюса", то это уже более чем ... ;) Так что спасибо всем, давшим положительную оценку - нет, не автору, а затронутой теме. Области знаний, от которой многое сейчас зависит.  Это те слова, которые мы вправе сказать в адрес теории, посвященной  синтезу цифровых схем, в адрес тех, кто занимался и занимается ее развитием, становлением и внедрением в практику.

Меня зовут Андрей Бакшаев, я ведущий инженер-программист в YADRO. Моя команда занимается разработкой и оптимизацией математических библиотек под архитектуру x86. До этого я 15 лет работал в Intel. Значительная часть моих задач заключалась в том, чтобы реализовывать некоторые алгоритмы обработки изображений и сигналов в довольно известной математической библиотеке IPP, максимально эффективно используя возможности процессоров. Я также исследовал производительность этих алгоритмов в процессорах на ранней стадии проектирования. 

В статье я поделюсь своим опытом оптимизации низкоуровневого кода на языке C. Рассмотрим подсистему кэша и памяти процессоров и новые инструкции AVX-512. Разберем пример ускорения копирования байтового массива данных и посмотрим, как векторизованный код позволяет сократить время работы широко используемого алгоритма замены байтов по таблице с 619 до 34 мс, то есть примерно в 18 раз. 

В шейдере мы можем написать vec3 v0 = v1.xxy * 2 и любую другую комбинацию x, y, z и w в зависимости от длины вектора. Я рассматриваю только размеры вектора до 4, как самые распространенные для использования. Полученный вектор может не иметь той же самой размерности, как в меньшую так и в большую сторону и его компоненты могут быть скопированы в произвольном порядке. Это операция называется "swizzle" и это чертовски удобно для различных операций с малоразмерными векторами, особенно если они представляют игровые сущности в виде позиций, размера или цветов. Вектора используются повсюду в игровых проектах (да и не только в игровых), и не только в шейдерах. В какой-то момент swizzle было решено затащить и в наш игровой движок в базовые классы vec2, vec3 и vec4. Возникли вопросы: как добиться такого же синтаксического и семантического поведения в C++ коде, при этом минимизируя потери производительности.

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

Да, уже были статьи про собеседование и даже в эту же структуру, некоторые из них я видел, но не во всём с ними согласен, к тому же конкретно С++ разработчиков я там не видел.

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

На данный момент контент нашего блога можно разделить на 4 основные категории:

1. Теоретические статьи;
2. Информационно-развлекательные статьи;
3. Проверка открытых проектов;
4. Всё остальное.

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

Я просто опишу несколько случаев, и станет ясно, «почему».

Случай 1. В детстве у меня был обширный ожог на груди от кипящей воды. Мать хотела улучшить мою внешность — уменьшить размер шрамов. Мы пошли с ней к доктору (мне было 6 лет), он вырезал мне большой кусок кожи, от правого плеча до локтя левой руки, а оставшуюся кожу стянул и сшил. Всю жизнь я ходил с этим шрамом от скальпеля, который был ужасно жестким. Для рассасывания шрама мне кололи лидазу, но это не помогло. В результате вместо мягкого шрама от ожога я получил очень жесткий шрам от скальпеля, сейчас он имеет длину в полметра, стянул мои плечи и перекосил положение грудных сосков. В 45 лет этот шрам превратился во что‑то типа кости. Эта «кость» прорвала кожу, вылезла наружу и мне пришлось делать операцию по удалению «кости» с помощью лазера. Та часть шрама от ожога, которая не была тронута скальпелем, осталась мягкой и никогда мне не мешала. Я не знаю, но думаю, моя мать много заплатила хирургу, чтобы он сделал лучше. Это было в 1960 году, прошло только 15 лет после войны, было ведь много раненых и обожженных. Неужели хирург не знал, что получится в результате?

Что я могу думать о врачах после этого? Они лечат или калечат?

Случай 2. В 19 лет у меня появились боли в области сердца, несколько лет не мог спать на левом боку. Пошел к терапевту, сняли ЭКГ — ничего не нашли. При описании жалобы я говорил: «странно, но у меня эти боли проходят после того, как позанимаюсь с гирей». Терапевт и кардиолог, снимавший ЭКГ, посмеялись и отпустили меня ни с чем.

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

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

Яндекс отчитался за 2 квартал (и первое полугодие) 2023 года, и в отчете я обнаружил много интересного. Я уже на протяжении 4 лет разбираю каждый квартал отчетность Яндекса, и это 16-й по счёту отчет (и, возможно, это последний разбор в общем доступе). Так что я уже знаю, куда смотреть и что там можно увидеть.