Исследования › Гибридный реконфигурируемый вычислитель › Инженерная методика адаптации приложения к гибридному кластеру с ускорителями на ПЛИС.

Часть 10. Краткое обсуждение результатов и основные выводы.

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

Начнем с того, что нам удалось получить векторно - конвейерную схему удовлетворительного качества. Именно удовлетворительного, а не отличного: как показывают расчеты, приведенные в предыдущем разделе, отличная схема 16-ниточного конвейера должна была бы тратить на обработку данных в нашем тесте не 2.75, а примерно 1.6 секунды. Этого можно было бы достичь, построив не цикл поочередного запуска конвейеров обработки отдельных строк сетки, а один, непрерывный конвейер обработки всей сетки. Такие схемы пишутся, и довольно компактно, например, на языке Автокод Stream, но это, для многих разработчиков, точно не проще и не быстрее, чем все то, что мы описали в предыдущем разделе. Наблюдавшаяся в данном случае потеря быстродействия - менее чем в два раза по сравнению с более трудоемкой и/или требующей более высокой квалификации исполнителя технологией - является приемлемой во многих случаях. Так что в принципе рассмотренная технология применима. Вопрос в том, для каких задач и при каких условиях.

Проще начать с того, для чего эта технология категорически НЕ применима. Она совершенно не годится для переноса сравнительно больших (тысячи строк исходного текста) программ вычислительного характера на гибридно - параллельный суперкомпьютер в «почти автоматическом» режиме, то есть без глубокой смысловой переработки исходного текста, и/или силами программиста, не знакомого с основами вычислительной схемотехники. Многие прикладные программисты полагают, что, если уж тексты всех вычислительных процедур записаны на C, то влияние того, КАК ИМЕННО они записаны, не должно быть критическим. Пусть замедление составит, по сравнению с идеальным вариантом, раза в два, а ускорение по сравнению с программной реализацией будет все равно заметным, - думают они. Мы только что показали на неправдоподобно простом примере, что замедление по причине не совсем правильной записи текста сопроцессора легко может быть более чем в сотню раз. В этом смысле наш вариант гибридно - параллельного суперкомпьютера - не более чем «экстремальная» версия более распространенных и привычных гибридно - параллельных машин на GPGPU, для которых структурная переработка программы и правильная запись вычислений для сопроцессора также очень важны, но эффект от их недостатка (и даже полного отсутствия) все же не является таким ошеломляющим.

Выше нам удалось показать, что точно таким же «пороговым» свойством обладает в нашем случае эффект наличия у прикладного программиста профессиональной схемотехнической подготовки. Главная проблема довольно многословного и причудливого текста на C, который нам в итоге пришлось написать, вовсе не в его причудливости как таковой. Она - в том, что понять проблему и пути ее исправления может только специалист - схемотехник, мысленно попытавшись построить вручную неправильный вариант схемы, и поняв, на основании своего практического опыта, насколько это тяжелая, неразрешимая задача. Можно, конечно, допустить, что в компиляторе просто не хватает прагмы, явно говорящей о делимости приращения индекса на заданное число, а «наивному» программисту можно столь же просто сообщить недостающие сведения в качестве «заклинания», которое следует выучить и применять, не задумываясь. К сожалению, многолетний опыт борьбы с похожими проблемами, уже не раз встававшими на пути попыток частичной автоматизации тех или иных видов параллельного программирования, показывает, что следом за этой критически недостающей прагмой выявится еще одна, недостающая не менее критически, потом — еще, и конца им не будет.

Словом, рассмотренная нами технология СОВСЕМ НЕ ГОДИТСЯ для снижения барьера вхождения в мир гибридно - параллельных вычислений на ПЛИС, по той простой причине, что она его практически не снижает. По крайней мере, не снижает в том смысле, в каком это склонен ждать от нее «наивный» прикладной программист.

Рассмотренная нами технология может применяться в качестве инструмента для ускорения и упрощения прототипирования, разработки опытных и модельных версий гибридно - параллельных приложений вычислительного характера, при условии выполнения этих работ грамотным системным инженером, знающим на практике хотя бы азы вычислительной схемотехники и техники построения компиляторов. Использование технологии синтеза текстов на C++ может носить инкрементальный характер. Сложная, описываемая несколькими функциями, вызывающими друг друга, схема первоначально реализуется на аннотированном C++. Затем в ней выделяются критические фрагменты, с наиболее локализованными вычислениями, и наибольшими шансами построения конвейера, и они поэтапно переписываются на Автокоде Stream, VHDL или Verilog'е. Предусмотренный в рассмотренном нами трансляторе протокол вызова функции является по умолчанию асинхронным, то есть компонент, соответствующий функции, вызывается с проверкой готовности того, что он уже отработал. Также поддерживается многократный асинхронный вызов в режиме конвейера. Все это делает возможной замену вызываемой функции, оттранслированной с C++, вариантом, оттранслированным с другого языка, на уровне VHDL/Verilog, поскольку сохранения конкретного значения времени срабатывания при замене не потребуется. Предложенный в настоящем документе порядок разработки позволит при этом постоянно иметь возможность отката к ближайшей программно реализованной модели, что должно упростить и ускорить отладку, упорядочить внесение изменений. Для техники поэтапной замены функций, написанных на аннотированном C++, их функциональными аналогами на других языках, потребуется инструмент генерации «связок», вроде упомянутого в Разделе 7 препроцессора для обработки псевдокомментариев, описывающих интерфейсную часть схемы. Кроме того, понадобится проработанная на конкретном примере и подробно описанная инженерная методика, похожая на настоящий документ.

Сказанное здесь вынуждает нас задать самим себе еще один, завершающий вопрос. Если, как мы показали на конкретном (и очень простом) примере, объем подготовительной работы с текстом программы очень велик, а потребная квалификация специалиста, выполняющего перенос, глубоко профессиональна и много выше средней, то не проще ли уговорить этого специалиста освоить нормальный, подходящий для описания схем инструмент, чем исполнять «танцы с бубном», подробно описанные в Разделе 9? Полагаем, что предложенная только что технология инкрементальной разработки, с поэтапной, выборочной заменой текстов на аннотированном C++ текстами на «нормальных» схемотехнических языках, скорее всего, все-таки оправдает себя во многих случаях, и, быть может, даже позволит несколько расширить, пусть даже и не за счет «наивных» прикладных программистов, круг разработчиков схем вычислительного характера.