Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.

В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас никакая, и чтобы догнать топовых производителей потребуются десятилетия (т.е. в условиях нынешней реальности никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем догнать и перегнать ведущих мировых производителей процессоров.

Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.

Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.

РЕГИСТРАЦИЯ НА ВЕБИНАР

Тестовый стенд

Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).

Схематично стенд выглядит следующим образом.

Стенд 1 e2k (Эльбрус)

Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16 G 2 шт.
• СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Стенд 2 amd64 (Intel)

Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16 G 2 шт.
• СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.

Методика тестирования

Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).

Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.

Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).

Выполняться будут основные и популярные сценарии использования СХД, в частности:

первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.

1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random

2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random

вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.

3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

третья группа тестов эмулирует работу потокового чтения (пример онлайн трансляции, восстановление резервных копий) и потоковой записи (пример видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.

5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential

Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.

Результаты тестов

Результаты тестов сведены в две таблицы.

Эльбрус 8С (СХД Аэродиск Восток 2-Э12)

Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)

Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.

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

Если говорить о случайной нагрузке небольшими блоками, то:

• с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
• с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.

В последовательной нагрузке небольшими блоками картина другая:

• и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

А вот в последовательной нагрузке большими блоками картина прямо противоположная:

• оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.

О чем это говорит? О том, что Эльбрус очень любит запись, а это, в свою очередь, говорит о том, что этот процессор будет очень полезен в задачах, где запись явно преобладает над чтением (кто сказал закон Яровой?), что также является несомненным преимуществом архитектуры e2k, и это преимущество нужно развивать.

Выводы и ближайшее будущее

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

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

При случайной записи небольшими блоками оба процессора показывают равные результаты.

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

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

• информационные системы с преобладанием операций записи;
• файловый доступ;
• онлайн-трансляции;
• видеонаблюдение;
• резервное копирование;
• медиа-контент.

Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.

Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.

Мы ожидаем выхода версии Аэродиск ВОСТОК на базе ядра 5.4 ближе к концу года, и как только работа над новой версией будет завершена, мы обновим результаты тестирования и также опубликуем их здесь.

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

Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.

Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар ОколоИТ, чтобы в прямом эфире на эти вопросы дать ответы.

В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.

РЕГИСТРАЦИЯ НА ВЕБИНАР

Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.

По этому прекрасному поводу мы в Аэродиске, предварительно обновив боевую версию встроенного Альт-Линукса в СХД ВОСТОК до ядра 5.4, повторно выполнили нагрузочное тестирование СХД, которое мы публиковали полгода назад. С прошлым отчетом можно ознакомиться по данной ссылке.

Новые тесты проводились на долгожданном ядре Линукс для e2k версии 5.4, которое появилось начале 2021 года, за что хотим сказать огромное спасибо коллективам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорину лично.

В ядре 5.4 изменений много, но нас интересуют только основные изменения с точки зрения СХД, а их можно разделить на следующие группы:

Общие обновления:

• переработан планировщик ввода-вывода, что позволяет лучше параллелить IO между дисками;
• много мелких оптимизаций под скоростные твердотельные накопители;
• и самое главное изменение новый компилятор от МЦСТ (LCC версии 1.25).

Обновления от Аэродиска:

• обновлённый таргет-драйвер, который позволяет лучше параллелить IO между процессорными ядрами;
• обновление логики работы связки ядро процессора диск для систем на Эльбрусе.

Тестовый стенд

Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.

Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
• Коммутатор FC 16G 1 шт.
• СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.

Методика тестирования

Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).

СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).

Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.

В ходе тестирование будут выполняться следующие популярные сценарии использования СХД, в частности:

Последовательная нагрузка маленькими блоками 4k

• 100%_read_4k_sequential
• 100%_write_4k_sequential

Случайная нагрузка маленькими блоками 4k

• 100%_read_4k_random
• 100%_write_4k_random

Последовательная нагрузка большими блоками 128k

• 100%_read_128k_sequential
• 100%_write_128k_sequential

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

