В последние годы стало появляться большое количество сообщений о всякого рода уязвимостях в процессорах компании Intel. Самыми известными из них являются Spectre и Meltdown, основанные на ошибках в реализации спекулятивного исполнения команд. В июне 2020 года появилось сообщение о новой уязвимости, носящей название Crosstalk.

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

Спекулятивные вычисления

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

Конвейер

Конвейер процессора представляет собой технологию, позволяющую распараллелить инструкции процессора на более простые, что позволяет производить вычисления с большей скоростью. На рисунке показано, как происходит исполнение инструкций в четырех стадийном конвейере. Для примера, на третьем такте происходит исполнение зеленой инструкции, декодирование фиолетовой и подтягивание новой синей инструкции. Без конвейера такой набор из четырех инструкций занял бы 16 тактов процессорного времени. В нашем случае, команды исполнились за 8 тактов.

Как происходит межъядерное взаимодействие?

Существует набор инструкций процессора Интел семейства x86 с нетривиальным поведением. Такие инструкции состоят из нескольких операций, называемых микрокодом. Исследователи из Vrije Universiteit Amsterdam провели ряд экспериментов, в которых изучалась работа инструкций процессора с разными наборами аргументов. Оказывается, что в ряде случаев такой микрокод осуществляет операции чтения-записи вне ядра через внутренние шины процессора в регистры MDS (Model-Specific-Registers) с помощью операций RDMSR и WRMSR. Эти операции являются привилегированными и могут исполняться только операционной системой. Для userspace примерами таких инструкций являются CPUID, RDRAND и RDSEED.

Промежуточный буфер сохраняет результаты ранее выполненных инструкций, такие как сгенерированные DRNG случайные числа, хэши состояния bootguard и другие ценные данные. Чтение из промежуточного буфера с помощью Crosstalk позволяет получать доступ к данным, к которым обращался пользователь, и которые остались в этом буфере после выполнения таких запросов, как например RDRAND и RDSEED.

RDRAND и RDSEED

Инструкция RDRAND возвращает случайные числа, полученные от digital random number generator (DRNG), и может быть вызвана из пользовательского пространства. DRNG выводит случайные начальные состояния и передает их генератору случайных битов, который заполняет глобальную очередь случайных чисел. Инструкция RDSEED обеспечивает доступ к более качественному источнику энтропии, т.к. предназначена для программных RNG.

Внутренние буферы процессора

Забегая немного назад в списке уязвимостей, стоит отметить RIDL, которая позволяет создавать утечки информации из разных источников, таких как кэши и буферы процессора: Line Fill Buffer, Load Ports, Store Buffer.

Line Fill Buffer (LFB) используется для отслеживания кэш миссов L1 Cache (невыполненных запросов памяти) и передачи кэш-линий за пределами L1 Cache. Например, при кэш миссе, вместо блокировки кэша, операция помещается в LFB и обрабатывается асинхронно. Это позволяет кэшу обслуживать другие запросы. Промежуточный буфер получает данные от ядра из LFB.

Store Buffer отслеживает запросы на запись данных.

Load Ports используются конвейером процессора при загрузке данных из памяти или I/O операций. Когда выполняется микрокод загрузки, данные сначала сохраняются в Load Ports перед передачей в регистры.

Детектирование Crosstalk

Детектирование Crosstalk состоит из двух стадий. Сначала проверяются различные инструкции, делающие запросы вне ядра с разными операндами. Затем анализируются данные, полученные от такого рода запросов, чтобы понять, как устроено взаимодействие между LFB, расположенном на ядре, и внешним разделяемым буфером. Разные инструкции записывают данные в разделяемый буфер с разным размером отступа. На другом ядре происходит чтение из этого буфера и наблюдение за изменениями, вносимыми первым ядром. Таким образом, злоумышленник может сгенерировать набор инструкций, позволяющий читать почти все инструкции, поступающие в промежуточный буфер от другого ядра.

FLUSH + RELOAD

inline int probe(char *adrs) {  volatile unsigned long time;  asm __volatile__ (    "  mfence             \n"    "  lfence             \n"    "  rdtsc              \n"    "  lfence             \n"    "  movl %%eax, %%esi  \n"    "  movl (%1), %%eax   \n"    "  lfence             \n"    "  rdtsc              \n"    "  subl %%esi, %%eax  \n"    "  clflush 0(%1)      \n"    : "=a" (time)    : "c" (adrs)    :  "%esi", "%edx");  return time;}

В качестве примера рассмотрим RIDL атаку с использованием LFB, выполняемую в четыре этапа. Сначала злоумышленник создает массив FLUSH + RELOAD, содержащий одно значение для каждой строки кэша (обычно байт) и выполняет операцию FLUSH, чтобы гарантировать, что ни одна из этих строк не находится в кэше. Затем злоумышленник предлагает программе-жертве прочитать или записать секретные данные или обеспечить удаление таких данных из кэша. В любом случае, процессор перемещает данные в LFB. Затем злоумышленник выполняет загрузку данных (операцию load), вызывающую исключение или pagefault. При этом, такая операция считается успешной, данные сохраняются в LFB. Затем спекулятивно исполняемый код злоумышленника использует данные, соответствующие индексу в массиве FLUSH + RELOAD. Соответствующая строка кэша будет загружена в кэш конвейером, когда он выполнит спекулятивный код. Наконец, загрузив каждый элемент массива и определив время загрузки, злоумышленник может определить, какой из них был в кеше. Индекс в кэше - это секретные данные, полученный из LFB.

CPUID

