>OMP есть и на С/С++ (http://ru.wikipedia.org/wiki/OpenMP). Пример переписывается дословно.

да неужели? :)

> Нет ни одной фортрановской конструкции, которую нельзя реализовать на С/С++ с не худшей производительностью чем на фортране.

Уважаемый!

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

http://www.linux.org.ru/news/java/5148692

и если останется желание, то можем поговорить на тему производительности эквивалентной программы на Фортране и С. А про С++ я бы вообще и не начинал.

>Если Вам есть что сказать по этому поводу, советую ознакомиться с этим

http://www.linux.org.ru/news/java/5148692

Наверное, тут людям делать нечего - только читать 14 страниц треда, попробуй из него еще понять, что именно вы имеете в виду. Что там по существу-то? Не нравится Си, Фортран - используйте Matlab, Mathematica.

и если останется желание, то можем поговорить на тему производительности эквивалентной программы на Фортране и С.

Так говорите или не разводите пустословия.

> Для «числодробилок» он не просто «не хуже», а лучше.

Хуже. Теперь, когда есть restrict, точно хуже. Мы долго с одним из основных разработчиков PETSc смотрели что и как по этому поводу.

> Наверное, тут людям делать нечего - только читать 14 страниц треда

Да неееет, тут дюди занятые, на глупости не отвлекаются...

Что там по существу-то?

У вас как с в высшим образованием? Умеете из 14 страниц шума выделить 6-7 комментов плевел? А если нет, так и суда нет.

>> Для «числодробилок» он не просто «не хуже», а лучше.

Хуже. Теперь, когда есть restrict, точно хуже. Мы долго с одним из основных разработчиков PETSc смотрели что и как по этому поводу.

Не поделись подробностями? Что «вдруг» принес restrict, и что Вам Satish про это сказал?

Это всё хорошо, но что-то не видно нормального описания изменений.

>> Нет ни одной фортрановской конструкции, которую нельзя реализовать на С/С++ с не худшей производительностью чем на фортране.

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

http://www.linux.org.ru/news/java/5148692

14 страниц читать конечно же лень, но как я понял (с последней страницы) все преимущества фортрана сводятся к http://www.ibiblio.org/pub/languages/fortran/ch1-2.html . И какой пункт из этого списка нельзя сделать на С с нехудшей производительностью?

Или вопрос/утверждение стоит так: «Новичек на фортране создаст код как правило более быстрый чем новичек на С?» Ну уж тут не поспоришь — возможностей у С больше, соответственно и возможностей напортачить тоже больше :). Хотя я обычно использую другую сторону утверждения: больше возможностей (гибкость) языка — больше возможностей оптимизации кода.

и если останется желание, то можем поговорить на тему производительности эквивалентной программы на Фортране и С. А про С++ я бы вообще и не начинал.

Это опять камешек в сторону гибкости: возможностей у С++ еще больше, соответственно и возможностей напортачить тоже еще больше? Опять таки умываю руки — если кто-то не умеет пользоваться инструментом, то он сам себе «злобный буратино».

А вообще процитирую комментарий из http://www.linux.org.ru/news/java/5148692/page6#comment-5168335

«Сам C++ - это надстройка над C. Да, это очень удобная надстройка, имеющая много плюшек, но это не самостоятельный язык. C++ - это удобный способ организации кода в собственной программе.»

>Что «вдруг» принес restrict

Наверно научил С/С++ по умолчанию параметры в подпрогаммах по ссылке передавать. )))

> все преимущества фортрана сводятся к http://www.ibiblio.org/pub/languages/fortran/ch1-2.html

Вы забыли один принципиальный момент: преимущества рассматриваются только с точки зрения вычислительных задач, а не язык как таковой.

И какой пункт из этого списка нельзя сделать на С с нехудшей производительностью?

Любой, нет?

Хотите попрактиковаться? Начните с COMMON. Если получится, переходите к EQUIVALENCE или ENTRY.

я обычно использую другую сторону утверждения: больше возможностей (гибкость) языка — больше возможностей оптимизации кода.

Это неверно, все в точности наоборот. Оптимизации лучше поддаётся алгоритм с меньшим количеством неоднозначности. Моё же утверждение было такое - программисты одинаковой квалификации в общем пишут вычислительные программы на Фортране более производительнее чем на Си. Это утверждение нельзя ни доказать ни опровергнуть, слишком много неопределённостей. Я это говорю из своего опыта работы с большим количеством проектов и на том и на другом языке.