Во всех тестах мы, чтобы не искажать результаты тестирования, намеренно отключаем RAM-кэш СХД, который используется для ускорения ввода-вывода, компрессии и дедупликации. Забежим вперед и отдельно скажем про утилизацию оперативной памяти СХД в целом (чтобы к этому вопросу больше не возвращаться). Во всех тестах RAM утилизируется практически одинаково, т.е. слабо, т.к RAM-кэш, дедуп и компрессия отключены. Вся утилизация RAM это внутренние системные операции СХД. Если бы мы включили RAM-кэш, то результаты были бы заметно лучше, но тогда тест был бы не совсем честным. При этом график утилизации оперативки мы для порядка все-равно приводим в отчете ниже.

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

Результаты тестов

Последовательная нагрузка маленькими блоками 4k

100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.

Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).
Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.

Случайная нагрузка маленькими блоками 4k

100%_read_4k_random
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_4k_random
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.

Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.

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

Последовательная нагрузка большими блоками 128k

100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД

Ввод-вывод СХД, IOPS и latency

Результат:

Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 6 мс у аналогичного процессора архитектуры x-86).

При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).

А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).

Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4

Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые

Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19

Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые

Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все таки полтора миллиона IOPS это много.

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

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

Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.

В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).

Кстати о птичках! В течение этой недели мы определимся с датами следующего технического вебинара ОколоИТ про нашу систему виртуализации АИСТ и гиперконвергентную систему vAIR, ссылка на регистрацию появится в этой статье (следите за обновлением), а также в нашем телеграмм-чате.
Ну и само собой, не можем не напомнить о бесплатных курсах по системам Аэродиск, на которые можно записаться тут.

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

Сегодняшняя статья будет посвящена сразу двум нашим любимым темам: компьютерной томографии (КТ) и отечественному процессору Эльбрус. Мы расскажем, чем отличается рентгенограмма от результатов КТ и объясним, зачем такой большой и серьезной машине, как томограф, был бы кстати специализированный вычислитель. Несмотря на то, что томографы используются уже почти 50 лет (создание первого томографа было анонсировано в 1972 году [1]), это не означает, что все проблемы KT сегодня решены. Наоборот, существует острая потребность в новых томографических алгоритмах, которые были бы быстрее и точнее используемых, позволили бы уменьшить лучевую нагрузку на объект, что, в свою очередь, существенно расширило бы и сферу применения метода КТ. Понимая все это, мы создали такое программное обеспечение Smart Tomo Engine. О нем речь пойдет ниже. Рассказав ранее о борьбе с ортотропными артефактами и об оценке эффекта чаши, в данной статье мы опишем несколько тестов, проведенных с использованием синтетических и собранных на отечественном томографе реальных томографических датасетах и покажем работу нашей программы на процессоре Эльбрус нового поколения (видео прилагается ниже). Результат работы программы приоткроет внутренний мир майского жука, причем значение слова внутренний здесь следует понимать буквально.

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

Рис. 1. Рентгенография: принципиальная схема (слева); результат рентгеновского исследования рентгенограмма (справа). Источник.

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

Рис.2. Источник.

Уточнить форму и внутреннее строение поможет метод КТ. Также как и в рентгенографии, для сбора данных КТ объект помещается между источником рентгеновского излучения и детектором, но регистрируется уже набор рентгенограмм под разными углами. Углы поворота обычно равномерно распределены в некотором интервале. Принципиальная схема измерения показана на рис. 3.

Рис. 3. Принципиальная схема томографической съемки (источник).

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

Для исследования объектов разной природы могут использоваться принципиально отличающиеся друг от друга технические решения. Так, при медицинских исследованиях гентри (подвижное устройство, содержащее систему детекторов и рентгеновских излучателей) (Рис. 4) вращается вокруг неподвижного пациента. Пространственное разрешение в таких томографах достигает 0.2-0.5 мм. Результаты КТ сохраняются в формате DICOM медицинском отраслевом стандарте, разработанном для создания, хранения, передачи цифровых медицинских изображений и сопутствующих документов обследованного пациента.

