Xlera8

Спекуляції для моделювання. Інновації у верифікації

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

Спекуляції для моделювання

Інновації

Вибір цього місяця - Хронос: ефективний спекулятивний паралелізм для прискорювачів. Автори представили статтю на Конференції 2020 року з архітектурної підтримки мов програмування та операційних систем і є представниками MIT.

Використання паралелізму за допомогою багатоядерних процесорів є одним із варіантів для програм, де паралелізм є самоочевидним. Інші алгоритми можуть бути не так легко розділені, але вони можуть виграти від спекулятивного виконання з використанням внутрішнього паралелізму. Зазвичай спекулятивне виконання залежить від узгодженості кешу, високі накладні витрати, особливо для моделювання. Цей метод обходить потребу в узгодженості, фізично локалізуючи виконання завдання для обчислення плиток цільовим об’єктом читання-запису, гарантуючи, що виявлення конфлікту можна виявити локально без необхідності глобального керування узгодженістю. Завдання можуть виконуватися спекулятивно паралельно; будь-який виявлений конфлікт можна розгорнути із завдання через його дочірні завдання, а потім повторно виконати без необхідності зупиняти інші потоки.

Ще один момент. Цей метод підтримує моделювання на основі затримки, на відміну від більшості методів апаратного прискорення.

Погляд Павла

Вау, який чудовий високооктановий папір від MIT! Коли мене запитують про паралельні обчислення, я одразу думаю про потоки, м’ютекси та когерентність пам’яті. Звичайно, так влаштовані сучасні багатоядерні процесори. Але це не єдиний спосіб підтримки розпаралелювання в апаратному забезпеченні.

У цьому документі пропонується альтернативна архітектура для розпаралелювання під назвою 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-потокового 2.4 ГГц Intel Xeon E5-2676v3, обраного спеціально через те, що його ціна порівнянна з системою 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 раза порівняно з версіями програмного забезпечення, завдяки більшому паралелізму та більшому використанню спекулятивного виконання. Стаття також варто прочитати для застосування до задач, не пов’язаних із моделюванням; стаття містить три приклади.

Поділитися цим дописом через:

Зв'яжіться з нами!

Привіт! Чим я можу вам допомогти?