если кто-то не умеет пользоваться инструментом, то он сам себе «злобный буратино»

Когда речь идёт о вычислительных задачах, тысячах накопленных проектах, миллионах строк кода, аргумент «сам себе злобный буратино» как то не очень выглядит. Нужно смотреть тенденцию, анализировать закономерности, определять типичные действия и ошибки. И не забывать простого факта - почти всегда основу вычислительного алгоритма пишет не программист. Это может быть физик, биолог, химик, математик, но почти всегда это не программист. Таковы реалии...

>> все преимущества фортрана сводятся к http://www.ibiblio.org/pub/languages/fortran/ch1-2.html

Вы забыли один принципиальный момент: преимущества рассматриваются только с точки зрения вычислительных задач, а не язык как таковой.

На этот список я как-то натыкался. Его ж написали черт знает когда, еще там и Фортран 77 приводится. В каком веке вообще живете?

Хотите попрактиковаться? Начните с COMMON.

Это еще зачем???!!! Использование блока COMMON давно признано ненадежным, и от него отказались еще в Фортран 90.

я обычно использую другую сторону утверждения: больше возможностей (гибкость) языка — больше возможностей оптимизации кода.

Это неверно, все в точности наоборот. Оптимизации лучше поддаётся алгоритм с меньшим количеством неоднозначности.

Не могли бы здесь уточнить, речь об оптимизации компиляторов, не? Интеловские компиляторы С/C++/Fortran одинаково быстрые. Или речь о проектах? Расскажите тогда, какие у Фортрана СВОБОДНЫЕ библиотеки, сравнимые с GSL с ODE решателями и прочими плюшками?

Моё же утверждение было такое - программисты одинаковой квалификации в общем пишут вычислительные программы на Фортране более производительнее чем на Си.

Ну уж в Фортране большой квалификации не нужно. Тогда уж одинаково «неквалифицированные» программисты, да. И еще, назовите мне НОРМАЛЬНЫЙ учебник по Фортрану, сравнимый с Керриганом и Ричи? Мне также интересны библиотеки на Фортран 90, а не написанные в мохнатые года на 77ом. Где сообщество фортранистом? Я в общался в СПбГУ с преподавателем Фортрана, так он даже не знал, что LAPACK на Си переведен. Такое впечатление, что люди, пишущие на Фортран, живут в каком-то прошлом веке, когда этот язык был лучшим для расчетов.

>> все преимущества фортрана сводятся к http://www.ibiblio.org/pub/languages/fortran/ch1-2.html

Вы забыли один принципиальный момент: преимущества рассматриваются только с точки зрения вычислительных задач, а не язык как таковой.

Угу. Только зачем уж себя ограничивать только вычислительными задачами ;)

И какой пункт из этого списка нельзя сделать на С с нехудшей производительностью?

Любой, нет?

НИ ОДНОГО. Все на С будут не медленнее

Хотите попрактиковаться? Начните с COMMON. Если получится, переходите к EQUIVALENCE или ENTRY.

Как я понимаю: COMMON — глобальные переменные (возможно в namespace) EQUIVALENCE — аналог union ENTRY — легко пишется через static переменные функции (по крайней мере как я понял из его описания) void func() { static int a=0; if(a) { /* пропускаем код вначале */ } else a = 1; /* продолжаем выполнение */ }

Что еще?

я обычно использую другую сторону утверждения: больше возможностей (гибкость) языка — больше возможностей оптимизации кода.

Это неверно, все в точности наоборот. Оптимизации лучше поддаётся алгоритм с меньшим количеством неоднозначности.

Хмм, можно контрпример. Современные процессоры любят данные выровненные по 4,8 или 16 байт (кэш так устроен и мат. сопроцессор). В С/С++ я принудительно могу сделать такое выравнивание + скармливать процессору данные в нужном порядке (чтобы они находились близко и сразу вместе попадали в кэш). В фортране я этого сделать не могу как правило. В результате скорость расчета в фортране падает.

Ну уж про игры с указателями; функциональные, стековые и пр. стили программирования я уже не говорю.

Моё же утверждение было такое - программисты одинаковой квалификации в общем пишут вычислительные программы на Фортране более производительнее чем на Си. Это утверждение нельзя ни доказать ни опровергнуть, слишком много неопределённостей.

Т.е. все таки говорим про новичков, которые не удосужились изучить хотя бы основы языка и методы оптимизации программ?! Тогда согласен — в С/С++ накосячить проще.

если кто-то не умеет пользоваться инструментом, то он сам себе «злобный буратино»

Когда речь идёт о вычислительных задачах, тысячах накопленных проектах, миллионах строк кода, аргумент «сам себе злобный буратино» как то не очень выглядит. Нужно смотреть тенденцию, анализировать закономерности, определять типичные действия и ошибки. И не забывать простого факта - почти всегда основу вычислительного алгоритма пишет не программист. Это может быть физик, биолог, химик, математик, но почти всегда это не программист. Таковы реалии...

Знаю, знаю... сталкивался. Пытались меня посадить на монструозный проект расчета распространения лазерных пучков в веществе. Написанный индийскими «программистами» по формулам «физика» — полное отсутствие оптимизации, куча условий/нашлепок и т.д. и т.п.

Зато переписывание кода с нуля по правильно «преобразованным» формулам (ведь a+b и b+a считается часто с заметно разной скоростью) принесло мне известность + неплохие деньги и будущие приглашения/контракты... Ах да результатом стало сокращение времени типичного расчета с одной недели до 1 часа + 95% процентная распараллеливаемость алгоритма/программы для кластеров ... Хотя сейчас бы я наверное еще минут на 5-10 смог бы сократить ... только это вроде уже не критично.

И никакой фортран тут не поможет если руки кривые. Так что каждый «сам себе злобный буратино».

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

> Только зачем уж себя ограничивать только вычислительными задачами ;)

1) Нельзя объять необъятное, 2) Каждый инструмент нужно применять по назначению.

Как я понимаю: COMMON — глобальные переменные

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

Хмм, можно контрпример. Современные процессоры любят данные выровненные по 4,8 или 16 байт (кэш так устроен и мат. сопроцессор). В С/С++ я принудительно могу сделать такое выравнивание + скармливать процессору данные в нужном порядке (чтобы они находились близко и сразу вместе попадали в кэш). В фортране я этого сделать не могу как правило. В результате скорость расчета в фортране падает.

Здесь не место для примеров, поскольку простой пример не получится, а большой неизменно приведет к тюнингу на 100 страниц (типа писать надо так а не этак, компиляровать так, запускать так).

Выравнивание чаще является требованием памяти, а не узлов процессора. Вот допустим, написали вы программу, которая учитывает выравнивание одних объектов по 4 байта, а других по 8 байт (все как требует ваш процессор). Завтра решили посчитать на другой машине с другими требованиями по выравниванию. Что делать будете?

Т.е. все таки говорим про новичков

И про специалистов, одинаково пишущих на обоих языках.

Зато переписывание кода с нуля по правильно «преобразованным» формулам

Все Фортран проекты будете переписывать?

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

Какова ваша пользовательская база? Вы и ваш руководитель? Какова функциональность вашего нового проекта? Демонстрация кандидатской?

Существуют исследования о времени жизни программного проекта. Известно, что чтобы проект пережил одного пользователя и стал community code, он должен быть универсальным в области, расширяемым, переносимым без привязки к определенной архитектуре, иметь низкий порог вхождения. Такие проекты легче писать на Фортране. Но я не говорю, что такие проекты нельзя писать на других языках.

И напоследок — я сам физик и по образованию и по основной работе. Но это не мешает мне знать чуть-чуть из соседних областей

И это, к сожелению не важно, хотя и приятно. Один в поле не воин, одиночки науку не делают. Вам всего хорошего.

> Ну уж в Фортране большой квалификации не нужно.

Вы действительно обладаете квалификцией, чтобы так говорить? У меня вот, например, опыт программирования на Фортране лет 20, и я не берусь утверждать, что его знаю.

Такое впечатление, что люди, пишущие на Фортран, живут в каком-то прошлом веке, когда этот язык был лучшим для расчетов.

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

>Вот так всегда. Как доходит до дела, Фортран мало кто знает. Главное свойство COMMON - неразрывность области памяти, которая может переиспользоваться в разном контексте. Закругляюсь, и c сожелением констатирую, что все меньше людей, ругающих Фортран действительно его знают.

Не надо тут пытаться иронизировать. COMMON блоки и раньше в основном использовались как области глобальных переменных. Им на смену давно пришли модули. А использование области памяти в COMMON признано небезопасным.

Известно, что чтобы проект пережил одного пользователя и стал community code, он должен быть универсальным в области, расширяемым, переносимым без привязки к определенной архитектуре, иметь низкий порог вхождения. Такие проекты легче писать на Фортране. Но я не говорю, что такие проекты нельзя писать на других языках.