pid_t pid = fork();if (pid == 0) {    while (1)        asm volatile(            "mov %0, %%eax\n"            "cpuid\n"            ::"r"(CPUID_LEAF):"eax","ebx","ecx","edx");}for(size_t offset = BEGIN_OFFSET; offset < BEGIN_OFFSET + 4; ++offset) {    // ...    for(size_t i(0); i < ITERS; ++i) {        flush(reloadbuffer);        tsx_leak_read_normal(leak + offset, reloadbuffer);        reload(reloadbuffer, results);    }}

На представленном листинге показано, как осуществляется запрос на примере CPUID. Эта команда позволяет получить информацию о процессоре. Такого рода запросы называются MDS. К их числу относится упомянутый ранее RIDL. Запросы проводятся с разным смещением в разделяемом буфере. Смещение вызывает ошибку при чтении страницы, так как читаемый вектор захватывает границы страницы. Затем при помощи FLUSH + RELOAD можно получить данные, прочитанные во время выполнения инструкции. Таким образом, CPUID вызывает 4 запроса вне ядра, что говорит об успешной демонстрации CROSSTALK. В следующей таблице представлены результаты различных операций, реализуемых CROSSTALK

Замедление работы процессора

Одним из примеров атаки может служить замедление работы при запросах определенного рода ресурсов. Рассмотрим инструкцию RDSEED. Объем доступной энтропии всегда ограничен, причем RDSEED возвращает 0, если нет доступной энтропии. Неуспешный вызов RDSEED не перезаписывает содержимое промежуточного буфера. Таким образом, злоумышленник может потреблять доступную энтропию, самостоятельно выполняя запросы RDRAND и RDSEED, в то время как ядро-жертва не сможет получить достаточный объем энтропии для успешного завершения вызова RDSEED. С помощью такого рода запросов можно читать данные, записанные пользователем в разделяемый буфер. Когда запрос жертвы все же вернет положительный результат, данные в разделяемом буфере перезапишутся. Но в то же время, злоумышленник может уже прочитать данные, до завершения работы вызовов FLUSH + RELOAD.

Виртуальные машины

Если злоумышленники имеют возможность писать код только внутри виртуальной машины, то операции, позволяющие получать доступ к промежуточному буферу, ограничены. Например, обычно виртуальные машины запрещают пользователю выполнять вызов CPUID, чтобы не позволять пользователю получать информацию о возможностях виртуальной машины. Тем не менее, инструкции RDRAND и RDSEED могут быть исполнены из пространства пользователя, что создает уязвимость и для виртуальных машин. Примером может стать составление запросов гипервизору, а затем чтение из промежуточного буфера в LFB. Даже если процессор оснащен защитой от MDS атак, злоумышленник может получать содержимое разделяемого буфера из соседнего потока (hyperthread), раскрывая данные жертвы, работающей на другом ядре.

Устранение уязвимости

Компания Интел предоставила решение проблемы, которое заключается в блокировании шины данных перед обновлением промежуточного буфера и снятии блокировки только после завершения очистки содержимого буфера. Таким образом, одно из ядер не сможет читать инструкции, исполняемы на другом ядре. Такого рода блокировки, в свою очередь, создают большие задержки при работе с промежуточным буфером. Чтобы увеличить производительность операций записи в буфер, было предложено ограничиться блокировками буфера только для тех операций, которые представляют угрозу для безопасности данных, такие как рассмотренные ранее RDRAND, RDSEED и EGETKEY. В то же время, существует ряд команд, способных на чтение данных вне ядра, не регулируемых локами.

Выводы

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

У центральных и графических процессоров разная архитектура и разные сценарии использования. ЦП это мозг большинства наших электронных устройств. Они хорошо справляются с множеством различных задач. Это процессоры очень общего назначения, координирующие широкий спектр задач, которые выполняет компьютер. С другой стороны, графические процессоры гораздо более специализированные вычислительные системы. Они предназначены для эффективной обработки 3D-изображений, но визуализация графики это очень большая вычислительная нагрузка на матричную арифметику. Типы вычислений, в которых графическим процессорам нет равных, называются параллельными вычислениями, то есть это задачи, которые можно разделить на меньшие, независимые вычисления и выполнять одновременно. И этому потенциалу находится нетипичное применение.

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

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

Если посмотреть на то, как количество ядер в графическом процессоре меняется со временем, видно, что последние несколько лет оно растёт экспоненциально. И в то время как большинство центральных процессоров имеет несколько десятков ядер, графические процессоры насчитывают тысячи ядер. В новейших высокопроизводительных графических процессорах компании Nvidia более 10 000 ядер.

Этот беспрецедентный рост привёл к тому, что разработчики начали изучать возможности применения графических процессоров не только для графической обработки, но и для того, что теперь известно как неспециализированные вычисления на графических процессорах (GPGPU).

Чтобы помочь разработчикам использовать все возможности графических процессоров и позволить центральным и графическим процессорам обрабатывать данные в двух направлениях, компания Nvidia создала программную платформу CUDA, которая облегчает разработчикам создание приложений с использованием API.

Они всегда сотрудничают с разработчиками в целях реструктуризации алгоритмов, используемых в их приложениях, чтобы использовать аппаратное обеспечение Nvidia с максимальной отдачей. В результате достигнута очень хорошая интеграция с широко используемыми приложениями, такими как Adobe Photoshop CC, Adobe Premiere CC и Autodesk Maya.

Платформу CUDA можно скачать бесплатно, но для работы с ней требуется графический процессор Nvidia. Также существует альтернатива с открытым исходным кодом OpenCL, которая служит основной платформой для обработки графики на графических процессорах AMD. Компания Nvidia поддерживает OpenCL, но, так как платформа CUDA разрабатывается для работы с оборудованием Nvidia, она показывает более высокую производительность при работе на графических процессорах Nvidia.

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

Рассмотрим сценарий, в котором требуется вручную сложить две матрицы 20x20. Вы зовёте ещё 19 друзей и говорите им, что каждый из них отвечает за вычисление одной строки, а затем вы снова объединяете результаты в одну матрицу.

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

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

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

Для простоты предположим, что:

• Им известно, что приложение ограничивает пароли пользователей 10 символами.

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

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

Они должны будут повторить это для всех комбинаций символов, включая все 10 допустимых символов.

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

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

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

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

FPGA и ASIC

Увеличение скорости хэширования в 100 раз с помощью графических процессоров плохая новость для людей, которые пытаются надёжно хранить пароли.

Однако не все алгоритмы хэширования уязвимы для атак с ускорением на основе графических процессоров.

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

bcrypt один из таких алгоритмов.

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

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

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

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

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

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

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

Вот почему вы, вероятно, слышали о ASIC-микросхемах для майнинга биткойнов. Эти микросхемы могут делать только одно вычислять двойные хэши SHA256, а в настоящее время майнинг биткоинов достаточно прибылен, чтобы оправдать их производство.

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

Можно ли ASIC-микросхемы вместо майнинга биткоинов использовать взлома паролей?

Как я уже сказал, ASIC-микросхемы разрабатываются с нуля с одной целью, и в случае установок для майнинга биткойнов эта задача заключается в вычислении двойных хэшей SHA256.

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

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

Злоумышленникам потребовалось бы настроить по одной ASIC-установке для каждой функции хэширования и настраиваемой функции, такой как bcrypt, для каждой вероятной комбинации параметров. Мало того, что это трудно сделать с точки зрения разработки, но атака также должна иметь смысл с финансовой точки зрения.

FPGA-установки для взлома Bcrypt-паролей

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

Давайте посмотрим, как FPGA смогут преодолеть ограничения графических процессоров при взломе bcrypt.

С общими функциями хэширования, такими как SHA1 и MD5, вероятно, придётся попрощаться из-за графических процессоров, так как эти алгоритмы не создают узкие места в памяти, поскольку они не были предназначены для хранения паролей.

Для вычисления bcrypt-хэша процессору придётся постоянно обращаться к инструкциям, хранящимся в памяти. У каждого ядра есть быстрый, но небольшой объём памяти (кэш L1). Если в памяти L1 недостаточно места для вычисления хэша, данные должны храниться в более медленной основной оперативной памяти графического процессора, общей для всех ядер.

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

Это не проблема для FPGA-микросхем, потому что у них более чем достаточно памяти L1 для работы с bcrypt-хэшами.

Персонал службы уведомлений о нарушении паролей Scattered Secrets хотел проверить это, поэтому они построили кластер из FPGA-микросхем, способный взламывать bcrypt примерно в 3540 раз быстрее, чем современные высокопроизводительные графические процессоры, используя только около 5% мощности.

Используя RTX 2080Ti в качестве бенчмарка, они получили 54 тысячи bcrypt-хэшей в секунду на своей тестовой установке, в то время как установка, которую они построили с 18 четырёхъядерными FPGA-платами Spartan-6 LX150, выдавала 2,1 миллиона bcrypt-хэшей в секунду.

Имейте в виду, что это не самые современные FPGA-микросхемы: они были введены ещё в 2011 году. Эти платы были популярным инструментом, потому что они поддерживали Jack The Ripper, популярное программное обеспечение для взлома паролей. Поскольку приложения для взлома паролей начинают поддерживать новые микросхемы, скорость таких атак будет только увеличиваться.

Заглядывая в будущее

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

Всегда будут существовать финансовые стимулы разработки новых технологий для решения сложных проблем, с которыми мы сталкиваемся как общество. Число ядер в одном графическом процессоре выросло с 1 ядра в 1995 году до 24 ядер в 2006 году, затем подскочило до 128 ядер в 2009 году и продолжило расти экспоненциально до 10 000 и выше к 2021 году.

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

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

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

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Меня зовут Алексей Доильницын, я архитектор в DINS. Наша компания участвует в разработке UCaaS-платформы (Unified Communication as a Service) RingCentral, которой пользуется более 400 тыс. компаний по всему миру.

Я работаю в команде, которая отвечает за разработку сервиса видеоконференций RingCentral Video или RCV. Видеоконференции с большим количеством участников в галерее часто бывают неподъемными для устаревших лэптопов. Мы решили эту проблему с помощью теории систем автоматического управления (САУ).

RCV стал особенно актуальным в начале 2020 года в связи с массовым переходом на работу из дома. Тогда же мы столкнулись с интересной проблемой: некоторые пользователи жаловались на постоянный гул вентиляторов, на быстрое расходование батареи и торможение устройства. Оказалось, что конференции с большим количеством участников в галерее бывают неподъемными для устаревших лэптопов, которые часто встречаются дома. И мы стали эту проблему решать с помощью теории систем автоматического управления.

Задача и подход к решению

RingCentral Video выпускает нативного клиента для основных платформ Mac и Windows. Клиент построен на Electron (библиотека для разработки настольных приложений с использованием HTML), что существенно экономит ресурсы разработки, так как по сути позволяет разработать только одно веб-приложение на JavaScript, которое актуально сразу для трех основных платформ веб, Mac и Windows.

По нашему опыту, двухъядерные процессоры Intel старше 5 лет уже зачастую не справляются с типичными корпоративными конференциями с 8-16 участниками.

4-х ядерные современные Core i5 это, наверное, минимальная конфигурация для подобных задач. У более слабых компьютеров возникают проблемы вроде высокого расхода батареи и подвисания компьютера.

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

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

Построение системы управления

Система управления функционирует в JavaScript коде клиента видеоконференции.

Объектом управления в нашем случае являются видеопотоки, рисуемые на экране пользователя. На загрузку ЦПУ в первую очередь влияют количество потоков и разрешение видео (высота х ширина).

9 видеопотоков в разрешении 640x360:

В качестве обратной связи выбираем системную загрузку ЦПУ. Поскольку в браузере нет соответствующего API, измеряем загрузку ЦПУ в нативном коде (в плагине Electron) и периодически шлем событие с текущей загрузкой ЦПУ в JavaScript код.

Выбираем целевой коридор загрузки ЦПУ, например, 40-50%.

В качестве ошибки используем разницу между текущей загрузкой ЦПУ и ближайшей границей коридора. Например, текущая загрузка 80%, значит ошибка 80-50=30 в абсолютных величинах, или по отношению в коридору: 30/50=0.6 (60%).

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

• Если загрузка ЦПУ выше целевого коридора, то сначала уменьшаем разрешение потоков, потом начинаем выключать потоки.

• Если загрузка ЦПУ ниже целевого коридора, то сначала включаем выключенные потоки, потом увеличиваем их разрешение.

• Если загрузка внутри коридора, то ничего не делаем во избежание колебаний.

При этом количество потоков, на которые будет оказано воздействие, рассчитывается из величины ошибки. Например, клиент отрисовывает 16 видеопотоков в среднем разрешении 640х360. Если загрузка ЦПУ 80% и соответственно ошибка равна 0.6, то за один шаг мы уменьшим разрешение для 16*0.6=10 потоков. Это делается для того, чтобы система быстрее реагировала на большие возмущения. При этом мы учитываем, что отрисовка одного потока занимает от долей до единиц процентов полной загрузки системы.

Проблемы, возникшие в результате эксплуатации

Внутри коридора

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

Решение: все-таки включать видео потоки внутри коридора, но медленно, например, по одному потоку на каждый третий вызов.

Мощный компьютер

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

Решение: измерять, сколько ЦПУ потребляет наш процесс в процентах от общего потребления системы. Если доля нашего процесса менее 50%, то отключать систему управления.

Финальный тест

В финальном тесте на старом лаптопе с процессором i5-3210M (4 cores @ 3 GHz) участвовали 8 участников (ботов) в разрешении 320х180. Стартовая загрузка ЦПУ около 80%.

Через 30 секунд отключается четыре участника, загрузка опускается до 65%.

Ниже опускаться уже некуда, так как минимальное количество участников на экране 4.

В итоге система управления успешно прошла тесты и сдана в промышленную эксплуатацию.

Если у вас появились какие-то вопросы или хотелось бы узнать что-то еще об RCV пишите в комментариях.

17 ноябряAppleофициально представила устройства на базе своего нового ARM-процессораAppleM1. Естественно, это событие не могло быть не замечено со стороны компанииMicrosoft, которая с 2014 года начала активную экспансию .NET на новые платформы. Давайте посмотрим, что нас ждет в связи с этим в ближайшее время.

Начнем пожалуй с инструментов, а затем перейдем к самой платформе .NET, но если вам не терпится узнать, получат ли новые маки поддержку .NET, то вот вам небольшой спойлер:

Да, на новых маках будет .NET

Visual Studio Code

Команда разработчиков Visual Studio Code уже объявила о том, что работает над поддержкой новых процессоров. На странице загрузок Insider Preview для macOS уже появились опция для загрузки экспериментальной сборки с поддержкой ARM. Следить за работой команды можно на официальном аккаунте в GitHub.

Visual Studio for Mac

Если команда VS Code уже подготовила тестовые сборки с поддержкой Apple M1, то их коллеги из команды Visual Studio for Mac оказались не так расторопны:

Впрочем Visual Studio for Mac гораздо более крупный и сложный проект, поэтому портирование его на новый процессор может занять несколько больше времени. Сейчас эта версия IDE может работать при поддержке Rosetta 2.

На данный момент у владельцев новых ноутбуков Apple наблюдаются некоторые проблемы при отладке проектов на Xamarin.Forms для iOS. Соответствующий баг уже заведен в репозитории проекта Xamarin.iOS & Xamarin.Mac.

Rider

В JetBrains уже объявили, что они работают над переносом JetBrains Runtime (и всех продуктов, работающих на JVM, в том числе и Rider) на Apple Silicon. На данный момент IDE от JetBrains работают на чипах Apple Silicon через Rosetta 2. Правда не все функции работают в этом режиме стабильно. Так, например, многие жалуются на то, что отладка в Rider сейчас не работает.

Docker

Docker стал практически must have инструментом для современного разработчика. У Майкрософт есть обширный набор образов для .NET, но к сожалению, воспользоваться вы ими на ноутбуке с новым процессором от Apple пока не сможете.

Будем надеяться, что в ближайшее время поддержка M1 будет реализована в Docker.

.NET

А теперь перейдем к самому главному получит ли новый чип поддержку .NET?

Те, кто подсмотрели спойлер в начале статьи уже знают ответ на этот вопрос. Команда разработки .NET активно работает над поддержкой Apple M1. Для этого даже был создан отдельный проект в трекинге платформы. Стоит отметить тот факт, что текущая версия платформы (а именно, недавно ушедший в релиз .NET 5) будет работать поверх Rosetta. А вот в .NET 6 уже будет нативная поддержка нового чипа. Согласно планам Microsoft, произойдет это не раньше, чем через год:

Из того, что уже выполнено, я бы отдельно отметил такие задачи:

• Add initial CoreCLR compilation support for Apple Silicon

• Add osx-arm64 to packges/CI

• Enable building SOS on Apple Silicon

• Enable osx-arm64 cross compilation

• Support Runtime native build on Apple arm64

• Enable building .NET Core osx-arm64 in CI

• Enable Apple Silicon SDK builds

Также запланирована поддержка нового процессора в ASP.NET Core.

Но несмотря на то, что официальной поддержки новых процессоров придется ждать почти год, уже доступна к загрузке альфа-версия .NET 6.0. На момент написания статьи, это версия 6.0.0-alpha.1.0562.6.

Mono

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

Самое большое изменение, которое было сделано для поддержки процессора M1 связанно с тем, как работает JIT, а именно, с изменение состояния потоков. Это было реализовано с помощью новых макросов в mono/mini.h. Они были встроены в систему из соображений производительности.

Rosetta 2

В этой публикации не один раз упоминалась технология Rosetta 2. Для тех, кто не знает, что это, приведем пояснение, которое размещено на странице портала Apple Developer:

Rosetta - это процесс трансляции, который позволяет пользователям запускать приложения, содержащие инструкции x86_64, на микросхеме Apple. Rosetta призвана упростить переход на микросхему Apple, давая разработчикам время на создание универсального двоичного кода приложений. Если исполняемый файл содержит только инструкции Intel, macOS автоматически запускает Rosetta и начинает процесс трансляции. По окончании трансляции система запускает подготовленный исполняемый файл вместо оригинала. Однако процесс перевода требует времени, поэтому транслированные приложения иногда запускаются или работают медленнее.

Итоги

Новый процессор (а соотвественно устройства, которые будут на основаны на нем) без сомнений получит нативную поддержку в .NET, впрочем эта задача не является приоритетной в текущем роадмапе, поэтому ждать ее придется не раньше, чем в релиз уйдет шестая версия платформы. До того момента можно будет работать c .NET, используя возможности Rosetta 2. Что касается инструментария для разработчиков, то я могу предположить, что в ближайшие пол года основные проблемы будут решены (возможно даже с участием Apple) и уже к апрелю можно будет потихоньку присматриваться к компьютерам на базе Apple M1 в качестве рабочего инструмента.

Современный мир ПО содержит настолько много слоёв, что оптимизации могут быть в самых неожиданных местах. Знакомьтесь - год 2000, проект HP Dynamo. Это эмулятор процессора PA-8000, работающий на этом же процессоре PA-8000, но с технологией JIT. И реальные программы, запускающиеся в эмуляторе - в итоге работают быстрее, чем на голом процессоре.

td;dr - всё сказано в заголовке

Программистам из HP Labs стало интересно, а что будет, если написать оптимизирующий JIT компилятор под ту же платформу, на которой он работает. Работа заняла несколько лет. Под эмулятором можно было запускать немодифицированные родные бинари. И результаты оказались несколько неожиданными.

В эмуляторе они искали "hot paths" и оптимизировали ход исполнения кода. Таким образом уменьшались расходы на джампы, вызов функций, динамических библиотек, оптимизации работы с кешем процессора. Результаты повышения производительности доходили до +22%, в среднем по тестам получалось +9%.

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

Если кому интересны подробности:

1. http://cseweb.ucsd.edu/classes/sp00/cse231/dynamopldi.pdf
2. https://stackoverflow.com/questions/5641356/why-is-it-that-bytecode-might-run-faster-than-native-code/5641664#5641664
3. https://en.wikipedia.org/wiki/Just-in-time_compilation

Когда диспетчер задач сообщает вам, что процессор загружен на все 100 %, вы можете подумать, что система работает изо всех сил и не имеет дополнительных вычислительных мощностей. А когда диспетчер задач сообщает о том, что ЦП загружен на 40 %, вы интуитивно полагаете, что он потребляет 40 % от всей общей доступной мощности. То было достаточно точное толкование как в Windows 7, так и Windows Server 2008 R2. Но с выходом нового дизайна, впервые представленного в Windows 8, вкладки Процессы и Производительность диспетчера задач теперь полагаются на разные метрики и показывают цифры, которые вводят в заблуждение и которые без дополнительного контекста совершенно бессмысленны.

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

(*) В более ранних версиях Windows это были грубые приближения. Точность доступных показателей улучшилась от Windows XP к Vista, а потом и к Win7, как и в соответствующих им серверных версиях ОС.

Чтобы попытаться учесть эти сложности, Windows ввела понятие служебной программы процессора вместе со счетчиками производительности, которые измеряют эту служебную программу. Windows определяет полезность процессора как объем выполненной работы в процентах от объема работы, которую он мог бы выполнить, если бы он постоянно работал на своем номинальном уровне производительности и никогда не включал режим повышенной производительности. Когда процессор включает режим повышенной производительности обычное вообще явление его процент полезности может легко превысить 100 %. Возможная верхняя граница неопределенна и зависит от множества факторов, которые Windows не может измерить напрямую. Вкладки Процессы и Производительность диспетчера задач теперь используют счетчик процент полезности процессора в качестве основы для показания их загруженности, а не счетчик процент загруженности процессора, на который полагался Диспетчер задач, который по-прежнему используется вкладкой Подробности диспетчера задач и Process Explorer, входящий в комплект Sysinternals.

В результате, поскольку динамически настраиваемые процессоры автоматически переходят в расширенный режим под нагрузкой, процент загруженности ЦП диспетчера задач на процесс, который активно выполняет код, обычно будет значительно больше, чем время его процессора. Но поскольку это число находится на шкале, которая ограничена 100 %, диспетчер задач создает впечатление, что процесс занимает больше вычислительных мощностей системы, чем есть на самом деле. Некоторое время сам диспетчер задач сообщал об общей загрузке ЦП более 100 %. Поскольку это противоречит здравому смыслу даже для людей, которые понимают концепцию полезности, диспетчер задач теперь ограничивает сообщаемые значения на отметке в 100 %. Это приводит в дальнейшем еще к большему искажению. Я покажу.

На приведенных ниже скриншотах Process Explorer и вкладка Производительность диспетчера задач подтверждают, что ровно половина из двенадцати потоков полностью загружены, а остальные процессоры почти полностью простаивают. Однако обратите внимание, что Process Explorer сообщает об общем проценте загруженности ЦП чуть более 50, а диспетчер задач сообщает о 83. Возможно, это должно быть 83 % по шкале 166 %. Но что это вообще значит? Процент буквально означает на сотню. Вкладка Производительность диспетчера задач также показывает, что базовая частота процессоров составляет 2,40 ГГц, но во время этого измерения скорость составляет 3,94 ГГц. Получается, что 83 % умножить на 2,40/3,94 это 50,56%, что близко к фактическому использованию. 83 процента в данном случае фактически находятся во временной шкале 164,17 (100 %*3,94/2,40). Это объясняет, как получаются числа, но не делает их интуитивно понятными или значимыми.

На вкладке Процессы диспетчера задач указано, что моя тестовая программа потребляет 82,8 %, то есть почти все из 83 % общего использования, о которых она сообщает. В то же время на вкладке Подробности диспетчера задач указано, что моя программа потребляет 50 % ресурсов ЦП. Цифры на вкладке "Подробности", основанные на "проценте загруженности процессора", а не на "процент полезности процессора" и более понятны, чем числа на вкладке "Процессы".

Давайте возьмем его на ступеньку выше и запустим восемь потоков, привязанных к потокам ЦП, задействуя две трети процессора, оставив остальные простаивать. Вкладка Производительность диспетчера задач сообщает о 100 % загрузке ЦП, подразумевая, что система работает на максимальной мощности, в то время, как и она, и Process Explorer ясно показывают, что четыре из двенадцати процессоров простаивают и готовы к работе. На вкладке Процессы диспетчера задач указано, что тестовая программа использует 100 % ЦП, а на вкладке Подробности указано, что она потребляет только 67 % две трети доступной вычислительной мощности.

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

Здесь можно взглянуть на точку зрения моего коллеги Джеффа Стоукса по поводу данного вопроса.

Наверное, каждый, кто работает с SQL Server оказывался, или ещё окажется, в такой ситуации: вечер пятницы, ты уже мысленно готов отдыхать и тут начинают прилетать уведомления о высокой нагрузке на CPU твоего SQL Server, телефон начинает звонить и в системе мониторинга ты видишь картинку как на КДПВ.

И, с одной стороны, в этом может не быть особой проблемы - да, серверу тяжело, да, это неприятно, но ведь, господи, ну сформируется ваш отчёт не за 15, а за 45 секунд - делов-то, вы же видите - вас много, а сервер один, нужно просто немножко подождать. Но что, если при всём при этом, есть какие-то бизнес-процессы, которые не могут ждать? Что если при такой нагрузке продажа товара становится настолько медленной, что покупатели отказываются от покупки?

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

И иногда их и правда можно разделить - с помощью Resource Governor.

Сразу несколько примечаний:

1. Resource Governor доступен только в Enterprise Edition. Если у вас любая другая редакция (ну ещё Developer, но он же у вас не в проде, да?) - к сожалению, использовать его вы не сможете.

2. Тут мы не говорим о таких важных вещах, как оптимизация запросов, структур хранения данных, разнесении нагрузки на разные реплики, секционировании, шардировании.

3. Мы говорим только о том, что такое Resource Governor, как и для чего он может быть полезен, когда бесполезен, чем опасен, как его настроить, что можно мониторить и как его обойти и выключить (если вдруг что).

4. В один пост я пытаюсь засунуть достаточно много информации и где-то сознательно, а где-то несознательно, будут допущены упрощения.

5. Сдуру можно сломать всё что угодно, всё что вы делаете, вы делаете на свой страх и риск.

Прежде чем начать разговор о Resource Governor, на всякий случай скажу. что кроме CPU запросы используют диск и оперативную память - SQL Server читает данные с диска и записывает их в buffer pool (но Resource Governor никаким образом не позволяет влиять на buffer pool), откуда их уже "забирает" CPU. Память, кроме того, чтобы использоваться в качестве buffer pool, нужна ещё для сортировок, джойнов и всяких таких вещей (можно немного глянуть тут, где я писал про использование varchar(max)).

И вот, Resource Governor позволяет делать три вещи:

1. Создавать пулы ресурсов (CPU, RAM, IOPS) - ограничивать ресурсы (или обеспечивать их необходимый минимум), доступные пользовательским сессиям.

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

3. Определять к какой группе (и, соответственно, пулу) будет относиться пользовательская сессия.

Если вы посмотрите в dmv sys.dm_exec_sessions, в нём есть столбец group_id - это идентификатор группы нагрузки resource governor, именно при установке соединения (точнее, после авторизации) и до конца жизни сессии определяется к какой группе (и, соответственно, пулу) она будет относиться.

По-умолчанию, у нас есть два пула - internal и default и две группы - internal и default (не знаю почему я не дорисовал Internal group). Собственно, по названию, должно быть понятно - internal - это то, что используют процессы самого SQL Server - мы не можем менять ни группу, ни пул - и не надо. default - это то, куда, по-умолчанию, попадают все пользовательские сессии.

Тут есть одна важная вещь, про которую нужно обязательно сказать. В SQL Server есть такая штука как Dedicated Admin Connection (DAC) - крайне, крайне желательно убедиться, что вы можете его использовать, поскольку при подключении через DAC, админская сессия попадает в internal pool. Даже если что-то пошло совсем не так как ожидалось, через DAC можно будет подключиться и что-то поправить. Без DAC, если будут проблемы с подключениями из-за Resource Governor, вероятно, придётся запускать сервер в однопользовательском режиме, за что остальные пользователи, я думаю, спасибо не скажут. После того, как вы включили возможность его использовать не только локально - научитесь его использовать при подключении через SSMS.

Теперь, когда введение можно считать законченным, перейдём непосредственно к Resource Governor.

Чтобы создать пул мы используем команду CREATE RESOURCE POOL (MSDN):

CREATE RESOURCE POOL pool_name  [ WITH      (          [ MIN_CPU_PERCENT = value ]          [ [ , ] MAX_CPU_PERCENT = value ]           [ [ , ] CAP_CPU_PERCENT = value ]           [ [ , ] AFFINITY {SCHEDULER =                    AUTO                 | ( <scheduler_range_spec> )                   | NUMANODE = ( <NUMA_node_range_spec> )                } ]           [ [ , ] MIN_MEMORY_PERCENT = value ]          [ [ , ] MAX_MEMORY_PERCENT = value ]          [ [ , ] MIN_IOPS_PER_VOLUME = value ]          [ [ , ] MAX_IOPS_PER_VOLUME = value ]      )   ]  [;]    <scheduler_range_spec> ::=  { SCHED_ID | SCHED_ID TO SCHED_ID }[,...n]    <NUMA_node_range_spec> ::=  { NUMA_node_ID | NUMA_node_ID TO NUMA_node_ID }[,...n]  

И пройдёмся по параметрам:

1. MIN_CPU_PERCENT - если процессор загружен на 100%, не меньше этого процента будет использоваться на выполнение запросов тех сессий, которые попали в этот пул. ВАЖНО: если им в этом пуле столько и не надо, "недоиспользованный" CPU, будет доступен другим пулам, если нужен им.

2. MAX_CPU_PERCENT - если процессор загружен на 100%, запросы сессий из этого пула, суммарно, не будут использовать больше указанного процента. ВАЖНО: Это не жёсткое ограничение, если запросам из пула нужно будет больше, а запросам из других пулов будет достаточно ресурсов, запросы из этого пула БУДУТ использовать больше.

3. CAP_CPU_PERCENT - а вот это жёсткое ограничение. Запросы сессий из этого пула не смогут использовать больше, чем указано, даже если процессор больше вообще никто не использует.

4. AFFINITY - позволяет привязать пул ЛИБО к конкретному(-ым) шедулерам (условно, ядрам процессора), ЛИБО к конретной(-ым) NUMA-нодам

5. MIN/MAX_MEMORY_PERCENT - задают (в процентах, понятно) сколько памяти из всей памяти может быть выделено запросам из пула. Ещё раз обращаю внимание - эта настройка никак не влияет на buffer pool, мы им не управляем. Это про memory grants.

6. MIN/MAX_IOPS_PER_VOLUME - задаёт минимальное и максимальное КОЛИЧЕСТВО IO операций (без деления на чтение и запись, только общее), доступное запросам из пула.

Отдельно нужно добавить про MIN_CPU_PERCENT - сумма всех MIN_CPU_PERCENT по всем пулам не может превышать 100%. В идеале, я бы и до 100% не стал доводить, оставив хоть что-то internal и default пулам.

Чтобы создать группу, используем команду CREATE WORKLOAD GROUP (MSDN):

CREATE WORKLOAD GROUP group_name[ WITH    ( [ IMPORTANCE = { LOW | MEDIUM | HIGH } ]      [ [ , ] REQUEST_MAX_MEMORY_GRANT_PERCENT = value ]      [ [ , ] REQUEST_MAX_CPU_TIME_SEC = value ]      [ [ , ] REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value ]      [ [ , ] MAX_DOP = value ]      [ [ , ] GROUP_MAX_REQUESTS = value ] ) ][ USING {    [ pool_name | "default" ]    [ [ , ] EXTERNAL external_pool_name | "default" ] ]    } ][ ; ]

