Intel Fortran и gFortran

Nov 16, 2009 01:30

Обнаружил, что есть как минимум одна языковая деталь, при работе с которой интеловский компилятор проигрывает GNU'тому. Собственно, подозрения возникали и раньше, но сейчас они окончательно подтвердились ( Read more... )

числодробилки

Leave a comment

Comments 26

dair_targ_one November 15 2009, 22:41:56 UTC
Насколько Вы много/часто используете fortran?

Reply

pphantom November 15 2009, 22:46:02 UTC
Хм... почти постоянно. А что?

Reply

dair_targ_one November 15 2009, 22:54:48 UTC
Ну просто насколько осмысленно на таком уровне оптимизировать. То есть это явно должно быть что-то (библиотека/приложение), что работает постоянно.

Reply

pphantom November 15 2009, 23:02:31 UTC
Не обязательно. Собственно, этот пост появился под впечатлением от свеженаписанного модуля (правда, "теоретического" - мне нужно было протестировать учебную задачу, испольщующую заведомо неэффективный вычислительный метод), для которого IFC при любых играх с ключами генерировал код, сжиравший всю оперативную память за несколько минут, в отличие от GNU'сного компилятора (который рекурсию корректно развернул).

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

Reply


glex1 November 15 2009, 23:58:30 UTC
Каковы преимущества использования в фортрана в век превосходно оптимизированных C-компиляторов для performance задач, и множества экоститем для всех остальных задач?

Reply

pphantom November 16 2009, 15:05:57 UTC
Ни о каких других задачах, кроме вычислительных, речь, естественно, не идет, а они почти всегда как раз performance ( ... )

Reply

dair_targ_one November 16 2009, 16:57:39 UTC
Остаётся добавить, что после небольшой работы современные языки позволяют вызывать код, написанный на одном языке из другого. Кстати, я знаю несколько пакетов, которые активно пользуются этим. Например, тот же FFTW, который написан на C, но при этом обладает API для фортрана.

Ещё есть такой замечательный текст от Дейкстры...

И да, pphantom, насколько часто Вам встречаются задачи, которые не нужно считать неделями, а нужно один раз быстро посчитать? Или прикинуть, как и что будет?

Reply

pphantom November 16 2009, 19:43:09 UTC
Позволяют, это верно. Вопрос только в том, зачем этим заниматься в данном случае?

Что касается текста Дейкстры...

Во-первых, он написан в 1975 году. Нынешний Фортран весьма слабо напоминает даже Фортран 77 (который в 1975 году существовал еще только в виде проекта), а Дейкстра в качестве образца имел Фортран 66 (он же IV).

Во-вторых, вопрос выбора языка - это, в конечном счете, вопрос удобства. Личное мнение Дейкстры по этому вопросу, как показал опыт, успехом не пользуется.

Ну а задачи-прикидки - тоже достаточно часто. И что?

Reply


оффтоп zhectjahsik December 9 2009, 00:12:29 UTC
Здравствуйте! Можно задать Вам вопрос, как человеку, который пишет на фортране и при этом является всесторонне развитым программистом: часто ли в своем коде вы используете "низкоуровневые трюки", под которыми я понимаю или связку {Loc() + malloc()} в Intel Fortran или transfer() ?

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

Заранее, спасибо!

Reply

Re: оффтоп zhectjahsik December 9 2009, 00:22:43 UTC
И самый глупый вопрос, который меня мучает: Вот мы подсоединили к стандартному устройству ввода не клавиатуру, а другой файл. Как средствами Фортрана вычитывать посимвольно входной поток? Все что у меня получилось, основано на примере из описания Intel Fortran:

объявляем большой массив
character(Len=1), allocatable :: BUF(:)

integer :: BIG_NUMBER = 10000
integer :: char_in_str
integer :: char_unread
integer :: i

allocate(BUF(BIG)_NUMBER))
read(5,(q,(a1),q)) char_in_str, (BUF(i), i = 1, char_in_str) , char_unread

Ясно, что если char_in_str > BIG_NUMBER, то программа завалится. А ведь мы не можем предсказать размер строки входного потока, если не оговорим это в какой-то спецификации.

Логичнее вычитывать из потока 5 (номер с оговорками "зашит" в IntelFortran как unit для stdin) посимвольно (а в целях оптимизации все же блоками не большее чем BLOC_SIZE символов ), но read упорно читает до символа конца строки или конца файла, просто выбрасывая симовлы, которым не соответсвует переменной в списке ввода, расположенного справа от read.

Reply

Re: оффтоп pphantom December 9 2009, 22:37:24 UTC
Есть несколько подходящих механизмов. Ну, например, так:

program qq
implicit none
character :: c
integer :: i
open(unit=1,file="data.txt",form="binary",recl=1)
do i=1,100
read(1) c
print *,c
end do
close(1)
end program qq

Другое дело, что подобная потребность на Фортране несколько противоестественна. Обработку текстовых файлов лучше писать на чем-то другом. :)

Reply

Re: оффтоп pphantom December 9 2009, 22:12:57 UTC
Ну спасибо на добром слове. :)

"Низкоуровневые трюки": первым - никогда, вторым - крайне редко (кажется, использовал вообще один или два раза).

Классы и наследование: я, по крайней мере в этом отношении, "классический вычислитель". То, что действительно нужно постоянно, либо уже реализовано, либо реализуется крайне просто. Городить ради этого огород с классами, на мой взгляд, нерационально.

Reply


draug February 19 2010, 07:13:24 UTC
Ну, ifort активно развивается, все может измениться. После того, как они купили первую версию GotoBLAS, в моих приложениях (большие плотные многомерные массивы) им не стало равных. Хотя некоторые детали пока еще раздражают, да.
Впрочем, у них есть форум, там часто можно получить толковый совет. Или просто узнать, "что вы там думаете со своей рекурсией, когда почините-то". Примеры они тоже приветствуют, тестируют и разбирают.

Reply


Leave a comment

Up
[]