Рис. 4. Схема медицинского томографа (источник).

Для научных исследований in vitro, проводимых в лабораторных условиях, применяется другая экспериментальная схема источник и детектор неподвижны, а набор рентгенограмм получают, вращая образец. Во ФНИЦ Кристаллография и фотоника РАН (ФНИЦ КФ РАН) в лаборатории рефлектометрии и малоуглового рассеяния был сконструирован и функционирует целый комплекс лабораторных рентгеновских микротомографов. Изображение одного из созданных приборов представлено на рис. 5. В нем образец размещается на гониометре, ось которого перпендикулярна направлению зондирования. Прибор оборудован двумерным детектором. Размер пикселя 9 мкм, поле зрения детектора 24 на 36 мм. В данном приборе реализована возможность использования для зондирования как полихроматического, так и монохроматического излучения. Это позволяет не только повышать качество реконструируемых изображений, но и получать дополнительную информацию об элементном составе изучаемых объектов. Разработка собственных томографов позволяет получить доступ к экспериментальным данным (рентгенограммам) и параметрам работы всех узлов томографа, а, значит, позволяет оптимизировать протоколы измерений в зависимости от поставленных задач.

Рис. 5. Фотография лабораторного микротомографа ФНИЦ КФ РАН.

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

Если зондирование проводится с использованием параллельного пучка, то задачу трехмерной реконструкции можно решить, восстановив серию двумерных сечений объекта. Для реконструкции одного сечения нет необходимости использовать полный набор проекций. Требуется лишь одна строка фиксированного номера от каждой угловой проекции. Все эти строки соответствуют одному горизонтальному сечению восстанавливаемого 3D распределения, которому можно приписать тот же номер. На рис. 6 слева представлено изображение, собранное из таких строк. Горизонтальная ось отвечает за номер столбца детектора, вертикальная за номер углового поворота. Справа на рис. 6 приведен результат реконструкции сечения.

Рис 6. Синограмма грудной клетки (слева); результат КТ сечение 3D изображения (справа).

Если для томографического зондирования используется монохроматическое рентгеновское излучение, то, опираясь на закон Бугера-Ламберта-Бера, задачу реконструкции можно свести к задаче обращения преобразования Радона. Преобразование Радона это интегральное преобразование, которое связывает значения функции со значениями ее интегралов по всевозможным прямым. Процедура обращения это восстановление неизвестной функции по известным значениям ее интегралов по прямым. Подынтегральная функция, которую и надо восстановить это распределение линейного коэффициента ослабления монохроматического рентгеновского излучения в объеме образца. Свойство обратимости преобразования Радона гарантирует точное восстановление неизвестной частотно-ограниченной функции при наличии достаточного числа интегралов по регулярно расположенным прямым. Это свойство использует алгоритм свертки и обратной проекции (Filtered Back Projection, FBP), реализованный в большинстве современных серийных томографов. Он состоит из двух шагов. Первый шаг линейная фильтрация зарегистрированных изображений. Второй шаг обратное проецирование, т.е. равномерное размазывание каждой полученной на предыдущем шаге одномерной функции по соответствующему направлению на все двумерное изображение с последующей суммацией. Результат работы алгоритма восстановленное пространственное распределение линейного коэффициента ослабления рентгеновского излучения заданной энергии. Если зондирование ведется не параллельным, а конусным пучком, то послойную реконструкцию организовать не удается, и приходится использовать более сложные алгоритмы. Об алгоритмах трехмерной реконструкции, например об алгоритме Фельдкампа, мы напишем как-нибудь в следующий раз. А теперь перейдем, наконец, к описанию нашего ПО.

Smart Tomo Engine

Сердцем Smart Tomo Engine служит библиотека томографической реконструкции, предоставляющая через API следующие функции: чтение томографических изображений (проекций); собственно томографическую реконструкцию (предлагается на выбор три алгоритма) и сохранение результатов (предлагаемые форматы: DICOM, PNG). Программный продукт дополнительно включает в себя графический интерфейс пользователя, обеспечивающий двухмерную визуализацию томографических изображений и результатов реконструкции. Основное назначение программного продукта выполнение реконструкции трехмерного цифрового изображения объекта по набору его трансмиссионных томографических изображений в рентгеновском диапазоне.

Для послойной двумерной реконструкции реализованы следующие алгоритмы:

• FBP Filtered Back Projection. Классический метод томографической реконструкции, комбинирующий обратное проецирование и линейную фильтрацию. Вычислительная сложность O(n³). Подробнее о методе можно почитать в [2]).
• DFR Direct Fourier Reconstruction. Алгоритм работает в частотной области и использует быстрое преобразование Фурье для фильтрации и обратного проецирования [3]. Вычислительная сложность O(n² log n) операций умножений.
• HFBP Hough FBP. Алгоритм реконструкции, который разработали наши ученые. Для обратного проецирования используется алгоритм Брейди быстрого вычисления преобразования Хафа, а для ускорения линейной фильтрации применяется метод Дериша [4,5]. Вычислительная сложность по сравнению с DFR снижена до O(n²) операций умножения (при O(n² log n) операций сложения).

Тестирование на Эльбрус

Мы протестировали наше ПО на отечественной платформе. Тестирование проводилось на машинах Эльбрус-401, Эльбрус-804 и Эльбрус-801СВ. Эльбрус-401 это рабочая станция с процессором Эльбрус-4С, Эльбрус-804 сервер с 4 процессорами Эльбрус-8С. (Мы уже тестировали на них наше ПО, разработанное для решения других задач, и почитать про это можно, например, тут.) Эльбрус-801СВ это новейшая разработка МЦСТ: рабочая станция с процессором Эльбрус-8СВ. Про принципиальные отличия Эльбрусов разных поколений нам рассказали коллеги из МЦСТ: Эльбрус-4С первый процессор, массово поставленный на рынок. Имеет 4 ядра с частотой 750800 МГЦ, 3 канала памяти DDR3-1600. Эльбрус-8С 8 ядер, частота 1.21.3 ГГц, 4 канала памяти DDR3-1600, и при этом в каждом ядре в 1.5 раза больше исполнительных устройств (ALU) для вычислений с плавающей запятой. Эльбрус-8СВ дальнейшее улучшение: 8 ядер с частотой 1.5 ГГц, память DDR4-2400 и ещё в 2 раза больше ALU. Эльбрус-8СВ лучше работает с невыровненными данными, и в нём масса других небольших улучшений по сравнению с Эльбрус-8С.

Характеристики процессоров представлены в таблице 1.

Таблица 1. Технические характеристик использованных процессоров.

Про оптимизацию на платформе Эльбрус мы уже писали тут и тут, поэтому не будем повторяться. Здесь мы не делали ничего сверхъестественного:

• использовали оптимизированную библиотеку EML (геометрические преобразования изображения (напр., аффинное преобразование), арифметические операции и т.д.);
• использовали интринсики там, где EML не смогла нам помочь; однако на Эльбрус-8СВ SIMD стал 128-битным, и мы не успели полностью на него перейти, поэтому интринсики все еще работали с 64-битными векторами.

Для тестирования Smart Tomo Engine мы собрали два датасета: с синтетическими и реальными данными. Синтетический датасет Шепп-Логан 3D был получен методом математического моделирования. Проекции рассчитаны послойно от трехмерного фантома Шеппа-Логана с использованием веерной схемы. Срез представлен на рис. 8 слева. Размер изображения фантома 511х511х511. Проекции рассчитаны для 420 углов, равномерно распределенных от 0.5 до 210 градусов. В эксперименте на вход Smart Tomo Engine подавалось 511 синограмм (изображение одной из них приведено на рис. 7 справа) размером 511х420. Выход 511 реконструированных слоев, размер каждого слоя 511х511. Размер фантома примерно соответствует изображениям, получаемым на современных стоматологических томографах: максимальный размер зоны сканирования челюсти обычно составляет 16 см, заявляемое производителями пространственное разрешение 0.3-0.4 мм. В таком случае размер регистрируемой проекции составит примерно 500х500 пикселей.