Параметры:

1. IMPORTANCE - задаёт "приоритет" сессии в группе. Разные группы могут относиться к одному пулу, соответственно, мы можем сказать, что сессии вот в этой группе "более важны", чем в другой. Это не значит, что "более важные" сессии будут выполняться, а "менее важные" ждать - просто больше ресурсов из пула будет доступно "более важным" сессиям.

2. REQUEST_MAX_MEMORY_GRANT_PERCENT - по умолчанию 25%, задаёт какое количество из максимальной памяти пула сессия может получить в своё распоряжение. В общем случае, если ну никак не получается выделить столько памяти - запрос упадёт с ошибкой.

3. REQUEST_MAX_CPU_TIME_SEC - если запросу потребовалось больше времени, чем тут указано, он не прервётся, но будет сгенерировано событие cpu_threshold_exceeded, которое можно отловить с помощью Extended Events. Начиная с определённого CU для SQL Server 2016/2017, появился trace-флаг, включение которого приведёт к тому, что запрос будет прерван, если CPU time превысит указанное значение.

4. REQUEST_MEMORY_GRANT_TIMEOUT_SEC - сколько секунд запрос будет ждать выделения памяти, если время прошло, а память так и не появилась - запрос падает с ошибкой.

5. MAX_DOP - указывает допустимую степень параллелизма. Это значение "важнее", чем указанное в настройках сервера, БД, или в хинте в запросе. Если у вас везде 1, а тут 4 - запросы из этой группы могут выполняться с MAX DOP = 4.

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

