Intel Fortran и gFortran

[pphantom]

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

Интеловский компилятор не умеет нормально обрабатывать рекурсию. Хвостовую - еще более-менее нормально, а вот в общем случае код получается весьма неэффективным. Правда, в вычислительных задачах рекурсия не особо нужна (и при необходимости ее обычно можно легко убрать), но все-таки печально.

Comments

[dair-targ-one.livejournal.com]

Насколько Вы много/часто используете fortran?

[pphantom.livejournal.com]

Хм... почти постоянно. А что?

[dair-targ-one.livejournal.com]

Ну просто насколько осмысленно на таком уровне оптимизировать. То есть это явно должно быть что-то (библиотека/приложение), что работает постоянно.

[pphantom.livejournal.com]

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

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

[dair-targ-one.livejournal.com]

Тогда да. Я-то просто привык за последние полтора года, что back-end уже написан кем-то ещё (всё украдено до нас!), а мне нужно решать именно задачу используя уже реализованные алгоритмы. Вот и удивляюсь -- откуда такая оптимизация.

[pphantom.livejournal.com]

Ну так этот back-end все-таки кто-то когда должен написать. :) К тому же он иногда бывает так написан, что хочется найти автора и помочь ему хирургически - оторвать руки, растущие из неправильного места.

[glex1.livejournal.com]

Каковы преимущества использования в фортрана в век превосходно оптимизированных C-компиляторов для performance задач, и множества экоститем для всех остальных задач?

[pphantom.livejournal.com]

Ни о каких других задачах, кроме вычислительных, речь, естественно, не идет, а они почти всегда как раз performance.

А именно для них причины таковы:

1) Нынешний Фортран является весьма неплохим примером DSL для вычислительных задач. C в этом отношении - полная противоположность. Соответственно, время разработки, читаемость кода, удобство для длительной поддержки и т.д. в случае Фортрана на порядок лучше. Кстати, стоит отметить еще и то, что C в неумелых руках - страшная штука, а вычислительные задачи, как правило, пишут люди, для которых программирование основной профессией не является (со всеми вытекающими отсюда последствиями).

2) За все время существования Фортрана на нем написано безумное количество кода, значительная часть которого активно используется (научный софт, как правило, самый долгоживущий - до сих пор встречается код, который писался еще в 60-70-х годах). Переводить это на какой-либо другой язык долго, сложно, и никому не нужно.

3) Следствием двух вышеперечисленных причин является то, что сейчас на любой архитектуре есть компиляторы Фортрана. Такую же распространенность имеет только C, все остальные языки основательно отстают. При этом эти компиляторы, как правило, буквально "вылизаны" для обеспечения максимального быстродействия, благо что для сравнительно простого Фортрана это сделать проще, чем для того же C. По тем же причинам большая часть каких-то новых инструментов в этой области делается именно в расчете на Фортран.

4) "Превосходная оптимизация" компиляторов C далеко не всегда оказывается таковой. Вернее, языковые средства не обладают достаточной выразительностью для того, чтобы компилятор мог максимально оптимизировать код. Поэтому на практике, кроме всех преимуществ из п.1., программы на Фортране попросту быстрее работают, чем аналогичные программы на C. Добиться аналогичной (но не большей) производительности от C можно, но при этом одну фортрановскую строчку с немалой вероятностью придется развернуть в несколько десятков (если не сотен) строк кода.

Ну вот, примерно так. :)

[dair-targ-one.livejournal.com]

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

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

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

[pphantom.livejournal.com]

Позволяют, это верно. Вопрос только в том, зачем этим заниматься в данном случае?

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

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

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

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

[dair-targ-one.livejournal.com]

Да я просто не люблю фортран и как бы намекаю на то, что для большинства задач есть заметно более простые (и в плане синтаксиса тоже -- python, ruby) языки. Поэтому нужно оптимизировать действительно узкие места, коими иногда является время/удобство написания приложения.
То есть чуть-чуть поработав с python+glesp (пакет для работы с cmb) у меня появилась по-факту проблемно-ориентированная консоль. То есть когда можно писать программы в терминах задачи, а не в терминах языка программирования.

[pphantom.livejournal.com]

Xто Вы не любите Фортран, я знаю. :) Правда, при этом я почти уверен, что не любите Вы именно Фортран 77, который разменял четвертый десяток лет (и на котором сейчас действительно пишут редко, скорее используют уже готовый код).

