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

1. Когда сложившаяся архитектура подлежит масштабным изменениям.

2. Что не менее важно, когда лучше оставить, как есть.

3. Ключевые признаки проблем в архитектуре.

4. Основные способы исправления таких проблем.

Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:

1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.

2. Что маленькие команды работают буквально в разы эффективнее, чем большие.

3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.

Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».

«We have a phrase inside Intel. We are supposed to be a data driven company and the phrase is, "Don't argue with the emotions, argue with the data."»

Andrew S. Grove, Chairman of the Board, Intel Corporation, August 9, 1998

В июле 2023-го года в «Байкал Электроникс» стартовал проект по разработке собственного AI-процессора. В данной публикации мы хотим рассказать, почему мы выбрали именно архитектуру GPGPU, какими данными при решении мы руководствовались, а во второй части немного рассказать о ходе разработки и поделиться полученным опытом.

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

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

Статья рассчитана на читателей, которые не являются гуру C++ или знатоками тонкостей языка, но в целом знакомы с языком и его идеями, хотя знание ассемблера x86 не требуется, я буду прикладывать ссылки на примеры кода quickbench, чтобы объяснить, почему даю те или иные советы.

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

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

1. Закон Паркинсона.
2. Закон Хофштадтера.
3. Закон Брукса.
4. Закон Конвея (и обратный закон Конвея).
5. Закон Каннингема.
6. Закон Старджона.
7. Закон Завински.
8. Закон Хайрама.
9. Закон Прайса.
10. Эффект Рингельмана.
11. Закон Гудхарта.
12. Закон Гилба.
13. Закон Мёрфи.

Я думаю, многие в курсе о том, что недавно в Париже торжественно открыли отреставрированный после большого пожара Собор Нотр-Дам-де-Пари. Однако знаете ли вы, что пожар не успели вовремя потушить, так как новый охранник получил от сигнализации код ZDA-110-3-15-1 (привет UX!) вроде как указывающий на точное место возгорания. Но охранник не смог его интерпретировать и 30 минут просто искал, где это место. За это время пожар успел разгореться и потушить его уже не получилось. На реставрацию потратили более 900 миллионов долларов. Хорошая цена за плохой UI/UX, не правда ли?

Цифровой двойник (Digital Twin, DT) представляет собой виртуальную копию физической системы, которая обновляется в реальном времени на основе данных, поступающих с реального объекта. Это динамическая модель, объединяющая физико-математические модели системы с методами анализа данных. Согласно прогнозам Gartner, технология цифровых двойников станет широко востребованной в ближайшие пять лет.

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

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

В 1970 году Билл Хардинг задумал создать полностью автоматизированную линию по производству кремниевых пластин, способную выпускать полностью готовые интегральные схемы с производственным циклом не более одних суток. В наши дни сроки изготовления передовых ИС измеряются неделями, а не днями. Представьте себе, как смело и даже дерзко выглядела эта задача 54 года назад! В те времена производство ИС, например, чипов памяти с произвольным доступом, растягивалось на месяц и требовало выполнения многих десятков ручных операций на всех этапах.

На тот момент Хардинг руководил отделом производственных исследований IBM в Ист-Фишкилле, штат Нью-Йорк. А проект, который он открыл, чтобы воплотить задуманное в жизнь, назывался Project SWIFT. Чтобы добиться столь короткого производственного цикла, требовался невероятный уровень автоматизации, достичь которого можно было только путем кардинального переосмысления принципов проектирования линий по производству микросхем.