Последнее, о чём нужно поговорить, перед тем как уже пощупать руками - это функции классификации. Пулы и группы мы создадим, но как дать понять SQL Server какие сессии к какой группе должны относиться?

Тут, к сожалению, всё не очень просто. Ну, точнее, просто, но не всем подойдёт (привет 1С). Функция классификации - это обычная scalar UDF, созданная в БД master. К ней есть два требования - она должна быть объявлена как SCHEMABINDING и должна возвращать значение типа SYSNAME. Нужно понимать, что выполняется эта функция сразу после логина и выполняется для каждого соединения, соответственно, она должна выполняться очень-очень-ОЧЕНЬ быстро, иначе станет очень узким местом и вам придётся использовать DAC, чтобы её заменить.

Нужно добавить, что нельзя изменять (ALTER) функцию, которая указана в качестве функции классификации, и нельзя менять привязку групп к пулам, если в них есть пользователи. НО! На лету можно: добавлять новые пулы и группы, и можно заменить одну функцию классификации на другую.

Для отключения Resource Governor необходимо выполнить команду:

ALTER RESOURCE GOVERNOR DISABLE;

Вот теперь введение точно можно считать законченным и можно создавать пулы/группы/функцию и проверять/мониторить это всё.

Начнём с CPU и создадим пулы:

