Как стать автором
Обновить

Разработка и тестирование на платформах Эльбрус программы для томографической реконструкции Smart Tomo Engine (+2 видео)

Время на прочтение 14 мин
Количество просмотров 10K
Всего голосов 29: ↑27 и ↓2 +25
Комментарии 31

Комментарии 31

Здорово. А для задачи восстановления проекционных изображений могут ли использоваться мощности графических карт? Вроде бы есть библиотеки для FFT. developer.nvidia.com/cufft
Реализации томографической реконструкции на видеокартах, конечно, уже существуют. И на суперкомпьютерах — тоже. Однако цель нашей статьи — рассказать об алгоритмах, обеспечивающих восстановление в реальном времени на процессорах общего назначения.
А зачем ограничиваться процессорами общего назначения, если есть видеокарты, которые скорее всего намного лучше подходят для этих задач?
Решая задачу с ограничениями, инженер создает продукт, обладающий конкурентными преимуществами. Инженеры производителей видеокарт работают в условиях жестких ограничений и упаковывают громадное количество АЛУ в единицу площади кремниевой пластины. Их бизнес процветает. Мы работаем с другим типом ограничений — наши продукты должны работать, по возможности, на любых платформах. Это тоже действует. А работая без ограничений ничего инновационного создать нельзя.
Не понимаю связь «любой платформы» с «только на CPU».
Мне как не сведующему в томографии человеку кажется, что если у вас вычислительно-интенсивная задача и требование скорости, то логично делать рассчеты на видеокартах. Я не вижу при этом чтобы это накладывало принципиальные ограничения на платформу, даже наоборот, кажется что будь все это сделано на OpenCL можно было бы поддерживать еще большее их число и сразу оптимально (просто требовать наличия поддержки OpenCL платформой или наличие PCIe шины куда можно воткнуть какой-нибудь FirePro) без необходимости делать архитектурно-специфические оптимизации. Но да, придется делать оптимизации под различные видеокарты, что тоже в общем-то ограничение, просто другое.
В ужасе мы перечитали статью и комментарии. И с облегчением обнаружили, что нигде не было заявлено про «только на CPU». Мы работаем и на GPU. Наши алгоритмы хорошо параллелизуются на векторных архитектурах. Но писать тут не о чем — это технологический мэйнстрим. Вот когда появится отечественный GPU — будет, о чем написать. Или вот: мы планируем освоить еще и NPU. Как осилим — обязательно напишем, это должно быть любопытно. А на OpenCL мы возлагали очень большие надежды. Думали, что можно будет одинаково абстрагировать CPU и GPU. Но в прошлом, 2019 году он выглядел как дохлая лошадь. В этом году движение возобновилось, и мы внимательно наблюдаем, появятся ли стабильные реализации на достаточном числе платформ. Тогда и решим.
Пока нет, но в ближайших планах научится с ним работать в наших задачах и не только по томографии.
Мы работаем и на GPU.

Тогда непонятно, как можно хвалиться визуализацией, которая работает несколько секунд (второе видео в материале) вместо реального времени на GPU.
Для сравнения, 2015-й год и слабая ноутбучная видеокарта:
www.youtube.com/watch?v=d9I9OoqHK2o
Присланное видео и наша визуализация — это не об одном и том же. Цель нашей визуализации — мониторинг процесса реконструкции (показан на первом ролике). Цель присланного видео — показать возможности программы визуализации.
Второй же наш ролик сделан для красивой демонстрации результата реконструкции, полученного с помощью Smart Tomo Engine, скорость визуализации задана из наших представлений о прекрасном и наглядности результата.
Я понимаю, что это две отдельные задачи, реконструкция и визуализация. Я хотел сказать (и подтвердить предположение Civil), что GPU здесь в целом подходят лучше, так как могут делать и реконструкцию, и визуализацию в реальном времени.
Сравнить скорость отрисовки на GPU и CPU можно например в этой софтине:
ngavrilov.ru/invols/index.php?id=Download
Для отрисовки, однозначно, лучше всего подходят GPU — они для этого созданы. А вот для вычислений все зависит от алгоритмов(упс) и часть алгоритмов хорошо «ложится» на GPU, а многие совсем нет. В своих работах мы используем ресурсы GPU, по мере необходимости и если это эффективно. Но ориентироваться только на них мы считаем глупостью.
часть алгоритмов хорошо «ложится» на GPU, а многие совсем нет.
Согласен, но сложные алгоритмы часто появляются при попытках оптимизировать под CPU — а если закинуть ту же задачу на GPU, то может оказаться, что и брут-форс вывозит.

Отрисовка КТ на GPU, кстати, совсем не похожа на полигональную графику в играх, так что «для этого созданы» не совсем верно.

Если к 2022 году Эльбрусы 16С доберутся до массового корпоративного пользователя это будет большая победа для всей отечественной ИТ индустрии.