C и C++ не имеют встроенной сборки мусора, поэтому разработчик сам решает, как и когда выделять и освобождать память. Мы, конечно, можем покивать в сторону STL, сокрытия аллокаций в контейнерах, но от этого они никуда не денутся. Просто если раньше приходилось думать про выделенный кусок памяти, понимать, как он скажется на времени фрейма, помнить, что его надо удалить (а может, не надо и стоит оставить на следующий фрейм), то теперь всё заворачивается в сахарные контейнеры и разработку в стиле STL-blin-vse-sterpit. STL-то может и стерпит, и даже как-то будет ворочаться, однако не стоит полагаться исключительно на системный аллокатор, бездумно вызывая new или malloc для каждого запроса памяти. Вы ведь понимаете, что std::vector посреди цикла или горячей функции — это плохая идея?

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

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

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

Ребята из HFT, Database, Automotive и Embedded-систем наверняка могут рассказать немало интересных историй про оптимизацию new/delete. Давайте я расскажу немного про разные аллокаторы в играх?

Привет! Сегодня мы выложили в опенсорс Perforator — систему непрерывного профилирования (continuous profiling), которую используем внутри Яндекса для анализа производительности большинства сервисов.

В Github-репозитории доступен исходный код системы и инфраструктура для развёртывания своей инсталляции Perforator на кластере Kubernetes. Кроме того, Perforator можно использовать на своём компьютере как более простую замену perf record: профили получаются точнее, а оверхед меньше. Исходный код доступен под лицензией MIT (и GPL для eBPF-программ) и запускается под x86-64 Linux.

При помощи Perforator и прошлых подходов к задаче профилирования мы регулярно оптимизируем самые крупные сервисы в Яндексе, например Баннерную крутилку или Поиск, на десятки процентов. Кроме того, Perforator реализует недостающий в опенсорсе компонент профилирования для простой автоматической оптимизации программ с использованием profile-guided optimization. Наши тесты показывают, что использование PGO даёт ускорение около 10% в разных сценариях.

Под катом поговорим про профилирование под Linux, опишем вызовы и сложности, возникающие при профилировании, изучим, как устроен Perforator внутри, и обсудим, как можно использовать полученную систему.

1. SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite.
   
   Её поддерживают три человека. Они не допускают внешних контрибьюторов.
   

Вы наверняка имеете медиа файлы закодированные не самым эффективным кодеком (H.264, JPEG, MP3). И вы можете сократить их размер вплоть до 75% перекодировав медиа современными альтернативами (H.265, AVIF, OPUS).

Использовать для этого можно консольные утилиты ffmpeg и magick.

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

Данные - это важный компонент системы. Приложение может хранить их где угодно, но в результате все сводится к файлам. Файлы - это хорошая абстракция, но она протекает: если не знать того, как работают ОС или гарантии файловой системы, то легко выстрелить себе в ногу.

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

Кто участвует в процессе записи

Ошибки, которые могут произойти

Что от нас зависит, а что нет

И самое главное - как это этого защититься

Материалы лекции про конфигурационные файлы — все основные аспекты написания и использования конфигов для самых маленьких, примеры кода на python.

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

Всем здравствуйте! Полагаю, что софт для разработки антенн и электродинамической симуляции - HFSS Design не нуждается в подробном представлении. С момента своего появления за почти тридцатилетнюю историю, летом 2021 года появилась его бесплатная студенческая версия. Она имеет ограничение на размер рассчитываемых моделей, однако для болшей части учебных задач он подходит. Здесь я бы хотел рассказать где скачать этот софт и как создать что-то типа "Hello World'a" с созданием тестовой модели в пару кликов.

USM, НеЖелательные Явления, ненужная документация, допущения и ограничения, тупиковый путь в тимлиды, красные флаги при трудоустройстве и всё интересное, что писали на этой неделе про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

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

Итак, начнем с моделей, основанных на данных. Такого рода модели встречаются почти на каждом шагу. Любая задача машинного обучения, будь то регрессия (например, предсказание цен на товары), классификация (определение маркера болезни по данным об анализах пациента), рекомендация (определение более подходящего видео в вашей ленте), сегментация (определение объектов на фото или видео) и т. д. Задач машинного обучения достаточно много, но все они требуют одного - данных.

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

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