Рис. 7. Слева срез трехмерного фантома Шеппа-Логана, справа синограмма центрального слоя.

Реальные томографические данные (датасет "Майский жук") были собраны на микротомографе ФНИЦ КФ РАН, предназначенном для проведения научных исследований. Размер пикселя использованного детектора составлял 9 микрон. Экспериментальный образец высушенный майский жук. Было снято 400 проекций в параллельной схеме. Образец, закрепленный на держателе, поворачивался на углы в диапазоне от 0.5 до 200 градусов с шагом 0.5 градусов. Время измерения одной проекции составило 5 секунд. Размер измеренной проекции 1261х1175. Вход для Smart Tomo Engine 1261 синограмма размером 1175х400, выход 1261 восстановленный слой размера 1175х1175.

А теперь самое интересное результаты замеров и выводы

На этих датасетах мы провели замеры скорости выполнения реализованных нами алгоритмов реконструкции: FBP, DFR и HFBP. Время работы алгоритмов приведено в таблице 2. Замеры проводились на 5 машинах: Эльбрусе-401, Эльбрусе-804, Эльбрусе-801СВ, AMD Ryzen 7 2700 и AMD Ryzen Threadripper 3970X. Для каждой машины в таблице указано число процессоров, число физических ядер и максимальное число одновременно выполняемых потоков (указано в скобках). Замеры скорости реконструкции проводились в двух режимах: однопоточном (1П) и многопоточном (МП), реализованном с помощью библиотеки tbb версии 2017 update 7.

Таблица 2. Замеры времени работы программы, сек.

Анализируя полученные результаты, прежде всего отметим, что в многопоточном режиме 4-процессорный сервер Эльбрус-804 затратил на реконструкцию 511 слоев фантома алгоритмом HFBP 19 секунд, то есть каждый слой был восстановлен за 0.037 секунды, а послойная частота составила 26.8 слоев в секунду (26.8 ips). Чтобы понять, высокая это частота или низкая, приведем следующую оценку. За секунду гентри 16-срезового кардиологического томографа совершает чуть меньше двух оборотов, регистрируя порядка 30 синограмм. Мы восстанавливаем 26.8 слоя в секунду, т.е. проводим реконструкцию практически в режиме реального времени. Таким образом, проведение реконструкции с использованием российской платформы удовлетворяет требованиям по скорости, предъявляемым в кардиологии, где основным реперным параметром является период сокращения сердца, который в среднем составляет одну секунду.

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

Для научных исследований таких жестких ограничений по времени нет, но выше требования к пространственному разрешению. Поэтому размеры восстанавливаемых сечений больше. При работе с датасетом, полученным с лабораторного микротомографа, на реконструкцию 1261 слоя потребовалось 189 секунды в многопоточном режиме (6.7 ips). Измерение входных данных на лабораторном томографе заняло 2000 секунд, а 3 с небольшим минуты, которые потребовались на реконструкцию всех слоев при использовании Smart Tomo Engine на Эльбрусе-804, соответствуют 10% этого времени. Ещё быстрее будет работать 4-процессорный сервер с процессором Эльбрус-8СВ, который в МЦСТ уже разработали и скоро планируют довести до готовности к серийному производству.