Я как-то удивился 28 нм техпроцессу. Думал там все на 65 застряло.
16С — 16 нм и уже начата разработка 32С он будет 7 нм.
А откуда станки на 7нм? Там же вроде бы лазер напиливает кремний, и требования к такой точности лазера, как я слышал, повышает стоимость оборудования просто неимоверно и даже у гигантов это очень серьезные вложения.
TSMC. Они производят процессоры для МЦСТ
Если вы про 16С, то он выполнен по 16 нм техпроцессу.
На Тайване, где производятся Эльбрусы, есть любые техпроцессы. А в России производство застряло даже не на 65, а на 90.
Вы пытались разобраться почему у вас в последней таблице данные выглядят хорошими, но когда переходите к общему времени работы приложения 1 ядро Ryzen 2700 показывает себя лучше, чем 8 ядер Эльбрус-8С и 8СВ?

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

Потому что в общем смысле вопросы к статье те же самые что в случаи СХД Аеродиск недавно. Абсолютно непонятно почему цифры отличаются.
Еще в конце статьи описано что под Эльбрус код оптимизирован, а под x86 насколько глубоко вы закапывались в оптимизацию?
Последняя таблица — про нейросети, реализованные на математических библиотеках, поставляемых с Эльбрусами. Это оценка того, чего можно достичь, когда все более-менее оптимизировано. А остальные таблицы — они по теме реконструкции, и нейросеть вовсе не является частью этой программы, поэтому говорить об «общем времени» тут не корректно. При реконструкции мы явно пока загружаем не все ресурсы процессора и не достигли пиковой производительности. Есть, над чем работать.

Что касается x86 (и ARM), то мы занимаемся оптимизацией под эти архитектуры уже 10 лет. В наших продуктах математика вынесена в отдельный слой, поэтому новые оптимизации обычно воздействуют на быстродействие всех подсистем. В этой области мы зарабатываем деньги на высококонкурентном рынке, а быстродействие и энергоэффективность — важная составляющая облика наших продуктов. Нет оснований полагать, что в томографии мы что-то прошляпили на этих платформах.

Что касается масштабируемости теста, то мы опубликовали данные только после того, как расследовали все странности. Не видим, что мы куда-либо «упираемся». Сравнения с другими процессорами мы регулярно проводим (строго говоря, AMD Ryzen 7 — один из этих «других»), но целью нашей статьи было сравниться с топовым чипом.
Просто из статьи это непонятно (возможно нужны какие-то знания о архитектуре ваших решений), а значит оценить разумность полученных данных сложно, если вообще возможно.
Дело в том, что на хабре в целом общетехнические статьи и я как не сведующий в томографии пытаюсь по Вашей статье сравнить Эльбрус и x86, вижу сильно разные результаты в разных таблицах без особого количества вводных и не могу сделать по ней никаких выводов для себя.
Непонятное мы готовы разъяснять, для этого и предназначен механизм комментариев. Что же касается вашей задачи, то решить ее можете только вы. Разработав ту методику, которая подходит под ваш запрос. Сравниваются ли подходы VLIW против CISC? Две архитектуры без учета частоты и тех. процесса? Два конкретных чипа? Системы, оснащенные штатными компиляторами? Ответы будут разными. Статья, как можно понять из заголовка, для поставленной вами задачи вряд ли подходит. Но, надеемся, будет одним из ориентиров. Мы готовы уточнять вводные, отвечать на вопросы. Но уж точно мы не можем за вас сделать выводы в неизвестной нам задаче.
Какой объем данных получился при исследовании майского жука?
Объем измеренных экспериментальных данных составил 1.1 Гб. объем реконструированного изображения — 872 Мб.
Какой максимальный объём данных(необходимый и достаточный) удавалось получить? Что это было? Какое время ушло на реконструкцию?
Самое печальное, что обычно сырые данные никто не хранит — получают набор срезов и реконструкций, занимающих такой же объём, а сырые данные удаляют.
Вместо этого можно было бы хранить сжатые сырые данные (а они прекрасно жмутся) и набор инструкций по получению нужных срезов, этакий скрипт — данные, ядро восстановления, участок (FOV), направление, шаг, профиль для криволинейного среза и т.д.
В результате на выходе получались бы те же самые изображения, но в любой момент можно было бы добавить любую новую реконструкцию — с другим ядром свёртки, другим FOV, более мелким шагом и т.д.
Время же на получение новой реконструкции пренебрежимо мало, особенно если её делать на GPU — объём сырых данных вполне умещается в видеопамять.
Вы абсолютно правы! Кроме прочего, мы готовим к публикации расширение формата DICOM-CT-PD, позволяющего хранение сырых данных и необходимой для реконструкции мета-информации. Что касается мгновенности обработки, то это верно только для линейных моделей реконструкции. «Безартефактные» алгоритмы бывают очень ресурсоемкими.

Коллеги, как писал в своей статье — важно помимо марки процессора явно указывать релиз ОС и версии пакетов, использованных при обработке.
На Эльбрусе 8С разница может быть до 10 раз, формально в одной и той же версии библиотеки. В нашем случае это была OpenCV, завязанная на EML

Мы не используем внешних пакетов кроме EML, а версия компилятора указана в табличке, как и версия ОС. Версию EML попробуем уточнить, но мы всегда используем рекомендованную МЦСТ под тип процессора. А скорость — коллеги работают над оптимизацией своих библиотек, что похвально.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий