2013-08-02 2 views
0

У меня есть код, написанный в старом стиле Fortran 95 для моделирования сжигания. Одна из особенностей этой проблемы заключается в том, что приходится решать жесткую систему ОДУ для учета влияния химических реакций. Для этой пурпуры я использую библиотеку Fortran SLATEC, которая также довольно старая. Процедура решения прямо вперед, один просто нужно вызвать подпрограмму ddriv3 в каждой ячейке расчетной области, так что выглядит так:Slatec + CUDA Fortran

do i = 1,Number_of_cells ! Number of cells is about 2000 
call ddriv3(...)  ! All calls are independent on cell number i 
end do 

ddriv3 является довольно сложным и использует множество других функций библиотеки.

Есть ли способ получить преимущество от CUDA Fortran, не искав какую-то другую библиотеку для этой цели? Если я просто запускаю это как «параллельный цикл», это будет эффективно, или может быть, есть другой способ?

Прошу прощения за такой вопрос, который недвусмысленно возникает из наиболее очевидного ответа: «Почему бы вам не попробовать и не узнать об этом сами?», Но я в очень стесненных условиях времени. У меня нет никакого опыта в CUDA, и я просто хочу выбрать самый правильный и самый простой способ начать.

Заранее благодарен!

+0

Это зависит от структуры подпрограммы, задействованных алгоритмов и требуемых передач memz. –

ответ

1

Вы не сможете использовать или распараллелить вызов ddriv3 без каких-либо усилий. Ваше использование фразы «параллельный цикл» подсказывает мне, что вы можете думать о использовании OpenACC directives with Fortran, в отличие от CUDA Fortran, но общий ответ ничем не отличается в любом случае.

Звонок ddriv3, являющийся частью библиотеки Fortran (который предположительно скомпилирован для использования в x86), не может быть непосредственно использован в CUDA Fortran (т.е. с использованием ядер ядра CUDA в Fortran) или в OpenACC Fortran по существу по той же причине : Код библиотеки - код x86 и не может использоваться на графическом процессоре.

Поскольку предположительно у вас может быть доступ к исходной реализации ddriv3, возможно, вам удастся извлечь исходный код и работать над созданием его версии CUDA (или версии, которую OpenACC не будет подавлять), но если он использует многие другие библиотечные процедуры, это может означать, что вам нужно создать CUDA (или прямой источник Fortran для OpenACC) для каждого из этих вызовов библиотеки. Если у вас нет опыта работы с CUDA, это может быть не то, что вы хотите сделать (я не знаю). Если вы пойдет по этому пути, это, конечно, означало бы больше узнать о CUDA или, по крайней мере, преобразовать вызовы библиотеки на прямые Источник Fortran (для версии OpenACC).

Для вышеуказанных причин имеет смысл исследовать, может ли замена библиотеки GPU (или что-то подобное) для вызова ddriv3 (но вы специально исключили эту опцию в свой вопрос.) Есть, конечно, библиотеки графического процессора, которые могут помогать в решении ODE.

+0

Большое спасибо за ваш ответ! Как я понял, предварительная компиляция библиотеки является проблемой. На самом деле мой проект Fortran состоит из файлов * .F90 и кода suce библиотеки SLATEC (также * .F90, автономный), и когда я компилирую свой проект, также компилируется исходный код SLATEC, так же как куча дополнительных подпрограммы. Извините, если я использовал термин «библиотека» неправильно, и если он изменит ситуацию. –

+0

Тогда ваше дело описано в моем третьем абзаце. Пока ни одна из дополнительных подпрограмм не ссылается на какую-либо библиотеку хоста, возможно, стоит попробовать посмотреть, что происходит с OpenACC (хотя я не очень оптимистично оцениваю результат). С CUDA Fortran вы все еще сталкиваетесь с задачей преобразования всего кода подпрограммы в параллельный код CUDA (т. Е. Это не так просто, как «параллельный цикл» в OpenACC). В любом случае, вероятно, задействованы некоторые нетривиальные усилия, т. Е.что-то помимо простой аннотации вашего кода с несколькими директивами. –