Ну это уж слишком притянутое мнение насчет Фортрана. Вы говорили про физиков, биологов и других ученых. Так вот, в этой среде Фортран никому особо и не нужен, и утверждать обратное - глупость. 99% задач решается на Matlab, Mathematica, Maple. Да, матричные вычисления неплохо делать на Фортране, но это ни в какое сравнение не идет с удобством Matlab и количеством подпрограмм для него. Еще замечательный единый Help, где удобно искать те самые подпрограммы.

Один в поле не воин, одиночки науку не делают.

Вы сильно заблуждаетесь - задачи научного коллектива гораздо шире; расчет, хоть и неотъемлемая, но достаточно небольшая их часть. Как правило, хорошую оптимизированную программу пишет один человек. Другие ею просто пользуются. Ограничиваются знанием как изменять параметры, и желания лезть в программу на Фортране ни у кого не возникнет, если программа работает. Компилятор установили, компилировать научились - и слава богу!

>Вы действительно обладаете квалификцией, чтобы так говорить? У меня вот, например, опыт программирования на Фортране лет 20, и я не берусь утверждать, что его знаю.

По вам заметно, что вы используете Фортран очень давно. Поймите правильно, я вашу точку зрения уважаю, хоть и пишу порой в резкой форме. Я не говорил, что знаю Фортран. Я знаю его достаточно, чтобы делать на нем свои расчеты. Не так много людей стремится хорошо знать Фортран, а дойти до уровня использования Фортрана как инструмента не так и сложно.

> Завтра решили посчитать на другой машине с другими требованиями по выравниванию. Что делать будете?

а препроцессор на что?

Все Фортран проекты будете переписывать?

Критические и особо медленные да. А если скорость и функциональность устраивает, то зачем переписывать?

Какова ваша пользовательская база? Вы и ваш руководитель? Какова функциональность вашего нового проекта? Демонстрация кандидатской?

Хмм, человек 5 постдоков и аспирантов (может и больше???), обсчитана пара ключевых экспериментов по компрессии импульсов в плазме (это с моим участием). И это было через несколько лет после кандидатской. Функциональность видимо достаточная, если он до сих пор (спустя 8 лет после создания) эксплуатируется.

Существуют исследования о времени жизни программного проекта. Известно, что чтобы проект пережил одного пользователя и стал community code, он должен быть универсальным в области, расширяемым, переносимым без привязки к определенной архитектуре, иметь низкий порог вхождения. Такие проекты легче писать на Фортране. Но я не говорю, что такие проекты нельзя писать на других языках.

У меня все проекты переносимые — кластеры все такие разные — без переносимости никак.

Насчет времени жизни ... есть у меня один проект, работает на Linux, Windows, MacOS (значит вроде переносимый), закачек правда немного (штук 30-40 в день). Только вот не представляю как бы я его на фортране написал. Хотя интерфейс к фортрану имеет :)

Уважаемый Владимир,

вы пытаетесь рассуждать о вещах, для которых не имеете достаточного опыта. Если госп. Балакин по-крайней мере знает о чем говорит, просто не является разработчиком действительно больших кодов и обобщает доступные ему факты, то вы просто не понимаете, о чем идет речь.

С опытом вы сами поймете, что те продукты, которые вы упоминаете, используются совершенно для других вещей, и уж точно не там, где используется Фортран. Участие в научной работе в течение долгого времени тоже расставит все на свои места: кто и что пишет, кто и как использует, и тому подобное.

С уважением,

Виталий

> человек 5 постдоков и аспирантов

Эти и есть «я и мой руководитель», не обижайтесь. Сравните это с пользовательской базой GTC, GTS, NWChem, VASP, FLASH...

>> Завтра решили посчитать на другой машине с другими требованиями по выравниванию. Что делать будете?

а препроцессор на что?

Препроцессор - не часть языка, его наличие само по себе говорит о недостатке основного языка программирования.

С точки зрения Фортран - выравнивание не должно быть частью языка, а должно быть частью реализации компилятора. Вообще, это уже мутный вопрос.

>вы пытаетесь рассуждать о вещах, для которых не имеете достаточного опыта. Если госп. Балакин по-крайней мере знает о чем говорит, просто не является разработчиком действительно больших кодов и обобщает доступные ему факты, то вы просто не понимаете, о чем идет речь.

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