В полученных результатах интересны и сами по себе соотношения производительностей разных платформ на каждом из алгоритмов, с учётом тактовой частоты ядер. На FBP отставание Эльбрусов умеренное, и при нормировании относительно тактовой частоты получаются близкие результаты. Но на алгоритмах DFR и HFBP отставание всех Эльбрусов от платформы х86 значительно больше. Почему? Ответ кроется в недостаточной оптимизации нашего ПО под платформу Эльбрус, все же на x86_64 мы потратили 5 лет, а под Эльбрус, особенно под 8СВ, большую часть программ и алгоритмов мы еще вовсе не оптимизировали.

В ближайшее время мы планируем ускорения в трех направлениях. Первое, что мы сделаем, это оптимизируем наши вычисления на интринсиках. Сейчас наши вычисления сделаны для 64-битного SIMD, а у Эльбрус-8СВ SIMD стал 128-битным. Второе ускорение будет сделано командой МЦСТ. Уже сейчас ведутся разработки для поддержки двумерного и одномерного дискретного преобразования Фурье для входного вектора, размер которого не равен степени двойки. И так как пока его нет, мы пользовались библиотекой ffts, с некоторой доработкой как под Эльбрус, так и под х86.

Для оценки возможного ускорения нашей программы мы сделали замеры времени выполнения дискретного преобразования Фурье на процессоре Эльбрус-8СВ для входной комплексной матрицы размером 512 на 512. Неоптимизированная на Эльбрус библиотека ffts выполнила эту операцию за 27 миллисекунд, а eml справилась всего за 5.5. Мы ускорили, как могли, ffts с помощью вызовов EML в 2 раза, и в таблице 2 замеры проведены уже с учётом этой оптимизации. Таким образом, если оптимизацию проводить с той тщательностью, с которой сделана библиотека eml, то алгоритм DFR на Эльбрусе все еще может быть ускорен почти в 2,5 раза.

Третье, но не менее важное ускорение относится к алгоритму HFBP, который основан на применении преобразования Хафа. Данное преобразование также пока еще не представлено в библиотеке eml, а наша версия оптимизирована только с помощью векторных операций. И, так как данный алгоритм вычислительно эффективнее, чем DFR, наши теоретические выводы и оптимизированная под платформу x86_64 версия это показывают, то данный алгоритм тоже может быть ускорен еще в несколько раз. О результатах этих оптимизаций мы обязательно расскажем в следующий раз.

А вот и обещанное видео с работой программы на Эльбрус-8СВ.

Вот такой внутренний мир майского жука у нас получился.

Заключение

В статье мы представили вам нашу новую разработку программное обеспечение для томографической реконструкции Smart Tomo Engine, которое:

• включает в себя инновационный алгоритм HFBP, стабильно обгоняющий по производительности лидера прошлых лет DFR;
• поддерживает операционные системы: ОС Эльбрус, MS Windows, macOS, различные дистрибутивы Linux;
• поддерживает процессорные архитектуры: Эльбрус, x86, x86_64;
• является полностью отечественной разработкой;
• в составе программно-аппаратного комплекса на платформе Эльбрус подходит для медицинских и промышленных сканеров всех поколений, для новейших нано-томографов (приборов, которые реконструируют объекты с субмикронным разрешением), а также синхротронных центров.

Ну а главный результат этой статьи заключается в том, что комбинации отечественного процессора Эльбрус и Smart Tomo Engine достаточно для томографии в реальном времени, даже без дополнительных ускорений, работа над которыми уже ведется!

P.S. А еще мы не смогли удержаться и замерили производительность UNetа на Эльбрусе. UNet популярная нейросетевая архитектура для решения задач сегментации. Изначально Unet была разработана для решения задачи сегментации в медицине, а по обработанным этим нейросетевым подходом томографическим снимкам теперь определяют патологии и новообразования. Вычислительно тяжелые части нейронных сетей у нас реализованы на EML, а EML оптимизировано под разные поколения Эльбрусов, поэтому на таком замере можно лучше оценить реальную производительность разных процессоров. Замеры выполнены для одного ядра, без распараллеливания, чтобы не оглядываться на число ядер.

Обратите внимание на последние две цифры. Круто?.. А наши исследования продолжаются...