Intel Fortran и gFortran

[pphantom]

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

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

Comments

[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, спасибо