С опытом вы сами поймете, что те продукты, которые вы упоминаете, используются совершенно для других вещей, и уж точно не там, где используется Фортран. Участие в научной работе в течение долгого времени тоже расставит все на свои места: кто и что пишет, кто и как использует, и тому подобное.

Здесь вы тоже промахнулись. Я считаю, кандидатскую физ-мат наук и публикации в Physical Review A достаточным опытом. И поверьте, я знаю вещи, о которых говорю. Научитесь читать чужие мысли. Я не говорил о том, что на упомянутых пакетах делают быстрые программы. Быстрые программы на Фортране/С/C++ делают единицы, и такие программы работают годами. Вы опять ведете себя слишком высокомерно.

Я прошу прощения.

Хорошо, я попробую ответить на наимение вызывающие вопросы, если смогу.

Дело в том, что большинство вычислителей занимается тем, чем возможно занимаетесь и вы: исследуют определенную тематику в рамках своей теории. У них есть любимый язык программирования, свой набор программ и утилит, ученики, использующие весь этот набор и дописывающие что нибудь свое. Вся эта деятельность не оказывает на вычислительную науку особенно большого влияния, хотя вполне возможно заметно улучшает понимание той или иной тематики в рамках той или иной теории.

На вычислительную науку влияют такие группы людей и коды, которые обеспечивают решение задач (или подходы к решению) национального масштаба. Именно такие коды (их поддержка, производительность, маштабируемость) изучаются при принятии решений построения новых компьютеров, создания новых вычислительных центров, изменения подходов к решению задачи в принципе. Примеры кодов такого типа я привел вверху. Когда принимается решение писать код такого типа, выбор языка программирования не основывается фразами о том «в каком веке мы живем» или насколько мы любим COMMON вместо module или static. Я выше писал, что является критерием при выборе.

Почему я берусь все это утверждать? Просто по долгу службы я занимаюсь вопросами производительности таких кодов на современных и будущих архитектурах. Процент использования Фортрана - 70%. Я тоже спрашиваю себя, почему?

Здесь немного о том, что я пытаюсь рассказать.

http://www.scidacreview.org/0904/html/multicore1.html

Насчёт ниточных програм.

Алексей, здравствуйте опять, после нескольких лет! :-)

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

Я редко пишу комментарии, т.к. работы много. Но по профилю стараюсь читать.

У меня есть написанная несколько лет назад Сишная мини-библиотечка, которая пул потоков делает и использует потом а распараллеливании. Вся чисто на pthreads написана. Написал её вот для этого, в этом году наконец сподобились опубликовать: http://arxiv.org/abs/1101.0086

В мае в Optics Letters выходит.

Вроде в своё время «вылизал» её довольно хорошо. Она на чистом Си написана, маленькая, лёгкая (поэтому несколько многословная, т.к. очень близко к изначальному pthreads), использовал в том числе на HP PA-RISC-ах с их родным компилятором, никаких GNU-сных расширений. Если интересно, могу прислать для ознакомления и если понравится - то для раздербанивания на куски по желанию. Мыло в статье есть, но и старое моё работает.

Насчёт языков - это всё дело вкуса. Мне гораздо легче писать на Си, т.к. я довольно хорошо могу представить, как код будет в ассемблере выглядеть. C++ - когда-то использовал, но после трахинга с профалингом завязал. Фотран - хороший компилятор Си есть ВЕЗДЕ, а вот Фотран - далеко не везде. Поэтому с моей точки зрения выбор очевиден. Ну и всё больше новых быстрых библиотек изначально сишные (классика жанра - fftw). Время Фортрана ещё не ушло, но уходит. А писать блоковую оптимизацию по кэшам и т.п. можно и на Фортране. Но мне на Си легче.

> Просто по долгу службы я занимаюсь вопросами производительности таких кодов на современных и будущих архитектурах. Процент использования Фортрана - 70%. Я тоже спрашиваю себя, почему?

Накопилось за годы?

Насчёт "кластеры проектируют под программы".

Сразу скажу, мне Ваш подход понятен. Вот только из моего личного опыта - он утопичен и именно на национальном уровне не живёт. Максимум - для конкретных достаточно узких прикладных задач локального значения. Когда строили Roadrunner я много общался с LANL. Участвовал в одном из пропозалов на его тестовую обкатку (самая крутая на тот момент машина на планете в эксклюзивное, пусть и недолгое, пользование - за это народ дрался). Так вот, сделали максимально быструю машину и положили на все предыдущие наработки, т.к. переписывать надо было ОЧЕНЬ много. Это первый наверное суперкомп с гетерогенной архитектурой. И никто не ныл, а только руки к нему тянули, только дайте, а коды напишем/адаптируем. Так что о постройке компьютеров под существующий код - это только на более низком уровне.

