Intel Fortran и gFortran
Обнаружил, что есть как минимум одна языковая деталь, при работе с которой интеловский компилятор проигрывает GNU'тому. Собственно, подозрения возникали и раньше, но сейчас они окончательно подтвердились
( Read more... )
А именно для них причины таковы:
1) Нынешний Фортран является весьма неплохим примером DSL для вычислительных задач. C в этом отношении - полная противоположность. Соответственно, время разработки, читаемость кода, удобство для длительной поддержки и т.д. в случае Фортрана на порядок лучше. Кстати, стоит отметить еще и то, что C в неумелых руках - страшная штука, а вычислительные задачи, как правило, пишут люди, для которых программирование основной профессией не является (со всеми вытекающими отсюда последствиями).
2) За все время существования Фортрана на нем написано безумное количество кода, значительная часть которого активно используется (научный софт, как правило, самый долгоживущий - до сих пор встречается код, который писался еще в 60-70-х годах). Переводить это на какой-либо другой язык долго, сложно, и никому не нужно.
3) Следствием двух вышеперечисленных причин является то, что сейчас на любой архитектуре есть компиляторы Фортрана. Такую же распространенность имеет только C, все остальные языки основательно отстают. При этом эти компиляторы, как правило, буквально "вылизаны" для обеспечения максимального быстродействия, благо что для сравнительно простого Фортрана это сделать проще, чем для того же C. По тем же причинам большая часть каких-то новых инструментов в этой области делается именно в расчете на Фортран.
4) "Превосходная оптимизация" компиляторов C далеко не всегда оказывается таковой. Вернее, языковые средства не обладают достаточной выразительностью для того, чтобы компилятор мог максимально оптимизировать код. Поэтому на практике, кроме всех преимуществ из п.1., программы на Фортране попросту быстрее работают, чем аналогичные программы на C. Добиться аналогичной (но не большей) производительности от C можно, но при этом одну фортрановскую строчку с немалой вероятностью придется развернуть в несколько десятков (если не сотен) строк кода.
Ну вот, примерно так. :)
Reply
Ещё есть такой замечательный текст от Дейкстры...
И да, pphantom, насколько часто Вам встречаются задачи, которые не нужно считать неделями, а нужно один раз быстро посчитать? Или прикинуть, как и что будет?
Reply
Что касается текста Дейкстры...
Во-первых, он написан в 1975 году. Нынешний Фортран весьма слабо напоминает даже Фортран 77 (который в 1975 году существовал еще только в виде проекта), а Дейкстра в качестве образца имел Фортран 66 (он же IV).
Во-вторых, вопрос выбора языка - это, в конечном счете, вопрос удобства. Личное мнение Дейкстры по этому вопросу, как показал опыт, успехом не пользуется.
Ну а задачи-прикидки - тоже достаточно часто. И что?
Reply
То есть чуть-чуть поработав с python+glesp (пакет для работы с cmb) у меня появилась по-факту проблемно-ориентированная консоль. То есть когда можно писать программы в терминах задачи, а не в терминах языка программирования.
Reply
Что касается простоты синтаксиса, но опять-таки "на вкус и цвет". У каждого свои привычки, и если Ruby я более-менее перевариваю (хотя и не слишком люблю), то некоторые особенности Python'а, начиная с табулятора в виде синтаксической конструкции, вызывают просто отторжение.
Но это, в конце концов, не так уж важно. "Обвязку" вычислительной задачи можно писать на чем угодно, хоть на Прологе (не кидайтесь тапками, но им для этих целей я как раз периодически пользуюсь). А вот саму эту задачу на Ruby Вы не напишете (а если и напишете, то результатов будете ждать до пенсии). Писать на Python'е обвязку для GLESP'а, наверное, удобно, но для этого сначала некто Олег Верходанов сотоварищи должны были написать сам этот GLESP. На чем, кстати, он написан, Вы в курсе? ;)
Reply
Может быть я просто слишком много общаюсь с такими задачами и такими языками, где нужно не правильно писать что-то новое, а правильно комбинировать уже существующее.
И в ответ на удалённый комментарий (они таки приходят =). Пример того, что у меня получалось:
#!/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. Используйте тэги
your code here.
Reply
Я догадываюсь, что приходят.
Такой фокус тоже не прошел (вернее, прошел частично). :( Есть нормальное решение, но, к сожалению, оно не лезет (длина комментария ограничена), а маленький кусок не слишком показателен. Не картинку же вставлять...
Reply
Вот я, кстати, сейчас ровно на 95-м фортране пишу какую-то гидродинамическую задачку (решение несложного дифура...). И меня больше раздражают не какие-нибудь крупные идеи, а всякие мелочи, о которые спотыкаешься... просто такое ощущение, что выехал с автобана на разбитый асфальт. Вроде ровно, а вроде и трясёт.
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Leave a comment