CREATE RESOURCE POOL [pool1]WITH (    MIN_CPU_PERCENT = 15,    MAX_CPU_PERCENT = 15,    CAP_CPU_PERCENT = 20);CREATE RESOURCE POOL [pool2]WITH (    MIN_CPU_PERCENT = 50,    MAX_CPU_PERCENT = 90);

Первый пул, в случае "борьбы" за процессор сможет забирать не менее и не более 15 процентов, но из-за CAP_CPU_PERCENT не сможет использовать больше 20 процентов CPU, даже если никакой "борьбы" нет. Второй пул, в случае "борьбы" сможет взять не менее 50 и не более 90 процентов, при этом, если никому больше процессор не нужен будет - сможет взять все 100.

Создаю группы нагрузки:

CREATE WORKLOAD GROUP [pool1_group1]WITH (    IMPORTANCE = HIGH,    REQUEST_MAX_CPU_TIME_SEC = 5,    MAX_DOP = 2)USING [pool1];CREATE WORKLOAD GROUP [pool2_group1]WITH (    IMPORTANCE = HIGH)USING [pool2];CREATE WORKLOAD GROUP [pool2_group2]WITH (    IMPORTANCE = MEDIUM)USING [pool2];CREATE WORKLOAD GROUP [pool2_group3]WITH (    IMPORTANCE = LOW,    GROUP_MAX_REQUESTS = 1 )USING [pool2];

В первом пуле я создаю всего одну группу нагрузки, указываю, что сессии из этой группы смогут рассчитывать только на 2 ядра (на уровне сервера стоит MAXDOP = 4), и что максимальная длительность запроса составляет 5 секунд. Важность запросов из группы я объявляю как высокую, но, поскольку группа в пуле одна, эта важность не повлияет ни на что.

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

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

USE [StackOverflow2013]GOCREATE LOGIN p1g1 WITH PASSWORD = N'1', CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF;CREATE LOGIN p2g1 WITH PASSWORD = N'1', CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF;CREATE LOGIN p2g2 WITH PASSWORD = N'1', CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF;CREATE LOGIN p2g3 WITH PASSWORD = N'1', CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF;CREATE USER p1g1 FOR LOGIN p1g1;CREATE USER p2g1 FOR LOGIN p2g1;CREATE USER p2g2 FOR LOGIN p2g2;CREATE USER p2g3 FOR LOGIN p2g3; EXEC sp_addrolemember N'db_owner', N'p1g1';EXEC sp_addrolemember N'db_owner', N'p2g1';EXEC sp_addrolemember N'db_owner', N'p2g2';EXEC sp_addrolemember N'db_owner', N'p2g3';

А вот и функция классификации:

USE [master]GOCREATE FUNCTION fnClassify()RETURNS SYSNAME WITH SCHEMABINDINGASBEGIN    RETURN         CASE ORIGINAL_LOGIN()             WHEN 'p1g1' THEN 'pool1_group1'            WHEN 'p2g1' THEN 'pool2_group1'            WHEN 'p2g2' THEN 'pool2_group2'            WHEN 'p2g3' THEN 'pool2_group3'        ELSE 'default' END;END;

И сразу проверим, куда эта функция отнесёт нас:

SELECT master.dbo.fnClassify();

Последнее, что нужно сделать - указать Resource Governor созданную функцию классификации и применить изменения:

ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fnClassify);  ALTER RESOURCE GOVERNOR RECONFIGURE;  

Теперь можно логиниться с созданными учётными данными и посмотреть, что из этого вышло.

SELECT     s.session_id,     s.login_name,     wg.group_id,    wg.name AS workload_group_name,    wg.pool_id,    rp.name AS pool_nameFROM sys.dm_exec_sessions sJOIN sys.dm_resource_governor_workload_groups wg ON s.group_id = wg.group_idJOIN sys.dm_resource_governor_resource_pools rp ON wg.pool_id = rp.pool_idWHERE s.session_id >= 50

Мы видим, что все новые пользователи благополучно "расползлись" по назначенным группам. Object Explorer и моё основное соединение остались в группе и пуле default.

Теперь попробуем нагрузить процессор и помониторить - работают ли указанные при настройке ограничения. В perfmon есть две группы счётчиков: SQLServer: Workload Group Stats и SQL Server: Resource Pool Stats. Обратите внимание, что доступные счётчики зависят от версии вашего SQL Server.

В сессии p1g1 запускаю запрос, который не делает ничего полезного, только грузит процессор, причём хинтом указываю, что он может использовать все 8 ядер моего лютого i5-8250u, если ему это нужно

USE StackOverflow2013;GOSELECT SUM (CAST (VoteTypeId AS decimal(12,2))) / AVG (CAST (VoteTypeId AS decimal(14,4)))FROM dbo.VotesOPTION (MAXDOP 8);GO

В то же время, в perfmon смотрим на показания SQLServer: Workload Group Stats: CPU Usage% и CPU Delayed % по группе pool1_group1:

CPU Usage% упёрся в CAP_CPU_PERCENT = 20, Resource Governor не даёт использовать больше CPU моему запросу, а сам запрос может использовать только 2 ядра, вместо положенных 8, из-за того, что при создании группы нагрузки, я ограничил запросы из группы именно этим значением. CPU Delayed %, в свою очередь показывает, что пул хотел бы получить в своё распоряжение ещё около 5% процессорного времени, но Resource Governor строго его ограничил.

Посмотрим тот же запрос и те же счётчики, но выполненный от имени p2g3, пользователя, который входит в группу с наименьшим приоритетом (IMPORTANCE = LOW) во втором пуле.

Поскольку это был единственный запрос, который выполнялся в этот момент, запросу ничего не мешало использовать все ядра и все 100% CPU. Правда CPU Delayed там где-то подпрыгивал аж до 0,483%, но это связано с какими-то внутренними процессами из Internal pool, которым тоже нужен был CPU. А что будет, если запустить, параллельно ещё что-нибудь тяжелое в том же пуле (pool2), но из другой группы нагрузки, с более высоким приоритетом?

Добавляю в запрос ещё немного вычислений и запускаю от имени p2g1 (IMPORTANCE = HIGH) и через пару секунд тот же самый запрос от имени p2g3 (IMPORTANCE = LOW):

USE StackOverflow2013;GOSELECT SUM (CAST (VoteTypeId AS decimal(12,2))) / AVG (CAST (VoteTypeId AS decimal(14,4))) * AVG (CAST (PostId AS decimal(19,4)))FROM dbo.VotesOPTION (MAXDOP 8);GO

Тут картинка становится интереснее. Пока запрос был один, запрос из группы с высоким приоритетом забирал весь доступный CPU, но как только появился запрос из группы с низким приоритетом - пришлось делиться. От щедрот, как видно на графике, было выдано 10% CPU, соответственно, пока запросы выполнялись параллельно, запрос из группы с низким приоритетом мог использовать только 10% CPU, и только когда первый запрос завершился, он смог использовать все 100%.

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

Сначала запрос был запущен от имени пользователя с низким приоритетом, потом со средним и в конце - с высоким:

Видно, что сначала группе с низким приоритетом было доступно 100%. Как только подключился запрос из группы со средним приоритетом - он забрал себе 70-75%, а низкому приоритету осталось 25-30%. Когда пришёл босс, он забрал себе около 65-70% процессорного времени, средний оставил себе ещё 22,5-25%, а низкому приоритету осталось всего 7.5-10% процессорного времени.

Как вы видите, сначала завершился процесс с высоким приоритетом, затем со средним и после них - с высоким. И это не смотря на то, что выполнять запросы они начинали в обратном порядке!

Теперь, когда мы увидели как взаимодействуют процессы из разных групп внутри одного пула, давайте посмотрим как будут взаимодействовать процессы из разных пулов. Тот же самый запрос я запущу в трёх сессиях: от имени пользователя p1g1 из пула 1 и от имени пользователей p2g1 и p2g3 из пула 2, с высоким и низким приоритетом. Во-первых, я хочу посмотреть как будет делиться CPU между пулами, а во вторых - как будет делиться CPU между группами с разными приоритетами, когда им, параллельно, приходится делить CPU с другим пулом. Ещё раз обращаю внимание, что "приоритеты" (IMPORTANCE) - не влияют на приоритет пула, они влияют на "важность" запросов только внутри того пула, к которому привязана группа.

Верхний график - это использование CPU разными пулами (SQL Server: Resource Pool Stats: CPU Usage %). Сначала я запустил запрос от имени пользователя p1g1, привязанного к пулу с жёстко ограниченным CPU. Он сразу забрал свои максимально-максимально допустимые 20%, но как только подоспели запросы из второго пула, пришлось часть ресурсов отдать.

Напоминаю, что в первом пуле у нас стоит MAX_CPU_PERCENT = 15, а во втором пуле MAX_CPU_PERCENT = 90. Суммарно, получается, больше 100%, соответственно в дело вступают минимальные проценты. У первого пула минимум = 15%, у второго - 50%. Поэтому первый пул может рассчитывать на все свои 15%, а второй получает оставшиеся 85%.

Нижний график - это делёж процессора разными группами второго пула. Сначала был запущен запрос из группы с низким приоритетом и забрал все максимально доступные пулу 85%, но потом пришёл процесс с высоким приоритетом и забрал, примерно, 75% из них. Когда запрос с максимальным приоритетом завершился, запрос с минимальным приоритетом получил весь доступный пулу CPU обратно и тоже быстро завершился, после чего первый пул получил свои дополнительные 5% и дожал выполнение.

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

SELECT     s.session_id,    s.status,    r.task_address,    r.scheduler_idFROM sys.dm_exec_sessions s LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_idWHERE s.login_name = N'p2g3';

Обе сессии в состоянии running, но запрос (request) и соответствующий таск был создан только для одной и только ей доступен шедулер (сверху). Только после того, как запрос от первой сессии выполнился, начал выполняться второй (снизу).

Теперь попробуем поиграться с IO. Для начала отключим Resource Governor, удалим пулы и группы:

USE [master];GOALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = NULL);  ALTER RESOURCE GOVERNOR DISABLE; DROP WORKLOAD GROUP [pool1_group1];DROP WORKLOAD GROUP [pool2_group1];DROP WORKLOAD GROUP [pool2_group2];DROP WORKLOAD GROUP [pool2_group3];DROP RESOURCE POOL [pool1];DROP RESOURCE POOL [pool2];

Для начала нужно прикинуть сколько IO вообще способен выдать мой жёсткий диск. Хочу отметить, что оценка пропускной способности дисковой подсистемы - это достаточно нетривиальная задача, которую я тут решать не собираюсь. Мне нужно знать только сколько IOPS на чтение сможет выдать мой диск, если я его слегка подгружу на чтение, чтобы показать как работает Resource Governor и не более.

Используем для этого старый-добрый счётчик Физический диск: Обращений к диску/с, параллельно запустив что-то, что будет его активно читать, например вот так (не делайте этого на проде):

USE [StackOverflow2013]GODBCC DROPCLEANBUFFERS;GOSELECT *FROM dbo.Posts;    --сессия 1SELECT *FROM dbo.Comments; --сессия 2SELECT *FROM dbo.Votes;    --сессия 3

В разных сессиях я читаю разные таблицы, поскольку Enterprise (и, скорее всего, Developer) Edition умеет делать "shared scan" и результат может быть несколько некорректным. На графике ниже можно оценить с какой любовью и заботой подбирал жёсткий диск производитель моего ноута.

Итак, в среднем SQL Server может рассчитывать на 75 IOPS (на самом деле побольше, потому что запросы я начал выполнять через несколько секунд, после начала измерений). Окей, создаю пулы, группу, функцию классификации и запускаю Resource Governor.

USE [master];GOCREATE RESOURCE POOL [pool1]WITH (    MIN_IOPS_PER_VOLUME = 50);CREATE RESOURCE POOL [pool2]WITH (    MIN_IOPS_PER_VOLUME = 30,    MAX_IOPS_PER_VOLUME = 50);GOCREATE WORKLOAD GROUP [pool1_group1]USING [pool1];CREATE WORKLOAD GROUP [pool2_group1]USING [pool2];ALTER FUNCTION fnClassify()RETURNS SYSNAME WITH SCHEMABINDINGASBEGIN    RETURN         CASE ORIGINAL_LOGIN()             WHEN 'p1g1' THEN 'pool1_group1'            WHEN 'p2g1' THEN 'pool2_group1'        ELSE 'default' END;END;GOALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fnClassify);  ALTER RESOURCE GOVERNOR RECONFIGURE;  

Итак, посмотрим, как же разделится IO, если я запущу из разных сессий, относящихся к разным группам нагрузки, те же самые бессмысленные сканирования - для этого используем счётчики Disk Read IO/sec и Disk Read IO Throttled/sec из SQL Server: Resource Pool Stats. Сразу обращу ваше внимание, что в группе SQL Server: Workload Group Stats нет счётчиков, относящихся к IO, поэтому, вероятнее всего, "важность" группы никак не влияет на IO.

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

На верхнем графике, где показаны Read IOPS, видно, что сначала выполнялись запросы сессий только из пула 2 и Resource Governor "резал" их до 50, что указано в качестве максимального количества IOPS. После того, как добавился запрос из сессии, относящейся к первому пулу, основной его задачей было постараться сделать так, чтобы у всех выполнились минимальные ограничения - 50 в первом пуле и 30 во втором. Причём, скорее всего, из-за того, что во втором пуле IO были ограничены "сверху", и Resource Governor и так приходилось резать ему пропускную способность, "тормозить" IO первого пула ему приходилось только тогда, когда жёсткий диск уже не мог обеспечить минимум для второго пула.

В заключение, добавлю, что Resource Governor появился с SQL Server 2008 и с тех пор неплохо так обновился. Всё, что написано выше, в принципе, уже должно работать в SQL Server 2014, но на всякий случай - проверьте документацию по своей версии.

Последнее, что нужно рассказать - это когда Resource Governor может помочь. Наверное, можно было с этого начать, но мне кажется, что после демонстрации проще понять о чём речь.

В случае нагрузки на CPU, Resource Governor имеет шансы помочь только в том случае, если CPU - это реально узкое место. Если процессор сервера не загружен на 100% - маловероятно, что от Governor'а будет толк. Да, вы можете использовать CAP_PERCENT, но это значит, что в моменты, когда особой нагрузки нет, он будет только вредить.

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

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

Будьте осторожны и не забывайте про DAC.

Дополнительное чтиво:

1. MSDN про Resource Governor

2. Roy Ernest: Resoruce Governor

3. MSDN про функции классификации

Когда AMD начала предлагать процессоры Threadripper с большим количеством ядер, единственным рынком, который потреблял столько, сколько производила AMD, был рынок графического дизайна компании, которые занимались визуальными эффектами и рендерингом; им понравились количество ядер, поддержка памяти, полосы PCIe и цена. Но если есть что-то ещё, повышающее производительность, то это само стремление к производительности Threadripper Pro.

Брррр вот во что превращается вычислительная графика

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

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

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

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

Если вычислительная часть программного обеспечения не подвержена такой нагрузке, например, эта часть структурно более линейна, то потратить полгода на его переработку для GPU это напрасная трата сил. Или даже если математика лучше работает на GPU, попытки перестроить 20-летнюю (или ещё более старую) кодовую базу для GPU всё равно требуют значительных усилий со стороны группы экспертов.

Вычисления на GPU идут в гору с тех пор, как я выполнял их в конце двухтысячных годов. Но факт остается фактом: всё ещё существует ряд отраслей, представляющих смесь производительности CPU и GPU. К ним относятся машинное обучение, нефтегазовая отрасль, финансы, медицина, и та сфера, на которой мы сегодня сосредоточимся, визуальные эффекты.

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

Некоторые плагины имеют ускорение GPU, например Blender Cycles, и переход на ещё более ускоренную GPU рабочую нагрузку занимает некоторое время например. область, привлекающая большое внимание GPU, дизайн с ускоренной трассировкой лучей.

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

Скорее всего, киностудия предпочтёт медленный рендеринг более высокого качества на CPU, чем быстрый и шумный на GPU, или же, наоборот, рендеринг изображения в более низком разрешении, а затем и рендеринг более высокого класса с искусственным интеллектом.

Поставляющие продукцию для отрасли OEM-производители сообщили нам, что ряд студий прямо скажут: рендеринг их рабочего процесса на CPU единственный способ рендеринга. Другой аспект память: соответствующий задаче CPU может иметь от 256 ГБ до 4 ТБ DRAM, тогда как лучшие GPU имеют пропускную способность в 80 ГБ (и это очень дорогие графические процессоры).

Вот о чём я говорю: VFX-студии до сих пор предпочитают вычисления на CPU, и, чем таких вычислений больше, тем лучше. Когда компания AMD выпустила новые процессоры на базе Zen, в частности 32- и 64-ядерные модели, их сразу же резервировали как потенциальную замену Xeon, с которыми работали студии VFX.

В компонентах AMD внимание уделяется вычислениям FP ключевому элементу в дизайне VFX. С двумя ядрами на сокет в сочетании с большим количеством кеша на одно ядро, процессор AMD был лучшим в деле. Это означает, что, хотя первые многоядерные вычислительные компоненты обладали неоднородной архитектурой памяти, это не было большой проблемой, как в случае с некоторыми другими вычислительными процессами.

Ряд компаний VFX, насколько мы понимаем, сосредоточились на платформе AMD Threadripper поверх соответствующего EPYC. Когда оба компонента впервые появились на рынке, VFX-студиям было очень легко инвестировать в рабочие станции, построенные на базе Threadripper, тогда как EPYC больше предназначался для серверной стойки.

Посмотрим на Threadripper 3000 и EPYC 7002: есть 64 ядра, 64 полосы PCIe 4.0 и большой выбор. студии VFX тогда всё ещё предпочитали Threadripper в основном из-за того, что эти процессоры предлагали лучшую мощность в 280 Вт в чём-то, что могло бы легко прийти от системных интеграторов, таких как Armari. Эти интеграторы специализируются на high-desk и high-compute, они также запрашивали у AMD большего.

Сегодня компания AMD развернула платформу Threadripper Pro, удовлетворяющую некоторым из требований выше. Тогда как VFX всегда ориентирован на вычисления в ядре, TR Pro предоставляет удвоенную полосу PCIe, удвоенную пропускную способность памяти, поддержку до 2 ТБ памяти, а также поддержку от администратора-профессионала.

Линии PCIe могут быть расширены до локального хранилища (которое всегда важно в VFX), а также больших RAM-дисков; поддержка администратора через DASH помогает поддерживать управление системами компании. AMD Memory Guard также входит в линейку Pro, которая создана, чтобы обеспечивать полное шифрование памяти.

Помимо работы с VFX компания AMD мировой лидер в области вычислений с помощью TR Pro в проектировании продуктов с помощью Creo, 3D-визуализации через KeyShot, в области проектирования архитектурных моделей с помощью ПО Autodesk Revit, а также в областях Data Science, таких как анализ массивов данных о нефти и газе, где наборы данных возрастают до сотен гигабайт и требуют существенной вычислительной поддержки.

Threadripper Pro против Workstation EPYC (WEPYC)

Глядя на преимущества, которые дают эти новые процессоры, становится ясно, что они скорее компоненты EPYC в стиле рабочей станции, чем "усовершенствованные" драйверы Threadripper. Вот объясняющая таблица:

Чтобы получить (начиная с EPYC) эти новые компоненты, всё, что AMD нужно было сделать, это поднять TDP до 280 Вт и урезать поддержку DRAM. Если начинать с базового Threadripper, есть 34 существенных изменения. Так почему же название по-прежнему Threadripper Pro, а не Workstation EPYC?

Чтобы ответить на этот вопрос, снова вернёмся в студии VFX. Когда они уже купились на брендинг и образ мысли Threadripper, сохранить название компонентов Threadripper значит, помочь сгладить переход. Как было сказано, они предпочитают Threadripper, а не EPYC (из того, что сказали нам), и поэтому сохранение названия означает, что не нужно никого переучивать.

Кроме того, линия процессора EPYC несколько изломана: есть стандартные версии, высокопроизводительные модели H, высокочастотные модели F и серия заказных конструкций под B, V, другие серии для конкретных клиентов. Сохраняя название Threadripper Pro, AMD сохраняет всё под одним началом.

Предложения Threadripper Pro: от 12 до 64 ядер

В середине прошлого года AMD анонсировала эти процессоры, а также Lenovo Thinkstation P620 как платформу их запуска. По моему опыту, линейка Thinkstation очень хорошо спроектирована, и сегодня мы тестируем наш 3995WX в P620.

TR Pro анонсировали вместе с Lenovo, и мы не были уверены, что Threadripper станет доступен какому-то другому OEM-производителю. Мы спросили об этом самих OEM-производителей в том же году, ещё до того, как узнали, существует ли TR Pro на самом деле; они заявили, что AMD даже не отметил платформу в своём плане развития, о котором мы тогда рассказывали.

С тех пор мы узнали, что у Lenovo был эксклюзивный срок в полгода; информацию предоставили другим производителям (ASUS, GIGABYTE, Supermicro) только после того, как было объявлено об этом.

В связи с этим AMD объявила, что Threadripper Pro выходит на рынок розничной торговли как для других OEM-производителей, которые будут проектировать системы, так и для конечных пользователей, которые будут собирать свои системы.

Несмотря на использование того же сокета LGA4094, что и у другие процессоров Threadripper и EPYC, TR Pro заблокируют на материнских платах WRX80. На данный момент нам известно о трёх моделях, например Supermicro и GIGABYTE, и об ASUS Pro WS WRX80E-SAGE SE Wi-Fi, которая у нас была, однако мы не смогли её протестировать.

Из четырёх перечисленных выше процессоров три лучших идут в продажу. Стоит отметить, что только 64-ядерный процессор поставляется с 256 МБ кеша L3, тогда как 32-ядерный поставляется с 128 МБ L3.

AMD придерживается такой архитектуры, что в этих чиплетах (chiplet) используется только абсолютно необходимое количество наборов микросхем, кеш L3 на одно ядро, а также 8 ядер на набор микросхем (в линейке продуктов EPYC дело обстоит немного иначе). Четвёртый процессор, 12-ядерный, по-видимому, является специфическим процессором, он создан только для OEM-производителей готовых систем.

Threadripper Pro против всех

Эти предложения Threadripper Pro созданы конкурировать с двумя сегментами рынка: во-первых, с самой AMD, демонстрирующий высокую производительность всем пользователям профессиональных систем высокого класса, построенных на аппаратном обеспечении первого поколения Zen.

Второе предложение нацелено на пользователей рабочих станций Intel с односокетным Xeon W (который имеет 28 ядер) либо на пользователей двухсокетной системы Xeon, которая дороже или которая потребляет намного больше энергии просто потому, что она двухсокетная, но при этом архитектура памяти системы неоднородная.

У нас есть почти все системы (нет 7702P, но есть 7742), и на самом деле это единственные процессоры, которые следует учитывать, если 3995WX в вашем случае один из вариантов:

Intel достигает максимума на 28 ядрах, и обойти его невозможно. Технически у Intel есть линейка процессоров AP до 56 ядер, однако это для специализированных систем, а для тестирования нам не отправили ни одного процессора этой линейки. Кроме того, это $ 20 000+ на один процессор, а также два процессора в одной системе, которые прикрепили болтами в одной упаковке.

Лучшее оборудование AMD это Threadripper, лучший доступный процессор EPYC версий 2P. Самым лучшим здесь был бы 7702P, вариант с одним сокетом и по гораздо более конкурентоспособной цене, однако у нас для целей тестирования его нет; вместо него у нас есть AMD EPYC 7742 версия с двумя сокетами, но с несколько большей производительностью.

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

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

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

Узнайте подробности, как получить Level Up по навыкам и зарплате или востребованную профессию с нуля, пройдя онлайн-курсы SkillFactory со скидкой 40% и промокодомHABR, который даст еще +10% скидки на обучение.

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Apple отказывается от процессоров Intel в пользу собственных на базе ARM. Последуют ли её примеру другие производители ПК?

Apple отказывается от процессоров Intel в пользу своих собственных. Почему это произошло и каковы возможные последствия для всего рынка ПК? Как случилось, что микроархитектура CPU, изначально появившаяся в безвестных британских домашних компьютерах в 1980-х годах, бросает вызов империи Intel? В этой статье мы рассмотрим специфику проектирования процессоров ARM, проследим за тем, как они совершенствовались с годами и как достигнутый прогресс отразился на тестах производительности, а также сопоставим полученные результаты с результатами тестов железа от Intel. Ещё порассуждаем о конкуренции на рынке ПО и как она сказывается на нас, потребителях. И хорошо ли для пользователей ПК иметь микроархитектуру, построенную на совершенно отличном от привычного набора инструкций.
Что представляет собой процессор от Intel? Что такое ПК? В те дни, когда компоненты для IBM поставляли различные производители, у неё (IBM) имелись собственные процессоры 801 RISC. Однако она отказалась от них в пользу более экономичных Intel 8088, и так повелось, что в любой совестимый ПК можно было поставить процессор с архитектурой x86.
В теории проектировать и производить x86-совместимые процессоры мог любой, однако по закону Intel обладала патентом на наборы команд CPU.Это означало, что всем желающим их приобрести, пришлось бы покупать лицензию. Если сторонняя фирма и занималась разработкой или производством процессоров x86, то только потому, что Intel или суд дали на это разрешение. С AMD дела обстоят иначе, поскольку она заключила соглашение о патентной лицензии с Intel, чтобы потом не судиться друг с другом до беспамятства.
Долгое время производством CPU на архитектуре x86 занималось несколько компаний: IBM с её линейкой 386-х и 486-х процессоров, AMD, Cytrix, VIA, NEC, Transmeta и др. Дизайн их CPU оставлял желать лучшего. Intel всегда была победителем, в то время как другие (за исключением AMD и IBM) были лишь рядовыми спортсменами. Вы, конечно, могли бы возразить, что на рынке была конкуренция. Но считалась ли конкуренцией битва за отбросы? Суть в том, что у Intel не было достойного соперника даже сегодня, учитывая, что дела у AMD идут хорошо, ей (AMD) принадлежит всего лишь 18% рынка. Сам производитель заявлял в 2020-м году о том, что стремится заполучить 10% рынка серверов и снова достигнуть высот 2006 года, когда на долю Opteron приходилось 25% рынка.
Можно, конечно, сетовать на отсутствие конкуренции, но что можно изменить, чтобы положить конец создавшемуся положению вещей? Недавно Apple сделала громкое заявление о том, что она отказывается от процессоров на базе Intel и переводит всё своё железо на CPU собственной разработки. Речь идёт не только о лэптопах и низкопроизводительных iMacs, но даже о высокопроизводительных рабочих станциях на базе Intel Xeon. Планы, конечно, грандиозные, но как она собирается воплощать их в жизнь?

Старые добрые времена

Итак, Apple не собирается строить будущие процессоры на базе архитектуры x86. Ни для кого не секрет, что iPhone очень популярны. Кроме того, их причисляют к самым быстрым смартфонам на рынке мобильных устройств. При желании компания могла бы задействовать любую микроархитектуру своих мобильных CPU для разработки настольных систем. Опять же, кто проектировал эти процессоры? Сама Apple, используя архитектуру набора команд (ISA) по лицензии ARM.

Для справки: микроархитектура ARM использует сокращённый набор команд (RISC), в то время как микроархитектура x86 использует полный набор команд (CISC).

Пару слов о RISC. Принципами проектирования RISC-микропроцессора являются оптимизация набора команд и работы ядра, гарантия того, что инструкции можно выполнить за один цикл памяти, устранение ненужных команд. Со временем наборов инструкций стало больше, в основном за счёт отдельных криптографических/векторных/SIMD функций. Так что слово сокращённый не соответствует действительности.

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

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

Вступайте в ARMию

Далее мы проследим за тем, как архитектура ARM развивались с течением времени.

ARM это компания, которая разрабатывает спецификации АСК (архитектуры системы команд) процессоров ARM и улучшает их с помощью новых технологий. В их число входит особый дизайн ядер big.LITTLE, набор инструкций NEON SIMD и усовершенствованные математические сопроцессоры. Как правило, каждому новому семейству CPU производитель присваивает своё имя. Так у Apple оно впервые появилось с выходом линейки процессоров ARM11 с 32-битной архитектурой. Впоследствии разработчики Яблока создали собственную микроархитектуру на базе обновлений 64-битной ARMv8.