Теперь про национые проекты. То, что Вы перечислили - это довольно узкие задачи. А вот действительно мирового класса по влиянию научный софт - это, например, FFTW. Просто стандатр де факто. Написан на Си (+ Окамль в нужном месте), есть Фортрановский интерфейс. Линейную алгебру тоже на Си переписали. Как думаете, почему? Спецы по Фортрану постепенно вымирают. А почему до сих пор фортрановский код используют? Ну про это много раз говорили. Раньше были библиотеки только под Фортран. Поэтому код писали на нём. А сейчас тот, кто писал - он скорее всего уже умер. Причём давно. И разобраться в коде - это не просто, нужен квалифицированный специалист. Поэтому лучше не трогать. Вот и все причины. Инерция.

Ещё раз, я ничего против Фортрана не имею. Просто то, что вы высказали как аргументацию - это скорее как бы было в Вашем «идеале», а не как есть на самом деле.

> и если останется желание, то можем поговорить на тему производительности эквивалентной программы на Фортране и С.

А что тут говорить? Производительность очень близка, если придерживаться определенного стиля программирования на С (передавать все по ссылке).

А про С++ я бы вообще и не начинал.

А я вот года 3 писал на фортране 77, а потом свалил на C++ и ни капли не жалею. Код на фортране никуда не делся, всегда можно C-шную обертку написать и дернуть фортрановскую библиотеку (собственно, даже clapack это излишество — я декларировал прототипы функций из него в .h файле и все)

Более того, даже удобный синтаксис фортрановых массивов можно легко имитировать в C++, причем с примерно той же эффективностью. А помимо этого, можно прикрутить еще проверку выхода за границу массивов, что крайне удобно и полезно, по крайней мере на этапе отладки.

Уважаемый Виталий,

Во многом я с вами согласен. Видимо, основное непонимание возникло на почве разницы в задачах. Для научных приложений определяющим является не скорость вычислений, где Фортран может и должен быть лучше других, ввиду своей специализированности на подобных задачах. Повторюсь, но расчеты - только малая часть научной деятельности. Новую идею надо быстро проверить и с минимальными усилиями. И при интенсивных расчетах тоже важно наличие разнообразных библиотек, а необходимость делать нужные процедуры в Фортране «на коленке», наоборот, удручает. Покупать NAG и тому подобное, - проект потеряет переносимость. Как вариант - GSL, но ее обертка к Фортран довольно слабая. Так что налицо проблема выбора.

С уважением, Владимир.

> Когда строили Roadrunner ...

Возможно самый неудачный пример. Во-первых, существует в одном экземпляре, во-вторых, проектировался для определённого типа задач и не предусматривал рост, в-третьих, недоступен широкому кругу научной общественности, и в-четвёртых, все кто знают о том, что на нём делается в production предпочитают молчать. А вот вам пример посвежее - OLCF-3. Когда прошлым летом было предложено «взять и всё переписать на акселераторы», DOE сказало нет. Когда Джек Донгарра в каждом втором предложении на SC10 говорит «давайти пересматривать наш взгляд на то, как мы программируем сегодня суперкомпьютеры», я лично энтузиазма в глазах коллег не вижу. Авторитет Джека Донгарры подтверждать не нужно.

То, что Вы перечислили - это довольно узкие задачи. А вот действительно мирового класса по влиянию научный софт - это, например, FFTW.

Здесь произошла подмена понятий. Я различаю «выислительная библиотека» и «прикладное приложение». GTC, FLASH, MILC, NAMD, PARATEC, QBOX - примеры приложений. FFTW, mpich, ESSL, MKL, HDF5, PetSc, BLAS - примеры библиотек. Библиотеки живут другой жизнью, имеют другие требования. Я думаю, что сравнивать нельзя.

А почему до сих пор фортрановский код используют? ... Инерция.

Эх, если бы всё было так просто. А какой инерцией вы объясните появление новых Фортран кодов, написанных с нуля специально как ответ усторевшим кодам, не удовлетворяюшим современным требованиям? Т.е. появившихся в ситуации, когда разработчики уже готовы к революции. Примеры? GFDL's HIRAM new hi-res atmospheric climate code. ANL's Unic code for neutronic. Это только то, что я сам наблюдаю.

