Обнаружил, что есть как минимум одна языковая деталь, при работе с которой интеловский компилятор проигрывает GNU'тому. Собственно, подозрения возникали и раньше, но сейчас они окончательно подтвердились
( Read more... )
Не обязательно. Собственно, этот пост появился под впечатлением от свеженаписанного модуля (правда, "теоретического" - мне нужно было протестировать учебную задачу, испольщующую заведомо неэффективный вычислительный метод), для которого IFC при любых играх с ключами генерировал код, сжиравший всю оперативную память за несколько минут, в отличие от GNU'сного компилятора (который рекурсию корректно развернул).
Впрочем, и менее существенная разница тоже бывает важной. Улучшение быстродействия на 10% - не такая уж мелочь, если один прогон программы занимает неделю.
Каковы преимущества использования в фортрана в век превосходно оптимизированных C-компиляторов для performance задач, и множества экоститем для всех остальных задач?
Остаётся добавить, что после небольшой работы современные языки позволяют вызывать код, написанный на одном языке из другого. Кстати, я знаю несколько пакетов, которые активно пользуются этим. Например, тот же FFTW, который написан на C, но при этом обладает API для фортрана.
И да, pphantom, насколько часто Вам встречаются задачи, которые не нужно считать неделями, а нужно один раз быстро посчитать? Или прикинуть, как и что будет?
Позволяют, это верно. Вопрос только в том, зачем этим заниматься в данном случае?
Что касается текста Дейкстры...
Во-первых, он написан в 1975 году. Нынешний Фортран весьма слабо напоминает даже Фортран 77 (который в 1975 году существовал еще только в виде проекта), а Дейкстра в качестве образца имел Фортран 66 (он же IV).
Во-вторых, вопрос выбора языка - это, в конечном счете, вопрос удобства. Личное мнение Дейкстры по этому вопросу, как показал опыт, успехом не пользуется.
Ну а задачи-прикидки - тоже достаточно часто. И что?
Здравствуйте! Можно задать Вам вопрос, как человеку, который пишет на фортране и при этом является всесторонне развитым программистом: часто ли в своем коде вы используете "низкоуровневые трюки", под которыми я понимаю или связку {Loc() + malloc()} в Intel Fortran или transfer() ?
Каким образом вы обходите отсутсвие классов и наследования в фортране 95. И вытекающий из предыдущего вопрос: пишете ли вы реализаци контейнеров для каждого конкретного алгоритма, или у вас есть на примете"готовые", а может и свои средства, реализующие вектора переменной длинны, ассоциативные массывы, кортежи и т.п. вещи, которые нужны в алгоритмах постоянно, но в "классическом подходе" вычислителей каждый раз пишутся заново в новом месте появления?
Re: оффтопzhectjahsikDecember 9 2009, 00:22:43 UTC
И самый глупый вопрос, который меня мучает: Вот мы подсоединили к стандартному устройству ввода не клавиатуру, а другой файл. Как средствами Фортрана вычитывать посимвольно входной поток? Все что у меня получилось, основано на примере из описания Intel Fortran:
объявляем большой массив character(Len=1), allocatable :: BUF(:)
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.
Есть несколько подходящих механизмов. Ну, например, так:
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
Другое дело, что подобная потребность на Фортране несколько противоестественна. Обработку текстовых файлов лучше писать на чем-то другом. :)
"Низкоуровневые трюки": первым - никогда, вторым - крайне редко (кажется, использовал вообще один или два раза).
Классы и наследование: я, по крайней мере в этом отношении, "классический вычислитель". То, что действительно нужно постоянно, либо уже реализовано, либо реализуется крайне просто. Городить ради этого огород с классами, на мой взгляд, нерационально.
Ну, ifort активно развивается, все может измениться. После того, как они купили первую версию GotoBLAS, в моих приложениях (большие плотные многомерные массивы) им не стало равных. Хотя некоторые детали пока еще раздражают, да. Впрочем, у них есть форум, там часто можно получить толковый совет. Или просто узнать, "что вы там думаете со своей рекурсией, когда почините-то". Примеры они тоже приветствуют, тестируют и разбирают.
Comments 26
Reply
Reply
Reply
Впрочем, и менее существенная разница тоже бывает важной. Улучшение быстродействия на 10% - не такая уж мелочь, если один прогон программы занимает неделю.
Reply
Reply
Reply
Ещё есть такой замечательный текст от Дейкстры...
И да, pphantom, насколько часто Вам встречаются задачи, которые не нужно считать неделями, а нужно один раз быстро посчитать? Или прикинуть, как и что будет?
Reply
Что касается текста Дейкстры...
Во-первых, он написан в 1975 году. Нынешний Фортран весьма слабо напоминает даже Фортран 77 (который в 1975 году существовал еще только в виде проекта), а Дейкстра в качестве образца имел Фортран 66 (он же IV).
Во-вторых, вопрос выбора языка - это, в конечном счете, вопрос удобства. Личное мнение Дейкстры по этому вопросу, как показал опыт, успехом не пользуется.
Ну а задачи-прикидки - тоже достаточно часто. И что?
Reply
Каким образом вы обходите отсутсвие классов и наследования в фортране 95. И вытекающий из предыдущего вопрос: пишете ли вы реализаци контейнеров для каждого конкретного алгоритма, или у вас есть на примете"готовые", а может и свои средства, реализующие вектора переменной длинны, ассоциативные массывы, кортежи и т.п. вещи, которые нужны в алгоритмах постоянно, но в "классическом подходе" вычислителей каждый раз пишутся заново в новом месте появления?
Заранее, спасибо!
Reply
объявляем большой массив
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
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
"Низкоуровневые трюки": первым - никогда, вторым - крайне редко (кажется, использовал вообще один или два раза).
Классы и наследование: я, по крайней мере в этом отношении, "классический вычислитель". То, что действительно нужно постоянно, либо уже реализовано, либо реализуется крайне просто. Городить ради этого огород с классами, на мой взгляд, нерационально.
Reply
Впрочем, у них есть форум, там часто можно получить толковый совет. Или просто узнать, "что вы там думаете со своей рекурсией, когда почините-то". Примеры они тоже приветствуют, тестируют и разбирают.
Reply
Leave a comment