Что касается простоты синтаксиса, но опять-таки "на вкус и цвет". У каждого свои привычки, и если Ruby я более-менее перевариваю (хотя и не слишком люблю), то некоторые особенности Python'а, начиная с табулятора в виде синтаксической конструкции, вызывают просто отторжение.

Но это, в конце концов, не так уж важно. "Обвязку" вычислительной задачи можно писать на чем угодно, хоть на Прологе (не кидайтесь тапками, но им для этих целей я как раз периодически пользуюсь). А вот саму эту задачу на Ruby Вы не напишете (а если и напишете, то результатов будете ждать до пенсии). Писать на Python'е обвязку для GLESP'а, наверное, удобно, но для этого сначала некто Олег Верходанов сотоварищи должны были написать сам этот GLESP. На чем, кстати, он написан, Вы в курсе? ;)

[dair-targ-one.livejournal.com]

GLESP? На С. Благо у меня сейчас исходники регулярно появляются ;)
Может быть я просто слишком много общаюсь с такими задачами и такими языками, где нужно не правильно писать что-то новое, а правильно комбинировать уже существующее.

И в ответ на удалённый комментарий (они таки приходят =). Пример того, что у меня получалось:

#!/usr/bin/python
# -*- coding: utf-8 -*-
import glesp

mis = xrange(50, 100)
lrs = xrange(2, 11)

with open('x.plot', 'w') as pf:
	for map_index in mis:
		map = glesp.random()
		for lr in lrs:
			filename = 'out/m%03d-lr%03d.ascii' % (map_index, lr)
			with open(filename, 'w') as f:
				for lmin in xrange(map.lmin(), map.lmax() - lr):
					lmax = lmin + lr - 1
					f.write('%d %d %f\n' % (lmin, lmax, (map - map[lmin:lmax]).autocorr()))
			pf.write(',\\\n    \'%s\' using 1:3 w l linetype 5' % (filename))
	
	pf.write('    0\n')

Кусок генерирует случайные карты cmb, затем для каждой карты поочерёдно выкидывает по несколько гармоник, строит автокорреляцию полученной карты, записывает это всё дело в файл и параллельно генерирует gnuplot-скрипт для отрисовки всего этого дела.

p.s. Используйте тэги <code><pre>your code here</pre><code>.

[pphantom.livejournal.com]

Насколько я помню, GLESP написан на смеси F77 и С. Причем основная счетная часть - именно на Фортране. Или фортрановский только внешний интерфейс? Впрочем, это в любом случае не Python и не Ruby. :)

Я догадываюсь, что приходят.

Такой фокус тоже не прошел (вернее, прошел частично). :( Есть нормальное решение, но, к сожалению, оно не лезет (длина комментария ограничена), а маленький кусок не слишком показателен. Не картинку же вставлять...

[dair-targ-one.livejournal.com]

pastebin.com -- Есть такой ресурс для всяческого выкладывания кода.

Вот я, кстати, сейчас ровно на 95-м фортране пишу какую-то гидродинамическую задачку (решение несложного дифура...). И меня больше раздражают не какие-нибудь крупные идеи, а всякие мелочи, о которые спотыкаешься... просто такое ощущение, что выехал с автобана на разбитый асфальт. Вроде ровно, а вроде и трясёт.

[pphantom.livejournal.com]

Ну, не знаю. А что пишете?

[dair-targ-one.livejournal.com]

Frictional Resistance in Pipe Flow using the Colebrook-White equation.

[pphantom.livejournal.com]

Забавно. В качестве халтуры или какому-нибудь знакомому механику в порядке гуманитарной помощи? Просто, насколько я понимаю, ни в каком другом качестве оно Вам не нужно.

[dair-targ-one.livejournal.com]

Ну это наша проверка одного сервиса для freelancer-ства.

[pphantom.livejournal.com]

А, тогда понятно.

[glex1.livejournal.com]

OK, спасибо

оффтоп

[zhectjahsik.livejournal.com]

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

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

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

Re: оффтоп

[zhectjahsik.livejournal.com]

И самый глупый вопрос, который меня мучает: Вот мы подсоединили к стандартному устройству ввода не клавиатуру, а другой файл. Как средствами Фортрана вычитывать посимвольно входной поток? Все что у меня получилось, основано на примере из описания 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.

Re: оффтоп

[pphantom.livejournal.com]

Есть несколько подходящих механизмов. Ну, например, так:

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

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

Re: оффтоп

[pphantom.livejournal.com]

Ну спасибо на добром слове. :)

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

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

[draug.livejournal.com]

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