Просто то, что вы высказали как аргументацию - это скорее как бы было в Вашем «идеале», а не как есть на самом деле.

Дай бог, дай бог чтобы вы оказались правы. А мы тем самым следующую машину делать будем ;)

>> и если останется желание, то можем поговорить на тему производительности эквивалентной программы на Фортране и С.

А что тут говорить? Производительность очень близка, если придерживаться определенного стиля программирования на С (передавать все по ссылке).

Я встречал программу (называть не буду, большой проект), где COMMON блок использовался в качестве буффера для MPI_Send, и содержал, естественно, массу разнотипных данных, генерируемых в разных подпрограммах. Всё очень элегантно, красиво, эффективно и переносимо. Вот мне интересно, как вы будете такое делать на Си. Про мульки Фортрана-2008 я молчу, ну например про co-arrays. Я, правда, тоже не знаю, зачем эту нужно, но обоснование легко гуглится.

> даже удобный синтаксис фортрановых массивов можно легко имитировать в C++, причем с примерно той же эффективностью.

А вы пробовали? Особенно про эффективность.

Начните с такого примера

real(8), dimension(20) :: A real(8), parameter :: TOL = 1d-6

if ( all( A ) .lt. TOL .and. any(A) .lt. 2d0 * TOL ) then

do something

endif

А помимо этого, можно прикрутить еще проверку выхода за границу массивов

А вот это не должно делаться в рамках языка. Это должен делать компилятор. Но здесь для Фортрана 77 засада. Такой код:

subroutine A( N, X ) integer N real(8) X(1)

X(5) = sin( 0.5 )

return end

корректный, но выход за границы таки очевидный.

> но расчеты - только малая часть научной деятельности.

Я согласен, но с самого начала оговорился, что комментирую только и применительно к вычислительным приложениям (а посознательно ещё и только для HPC, поскольку других не знаю).

И при интенсивных расчетах тоже важно наличие разнообразных библиотек

Это тоже немного другая область. Но те библиоьеки, что я встречал одинаково линкуются и с Си кодом и с Фортран кодом.

а необходимость делать нужные процедуры в Фортране «на коленке», наоборот, удручает.

Может искать проект, где это уже реализовано? Я не знаю (точнее уже не помню) как выбирать проект или как реализовать ту или иную модель.

> Накопилось за годы?

Пришёл пошутить? Далеко ходить не будем. Ну вот смотрите, для примера, SPEC2006.

http://www.spec.org/cpu2006/CFP2006/

17 приложений, из которых так или иначе 10 или 59% используют Фортран. Причём те, кто знают эти приложения сразу скажут что GROMACS всю жизнь был чистым Фортран. Это же касется wrf - weather forecast model.

> А вы пробовали? Особенно про эффективность.

А то! Я даже целых 3 статьи на этом коде написал. И это было офигенно удобно. Более того, на низком уровне массивы соместимы с фортрановскими и спокойно передаются, например, в lapack-овские рутины. И в них можно упаковывать любой скалярный тип с конструктором по умолчанию.

if ( all( A ) .lt. TOL .and. any(A) .lt. 2d0 * TOL ) then

Не распарсил.

А вот это не должно делаться в рамках языка. Это должен делать компилятор.

Перегрузить оператор () для массива ничего не стоит. И это будет делать действительно компилятор. Более того, в compile time можно легко переключаться между «быстрой» и «безопасной» версией. Можно бросать исключение и легко локализовать ошибку.

а есть mpqc, psi3, написанные на C/C++

common block — самая уродливая конструкция фортрана. Никакой инкапсуляции, а в g77 еще была и «фича», свяанная с тем, что данные надо было упаковывать по убыванию размеров. C-шные struct или даже c++ статические классы намного более безопасны

> И это было офигенно удобно.

Вы хотели про эффективность что-то сказать?

Не распарсил.

Жаль.

> а есть mpqc, psi3, написанные на C/C++

ещё есть MILC, CPS, GPAW. Играем в игру - назови вычислительный проект на языке Си?

> Вы хотели про эффективность что-то сказать?

Да, и эффективность такая же: вычисление смещения в непрерывном куске данных. Или Вы думаете, фортран святым духом находит расположение нужного элемента?

MILC, CPS, GPAW.

fftw, gmp ;)

> common block ... C-шные struct

Ещё один со структурами. Скажите, а ваша структура гарантирует последовательность элементов? А можно переиспользовать её с другим набором полей? А что такое «неименованная структура»?

common block - один из способов организации совместной памяти между разными контекстами. Не лучше и не хуже других способов. А структура - это тип данных. Примерно как синее с быстрым.

>> MILC, CPS, GPAW.

fftw, gmp ;)

ок, пошли по кругу. Вы только часть комментариев читаете?

> Да, и эффективность такая же: вычисление смещения в непрерывном куске данных

Вы меряли или так, на глаз?

common block — это костыль, связанный с общей убогостью языковых средств фотрана (по историческим причинам, для упрощения компилятора). Мне странно видеть человека, который в этом уродливом детище видит что-то хорошее. В C++ можно много аналогов найти — структура, класс, замыкание — и все это будет лучше, уместнее и легче понимаемо.

В 77 фортране даже банальной рекурсии не сделать! Это не язык — это средство программирования калькуляторов.

Мерял, естественно! Сотые доли секунды на фоне сотен меня ни капли не расстраивали: важнее иметь более гибкий и выразительный язык, нежели гнаться за сомнительными оптимизациями. Это еще Кнут говорил: «Преждевременная оптимизация — корень всех зол»

Я вверху давал ссылку на точно такую же дискуссию. Почитайте, если вам действительно интересно.

Дело не в языке программирования - все языки эквивалентны. Дело в чём то более важном, чем удобство или убогость одного по сравнению с другим.

> Я встречал программу (называть не буду, большой проект), где COMMON блок использовался в качестве буффера для MPI_Send, и содержал, естественно, массу разнотипных данных, генерируемых в разных подпрограммах. Всё очень элегантно, красиво, эффективно и переносимо. Вот мне интересно, как вы будете такое делать на Си. Про мульки Фортрана-2008 я молчу, ну например про co-arrays. Я, правда, тоже не знаю, зачем эту нужно, но обоснование легко гуглится.

Ой! А вот тут можно здорово обжечься на гетерогенных кластерах. И потом долго и упорно искать ошибку. У самого похожее было, когда на альфах считал. С тех пор никаких бинарных данных без указания формата для сохранения/пересылки/чтения и пр. не использую!!! Вы с такими примерами (и программистами которые так пишут) поосторожнее были бы.

>> common block ... C-шные struct

Ещё один со структурами. Скажите, а ваша структура гарантирует последовательность элементов? А можно переиспользовать её с другим набором полей? А что такое «неименованная структура»?

Никто не отменял union. Только зачем? он довольно редко когда нужен, и то только для битовых полей или целочисленной арифметики. Или вопрос стоит о комплексных числах? если да то он легко решается явным преобразованием указателя на массив (без потери скорости).

И да, «структура гарантирует последовательность элементов».

common block - один из способов организации совместной памяти между разными контекстами. Не лучше и не хуже других способов. А структура - это тип данных. Примерно как синее с быстрым.

Это уже придирка к терминам. Структура — описание типа (или просто тип) данных, экземпляр структуры — память выделенная под этот тип и почти ничем не отличается от common block. Для краткости и то и другое часто называют структурой. Из контекста обычно понятно что имеется в виду.

>> Накопилось за годы?

Пришёл пошутить?

Вопрос задал.

17 приложений, из которых так или иначе 10 или 59% используют Фортран. Причём те, кто знают эти приложения сразу скажут что GROMACS всю жизнь был чистым Фортран.

Из статьи о GROMACS: «The molecular dynamics specific routines were rewritten in the C programming language from the Fortran77-based program GROMOS, which had been developed in the same group». Слова «had been developed in the same group» намекают, что на Фортране остются только старые кодовые базы, которые некому или незачем переписывать.

Мне лично Фортран (новый) нравиться. На старом (77) никогда не писал. Чисто из интереса купил книжку «Fortran 95/2003 Explained» и очень полюбил этот язык. Ниже мои наблюдения, основанные на личном опыте:

+: очень удобен если вы работаете с численными массивами. +: более высокого уровня чем С (но более низкого чем С++) +: быстрее С (попробуйте примеры, что идут с Интеловским компилятором: при абсолютно одинаковом примере и компиляторе фортран оказывается быстрее на ~10%) +: хорошее взаимодействие с С.

-: не популярен - это самый большой минус, по большому счету, все остальные являются следствием этого. -: компиляторы не спешат реализовывать последние стандарты. -: будущее не ясно