Кслера8

Спекуляция для моделирования. Инновации в проверке

Это интересная идея, использующая спекулятивный параллелизм с аппаратной поддержкой для ускорения симуляции, с изюминкой, требующей специального оборудования. Пол Каннингем (старший вице-президент/генеральный менеджер, отдел проверки в Cadence), Рауль Кампосано (Silicon Catalyst, предприниматель, бывший технический директор Synopsys, а теперь технический директор Silvaco) и я продолжаем нашу серию статей об исследовательских идеях. Как всегда, отзывы приветствуются.

Спекуляция для моделирования

Инновация

Выбор в этом месяце Chronos: эффективный спекулятивный параллелизм для ускорителей. Авторы представили документ на конференции 2020 года по архитектурной поддержке языков программирования и операционных систем из Массачусетского технологического института.

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

Еще одно замечание здесь. Этот метод поддерживает моделирование на основе задержки, в отличие от большинства методов аппаратного ускорения.

Взгляд Павла

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

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

Задачи в очереди передаются нескольким процессорным элементам (PE) параллельно, что означает, что Chronos спекулятивно выполняет будущие задачи до того, как текущая задача будет завершена. Если текущая задача делает недействительными какие-либо спекулятивно выполненные будущие задачи, то действия этих будущих задач «отменяются» и они повторно ставятся в очередь. Корректно реализовать эту концепцию на аппаратном уровне непросто, но для внешнего пользователя это красиво: вы просто кодируете свой алгоритм так, как если бы очередь задач выполнялась последовательно на одном PE. Не нужно кодировать какие-либо мьютексы или беспокоиться о взаимоблокировке.

Авторы реализуют Chronos в SystemVerilog и компилируют его в FPGA. Большая часть статьи посвящена объяснению того, как они реализовали очередь задач и любое необходимое аппаратное развертывание для максимальной эффективности. Chronos тестируется на четырех алгоритмах, хорошо подходящих для архитектуры, основанной на очереди задач. Каждый алгоритм реализуется двумя способами: во-первых, с использованием выделенного PE для конкретного алгоритма, а во-вторых, с использованием готового 32-разрядного встроенного ЦП RISC-V с открытым исходным кодом в качестве PE. Затем производительность Chronos сравнивается с многопоточными программными реализациями алгоритмов, работающими на сервере Intel Xeon с ценой, аналогичной FPGA, используемой для Chronos. Результаты впечатляют: Chronos масштабируется в 3–15 раз лучше, чем при использовании сервера Xeon. Однако, сравнивая Таблицу 3 с Рисунком 14, я немного беспокоюсь о том, что большая часть этих преимуществ была достигнута благодаря специфичным для алгоритма PE, а не самой архитектуре Chronos.

Учитывая, что это блог о проверке, я, естественно, сосредоточился на тесте моделирования на уровне ворот. Индустрия EDA вложила значительные средства в попытки распараллелить логическое моделирование, и оказалось, что трудно увидеть большие выгоды, кроме нескольких конкретных случаев использования. Это в основном связано с тем, что в производительности большинства реальных симуляций преобладают инструкции загрузки/сохранения, отсутствующие в кэше L3 и направляющиеся в DRAM. В этой статье тестируется только один тестовый пример, и это крошечный 32-битный сумматор для сохранения переноса. Если вы читаете этот блог и хотели бы провести более тщательный бенчмаркинг, дайте мне знать — если Chronos действительно сможет хорошо масштабироваться в реальных симуляторах, это будет иметь огромную коммерческую ценность!

Взгляд Рауля

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

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

Ассоциация Chronos Система была реализована в среде AWS FPGA как система с 16 плитками, каждая из которых имеет 4 элемента обработки для конкретных приложений (PE), работающих на частоте 125 МГц. Эта система сравнивается с базовой системой, состоящей из 20-ядерного/40-потокового процессора Intel Xeon E2.4-5v2676 с частотой 3 ГГц, который был выбран специально потому, что его цена сравнима с FPGA (около 2 долларов США в час). Выполняя одну задачу на одном PE, Chronos работает в 2.45 раза быстрее, чем базовый уровень. По мере увеличения количества одновременных задач реализация Chronos масштабируется до относительного ускорения в 44.9x на 8 тайлах, что соответствует ускорению в 15.3x по сравнению с реализацией CPU. Они также сравнили реализацию, основанную на RISC-V общего назначения, а не на PE для конкретных приложений; PE были в 5 раз быстрее, чем RISC-V.

Я нашел документ впечатляющим, потому что он охватывает все: от концепции до определения модели выполнения SLOT до реализации аппаратного обеспечения и подробного сравнения с традиционным процессором Xeon для 4 приложений. Усилия значительные, Chronos составляет более 20,000 5.4 строк SystemVerilog. Результатом является среднее (для 4 приложений) ускорение в XNUMX раза по сравнению с программно-параллельными версиями из-за большего параллелизма и большего использования спекулятивного выполнения. Бумагу также стоит прочитать для применения к задачам, не связанным с моделированием; статья включает три примера.

Поделитесь этим постом через:

Чат с нами

Всем привет! Могу я чем-нибудь помочь?