Первые iPhone работали на SoC от Samsung. Эта система на кристалле была построена на базе процессоров ARM11 с архитектурой ARMv6 2002-го года выпуска. Разработка и реализация iPhone осуществлялась в соответствии с нуждами, бытовавшими на заре появления смартфонов. В них была представлена SIMD (вычислительная система с одиночным потоком команд и множественным потоком данных) для считывания MPEG-файлов, увеличенный кэш (всего лишь 32К) и восьмиступенчатый конвейер. Так как функции изменения очерёдности команд и предсказания ветвлений были ограничены, то производительность первых iPhone не иначе как слабой не назовёшь.
iPhone 3GS стал первым удобным для пользования смартфоном от Apple (с точки зрения программных функций). Он всё ещё работал на SoC от Samsung, но теперь имел в составе улучшенное ядро Cortex-A8. Результаты испытаний показали увеличение скорости на 107% запишите это на счёт суперскалярного 13-ступенчатого конвейера и 10-ступенчатого конвейера NEON SIMD для ускорения медиаприложений. Помимо удвоенного кэша L1 в 3GS был впервые представлен кэш L2 на 256K, а также встроенный сопроцессор. Двигаясь по пути наименьшего сопротивления, ARM и Apple без труда оптимизировали CPU на ранних стадиях, что привело к увеличению скорости процессоров работы в два раза.
Apple A4 стала первой SoC собственной разработки Apple. Она дебютировала на оригинальном iPad с частотой 1 ГГц, однако позже использовалась в iPhone 4 при частоте 800 МГц. Если бы у Яблока была своя модель развития микропроцессоров Тик-так, как у Intel, то это была бы стадия так. Построенная на базе прежней архитектуры Cortex-A8 и того же 45-нм техпроцесса от Samsung она предлагала значительные улучшения за счёт увеличения частоты и удвоения кэша L2 до 512К и шины памяти до 64 бит.
Вместе с iPad 2 компания Apple представила свою принципиально новую однокристальную систему Apple A5 с частотой 1 ГГц. Позже та же SoC была заявлена в iPhone 4S, только работала она при 800 МГц. Выпуск Apple A5 стал знаковым событием для Яблока: теперь его ядра имели обновлённый дизайн Cortex-A9, а сам процессор стал двухъядерным. 45-нм техпроцесс от Samsung и тактовая частота остались прежними, зато быстродействие памяти выросло до 400 МГц, а кэш L2 снова удвоился до 1 Мб. В Cortex-A9 также были представлены ключевые улучшения: 8-ступенчатый конвейер с упреждающим считыванием, способный выполнять команды с изменением их последовательности, улучшенный NEON SIMD и математический сопроцессор с увеличенной вдвое скоростью.

Релиз A6 случился тогда, когда Apple начала брать под контроль разработку своих смартфонов и внедрять собственные дизайнерские идеи в ARMv7. Apple A6 были последними процессорами от Apple, построенными на 32-битной архитектуре. И хотя кэши L1 и L2 были те же, что и у А5, техпроцесс уменьшился до 32 нм, а тактовая частота выросла до 1,3 ГГц. Благодаря грамотным решениям в архитектуре производительность значительно увеличилась, потребление энергии же сократилось.

Судя по всему, A6 построен на ядре Cortex-A9, однако в нём использованы компоненты улучшенного чипа Cortex-A15, включая тогда ещё новые v4 FPU и Advanced SIMD v2. Анализ показывает, что в него было включено 5 функциональных модулей (2 арифметико-логических устройства (АЛУ), 2 математических сопроцессора/набора инструкций NEON и 1 модуль загрузки/сохранения). И вот этот значительно улучшенный FPU, оптимизированный кэш, специально выделенный модуль для загрузки/сохранения всё это привело к тому, что производительность памяти увеличилась втрое, а быстродействие вдвое.

С этого времени дела у производителя пошли в гору, а его А7 и вовсе совершил прорыв, став первым 64-битным процессором, в то время как остальные производители отстали с его выпуском на год. Благодаря архитектуре ARMv8-А на базе 28-нм техпроцесса от Samsung Apple добавила кэш L3 на 4 Мб, удвоила кэш L2 до 1 Мб и L1 до 128 Кб. Фактически Apple удвоила разрядность за счёт 4-х АЛУ, 2-х модулей для загрузки/сохранения, 2-х блоков передачи управления, 3-х модулей FPU/NEON. А7 достиг отметки 1млрд. транзисторов, а производительность его увеличилась на 33% по сравнению с А6. В то время Geekbench 2, изначально предназначенный только для замера производительности 32-битных систем, начал устаревать. Результаты же тестов в Geekbench 3 показали, что ядра А7 Cyclone превзошли своих конкурентов в два раза!

Apple А8 остаётся под вопросом. Похоже, в то время Apple уделяла больше внимания графическому ускорителю. Тогда же она разработала собственный пользовательский шейдер и, видимо, тогда же производитель начал переходить на новый 20-нм техпроцесс от TSMC. Схожая ситуация и с выпуском Apple А9, однако благодаря внедрению 20-нм техпроцесса от TSMC и 14-нм техпроцесса от Samsung тактовая частота процессора выросла до 1,8 ГГц, а L2 увеличился втрое до 3 Мб.
Появлению Apple А10 предшествовали два больших сдвига: внедрение технологии big.LITTLE от ARM, использующей высоко- и маломощные ядра для сбалансированного энергопотребления, и переход на уменьшенный до 16-нм техпроцесс от TSMC. Лёгкой победой стало увеличение частоты до 2,3 ГГц, которого удалось добиться посредством двух маломощных ядер Zephyr. Они работали на частоте 1 ГГц и тем самым использовали лишь 20% мощности больших ядер. Тогда же состоялся переход на новую микроархитектуру ARMv8.1-A, по сути являвшейся корректировочной версией прежней микроархитектуры. Эта система на кристалле от Apple была последней, проходившей тестирование в Geekbench 2. Результаты испытаний показывали лишь увеличение тактовой частоты, в то время как в новых версиях Geekbench появились замеры производительности графического ускорителя. И, согласно этим результатам, скорость работы элементов GPU от Apple стабильно росла.

В Apple A11 были представлены 2 крупных (Monsoon) и 4 малых (Mistral) вычислительных ядра, причём последние были построены на базе ядер Apple A6 Swift. В отличие от A10, малые ядра могли работать независимо от крупных ядер. Крупные ядра значительно улучшились: теперь они могли декодировать до 7 инструкций за такт вместо прежних 6. В то же время число блоков ALU увеличилось на две единицы, и теперь общее их количество достигло 6.

A12 стал ещё одним шагом вперёд для Apple он был первым доступным широкому кругу пользователей 7-нанометровым чипом. A12 сильно изменился в плане организации кэша, что в свою очередь способствовало уменьшению времени отклика и увеличению пропускной способности. Кэш L3 был изъят в пользу системного кэша L2 на 8 Мб, а L1 был удвоен до 256 К. Чип содержал 2 крупных высокопроизводительных ядра Vortex и 4 малых энергоэффективных ядра Tempest на базе Apple A6 Swift. Крупные ядра имели однопоточный быстрый режим до 2,5 ГГц. Микроархитектуры A11 и A12 были очень мощными, даже для десктопных процессоров.

Разработчики текущей модели A13 продолжили делать ставку на систему кэша. System Level Cache получила аж 16 Мб на обслуживание SoC. У малых ядер (Thunder) имеется 4Мб кэша L2, у крупных (Lightning) 8Мб. В целом дизайн A13 похож на коммуникационный процессор с шириной декодирования 7 и улучшенным множителем.
Apple, несомненно, поборется с Intel за рынок настольных ПК. Дизайн CPU, как и всего ПК, у Яблока в целом хорошо проработан. Однако важно помнить, что положение Apple отлично от остальных лицензиатов ARM. Apple проектирует чипы с тем расчётом, чтобы продавать их в продуктах по премиальной цене. Наверняка в её гаджетах будут мощные батареи и прочие свистелки-дуделки, а владелец будет знать, что его вложения окупятся.

Однако для сторонних производителей такая модель ведения бизнеса просто невозможна. Взять хотя бы AMD: ранее она не могла конкурировать с Intel, и с трудом делает это сейчас. Так собирается ли производитель процессоров на базе ARM отнять рынок ПК (или даже лэптопов) у Intel и АMD? Нет. Цены на рынке десктопов демократичны, а потребление электроэнергии не представляет проблемы. И потому зацепиться на нём тому, кто производит продукцию на базе ARM, будет непросто.
Вот где системы ARM могут действительно составить конкуренцию x86-й архитектуре, так это в мобильном секторе. Взять хотя бы Lenovo Flex 5G, который работает на однокристальной системе Snapdragon 8cх. Мы не будем приводить всех характеристик самого SoC, лишь упомянем, что он построен на микроархитектуре Cortex-A76, имеет 3 АЛУ, 2 модуля FPU/SIMD, 2 модуля загрузки/хранения, блок передачи управления. Безусловно, такие характеристики указывают на высокую производительность чипа, однако это лишь часть того, что Apple вкладывает в свой CPU следующего поколения. Четырёхъядерный Snapdragon набрал 716 баллов в однопоточных тестах. Это меньше половины того, что показал Apple A13.

И пока Intel снова косячит со своим технологическим процессом, Apple по крайней мере удаётся грамотно проектировать чипы и за счёт этого увеличивать их производительность: лицензированные ядра ARM намереваются бросить вызов Intel Core i5. В то время как AMD выжимает все соки из рабочих станций, ARM завоёвывает позиции на прибыльном HPC (вычислениях на суперкомпьютерах) и на серверном поприще. Очевидно, Intel вытесняют по всем фронтам.