В интервью Адарш Миттал, старший инженер по разработке специализированных интегральных схем (ASIC), объясняет, почему многие оптимизации производительности памяти на практике не работают и почему будущим архитектурам выгоден другой подход к проектированию.
По мере роста вычислительных возможностей поведение памяти все чаще определяет производительность. Нагрузки, связанные с искусственным интеллектом (ИИ), и гетерогенные архитектуры обеспечивают масштабирование вычислений, значительно опережающее улучшение характеристик памяти. Многоядерные центральные процессоры (ЦП), графические процессоры (ГПУ) и специализированные ускорители стали стандартом, но они не смогли преодолеть «стену памяти». Более быстрые ядра не приводят к ускорению работы систем. В некоторых случаях они усиливают неэффективность работы с памятью и обнажают узкие места, которые не выявляются при тестировании.
Ключевой вопрос не в том, стала ли память ограничением. Она стала. Реальная задача – понять конкретную системную динамику и то, почему именно она определяет, улучшит или ухудшит производительность дополнительная вычислительная мощность.
Адарш Миттал – старший инженер по разработке ASIC в глобальной технологической компании, где он проектирует interconnect-сети для ЦП, системы когерентности для мультипроцессоров и иерархии кэш-памяти. Его работа находится на стыке, где проблемы «стены памяти» проявляются в реальном «железе», что дает ему непосредственный опыт наблюдения за тем, как эти узкие места ведут себя под реальной нагрузкой. Он также является автором рецензируемых исследований и патентных заявок в области архитектуры систем памяти.
Почему добавление большего количества вычислительных ядер замедляет работу систем вместо того, чтобы ускорять их?
Миттал: Большее количество вычислительных ядер усиливает конкуренцию за одни и те же ресурсы. Когда одно ядро кэширует строку данных, а другое ядро нуждается в ней, второе ядро должно получить ее из соседнего. Эта конкуренция возникает во всех ЦП, ГПУ и ускорителях, вызывая остановку конвейеров выполнения, несмотря на возможности многопоточности и многопроцессорной обработки.
Обеспечение того, чтобы все ядра видели одну и ту же версию данных (известное как проблема когерентности), масштабируется экспоненциально, а не линейно. Критически важно отслеживать и синхронизировать каждую запись, обновление и изменение в расширяющейся сети вычислительных блоков. В результате трафик, связанный с поддержанием когерентности, становится огромным.
Затем есть проблема ограничения (throttling). Требования к качеству обслуживания означают, что каждый вычислительный блок имеет гарантированные уровни производительности. Рассмотрим нагрузку, которая использует только четыре ядра из 40 доступных. Система ограничивает пропускную способность памяти для всех четырех ядер...
Какие аспекты поведения памяти чаще всего неправильно понимаются разработчиками при проектировании систем?
Миттал: Первое заблуждение заключается в том, что пропускная способность может решить проблемы с задержкой. Добавление большей памяти не решает эту фундаментальную проблему. Задержка остается ограничением, которое обеспечивает согласованность системы и корректность операций чтения и записи данных. Пропускная способность и задержка – это разные проблемы, требующие разных решений.
Второе – это вера в то, что средняя задержка отражает реальный пользовательский опыт. Разработчики масштабируют системы в течение длительных периодов времени и рассчитывают среднее значение, но не каждый пользователь запускает приложение достаточно долго, чтобы эти средние значения имели к нему отношение. Некоторые взаимодействия коротки, другие – длительны, и усреднение маскирует реальные колебания производительности, с которыми сталкиваются пользователи.
Разработчики также упускают из виду конкуренцию, создаваемую механизмами безопасности, когерентности и отказоустойчивости. Механизмы безопасности предотвращают повреждение системы, в то время как репликация данных обеспечивает корректность в таких приложениях, как беспилотные автомобили. Но эти механизмы защиты создают конкуренцию, которую текущие проектные допущения не учитывают. Системы моделируются так, как будто этих механизмов не существует, что приводит к архитектурам, которые выглядят работоспособными изолированно, но испытывают трудности в реальных условиях, где безопасность и отказоустойчивость не являются опциональными.
И наконец, имеет место переоценка стабильности кэш-попаданий. Реальные нагрузки ведут себя не так, как тестовые сценарии (бенчмарки). Ими управляют температурные ограничения, поведение аппаратного и программного обеспечения, требования пользователей, доступность пропускной способности в системах с несколькими ЦП и ГПУ, а также в целой инфраструктуре центров обработки данных. Допущения, сделанные при проектировании, не отражают того, как эти системы работают в реальной эксплуатации.
Почему спецификации «сырой» пропускной способности не позволяют предсказать реальную производительность?
Миттал: Нагрузки не генерируют идеально потоковые шаблоны данных, которые предполагают бенчмарки. Реальные нагрузки эволюционируют. Всегда появляются новые приложения, тесты и системы. Шаблоны, предполагаемые при проектировании аппаратного обеспечения, не соответствуют тем, которые работают в реальной эксплуатации.
Задержка доминирует в критических путях выполнения, но не задержка отдельных компонентов, измеренная изолированно. Системная задержка в архитектурах с несколькими ЦП, ГПУ и ускорителями определяет фактическую производительность. Нельзя строить отдельные части аппаратного обеспечения независимо, а затем ожидать, что они будут эффективно работать вместе. Необходима координация между ЦП, ГПУ и системами памяти, управляющими этими путями выполнения.
Конкурирующие агенты и сервисы также разделяют пропускную способность. Пиковые спецификации измеряют аппаратное обеспечение изолированно, но производственные системы работают в условиях ограничений, которые эти измерения игнорируют. Доступная мощность, температурные ограничения, требования к частоте, характеристики нагрузки и поведение программного обеспечения – все это ограничивает доступные ресурсы. В многопользовательских средах проблема разделяемой пропускной способности усугубляется. Даже если отдельные пользователи ведут себя корректно при раздельном тестировании, их совместная активность создает шаблоны доступа и профили конкуренции, которые не выявляет ни одно изолированное тестирование.
Как предположения о кэшировании и предвыборке данных (prefetching) разрушаются в многопользовательских, гетерогенных системах?
Миттал: Механизмы предвыборки конкурируют друг с другом и засоряют разделяемые строки кэша. В одноядерных сценариях с фиксированными шаблонами механизмы предвыборки могут изучать шаблоны доступа, используя предсказание шага (stride prediction) или многоуровневую предвыборку. Но в системах с множеством агентов механизмы предвыборки борются друг с другом. Каждый предполагает, что ему нужны определенные строки кэша, и пытается их загрузить, но эти строки являются общими. Вместо повышения производительности результатом становится загрязнение кэша и конкуренция.
Затем эффективная емкость кэша потребляется метаданными, служебными расходами на поддержание когерентности и фоновыми сервисами еще до того, как к нему обратятся приложения. Только подмножество номинальной емкости кэша доступно для полезных данных. Остальное поддерживает когерентность, обрабатывает трафик безопасности и отказоустойчивости и поддерживает инфраструктуру, обеспечивающую согласованность системы. Решением может быть перенаправление предвыборки в память, а не в кэш, смещая то место в иерархии, где происходит эта спекулятивная загрузка данных.
Какие метрики лучше всего отражают эффективность использования памяти при реальных нагрузках?
Миттал: Я бы сказал, что часто используемые метрики скрывают реальные системные издержки. Энергопотребление на один полезный переданный байт и поведение «хвостовой» задержки (tail latency) являются более точными индикаторами эффективности производительности. Если ядро запрашивает один байт, но система памяти доставляет 32 байта, включая служебную информацию, затраты энергии отражают полную передачу 32 байт, хотя полезен был только один байт. Идея в том, чтобы разделить общую энергию на количество полезных байтов, чтобы была видна истинная стоимость доставки полезных данных.
«Хвостовая» задержка лучше отражает пользовательский опыт, чем средние значения. Пиковые задержки и выходящие за рамки случаи важнее сглаженных средних значений, которые скрывают то, с чем сталкиваются отдельные пользователи. Для стабильности производительности измеряйте показатели в течение разного времени выполнения (короткого, среднего и длительного), чтобы увидеть, как система ведет себя в различных случаях использования, а не сводите все к одному среднему числу.
Кроме того, отслеживание простоев (stalls) памяти на одну выполненную инструкцию показывает, сколько циклов тратится впустую в ожидании операций с памятью. В настоящее время не существует стандартного показателя того, сколько времени выполнения теряется из-за узких мест памяти. Такая видимость изменила бы то, как системы оцениваются и оптимизируются.
Какие конкретные шаги могут предпринять инженеры-разработчики, чтобы сбалансировать память и вычисления в своих архитектурах?
Миттал: Один из шагов – профилировать реальные нагрузки на ранних этапах процесса проектирования, а не полагаться на идеализированные потоковые бенчмарки. Инженеры могут проектировать с учетом толерантности к задержке, а не фокусироваться исключительно на максимизации пропускной способности. Также важно ограничивать ненужный трафик когерентности с помощью архитектурных решений. Это может означать иерархические системы когерентности, в которых группы ядер общаются с локальными мониторами когерентности, которые координируют действия друг с другом, вместо того чтобы все ядра общались напрямую с единым центральным узлом. Это также может включать компромиссы между мелкозернистым и крупнозернистым отслеживанием когерентности, принимая некоторый дополнительный трафик для определенных ядер в обмен на более простое управление.
Кроме того, проверяйте проекты в реальных условиях, включая требования к качеству обслуживания, бюджеты энергопотребления и целевые показатели производительности для множества конкурирующих агентов. Проводите стресс-тестирование с учетом этих фиксированных ограничений.
И наконец, обоснуйте важность этого перед руководством, привязав узкие места памяти напрямую к пользовательскому опыту. Покажите стоимость неиспользуемых вычислительных мощностей, несмотря на дорогостоящие аппаратные инвестиции. Представляйте память как мультипликатор производительности, а не просто как статью затрат. Поскольку индустрия осознает эти ограничения, новые архитектурные подходы, такие как расширение памяти на основе CXL и 3D-стэкинг DRAM, направлены на обеспечение более гибких и масштабируемых путей доступа к памяти.
Пересмотр стимулов в проектировании
Организации измеряют то, что они ценят, и большинство фокусируется на неправильных показателях для оценки производительности вычислений. Когда решения о закупках оптимизируются по количеству ядер и пиковым FLOPS (операциям с плавающей запятой в секунду), а бенчмарки поощряют потоковые шаблоны, не похожие на реальные нагрузки, стимулы остаются несогласованными. Экономическая реальность сурова: простаивающие ядра в ожидании памяти представляют собой sunk-затраты на «железо», генерирующее тепло вместо результатов; бюджеты энергопотребления тратятся впустую на вычисления, которые не могут быть полностью использованы; а пользовательский опыт ухудшается, несмотря на дорогостоящую инфраструктуру.
Чтобы разорвать этот круг, необходимы новые системы измерений и другие практики проектирования. Переосмысливая поведение памяти как системное ограничение, а не как проблему на уровне компонентов, Миттал показывает, почему многие оптимизации производительности терпят неудачу на практике и почему будущие архитектуры выиграют от другого подхода к проектированию. Инженеры, которые примут эти метрики и архитектурные подходы, смогут связать техническую реальность с бизнес-результатами и показать, что проектирование с учетом особенностей памяти – это не компромисс, а основа для создания систем, которые обеспечивают производительность, обещанную их аппаратными спецификациями. Это дает больше, чем просто решение проблемы узкого места. Это конкурентное преимущество.
Ссылка на первоисточник: https://www.designnews.com/electronics/the-hidden-truth-about-memory-why-the-best-hardware-under-delivers
Вас также могут заинтересовать: