>> silly.latex_print();

"А зато в Америке негров бьют!"

Я не специалист в Фортране и LaTex'e, но Фортран-Анонимус говорил о ВЫЧИСЛИТЕЛЬНЫХ задачах и скорости работы Фортран-программ, а не о печати в LaTex. Вы уводите диспут в сторону.

Я еще могу сказать: "COBOL лучше C++, поскольку там есть встроенная проверка орфографии (не говоря уж об операции возведения в степень)." Это будет некорректным софистическим приемом ведения дискуссии.

Так что извольте показать мне, стороннему наблюдателю,преимущества С++ в СКОРОСТИ вычислений. А уж LaTeX-С++ связку к вычислительному блоку Фортран-анонимус напишет.

======

> Современные численные схемы тем более собой "ноу-хау" представляют Не понял, что Вы имеете в виду - математический аппарат или его реализацию в виде программы/библиотеки ?

======

Реализацию, разумеется. "Математический аппарат" в Фихтенгольце изложен (ну, и еще в паре книжек). А физический - в Ландау-Лифшице. :)

======

> и никто их ни в какие цернлибы по определению включать не может. По какому определению, позвольте осведомиться?

======

Для начала - сколько в cernlib функций для для расчета нестационарных газодинамических течений? Ссылочку плиз. Было бы любопытно. :)

======

А в чем состоит проблема, если этот код в какой-то библиотеке? В том, что в некоторых убогих языках нет нормального вызова функций/передачи параметров и для того, чтоб использовать библиотеку/ просто чей-то код, надо рыться в COMMON-блоках? :)

======

Во-первых, идти учить Фортран. Во-вторых - какой способ передачи параметров в общем случае наиболее быстрый?

======

А по поводу простоты реализации я уж помолчу. Тем более, что переписывать по сто раз одну и ту же функцию - маразм (IMHO).

======

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

======

// тупой, но показательный пример.

#include <iostream>

using namespace std;

#include <ginac/ginac.h>

using namespace GiNaC;

int main() { symbol d("D"),mu_sym("mu"),nu_sym("nu");

index mu(mu_sym,d), nu(nu_sym,d);

ex silly = dirac_gamma(mu)*dirac_gamma(nu) + dirac_gamma(nu)*dirac_gamma(mu);

silly = silly.canonicalize_clifford();

silly.latex_print();

return 0;

}

А теперь то же самое - на FORTRAN'-е!

======

А в чем показательность примера, можно осведомиться?

Фортран-Анонимус.

По поводу того, что в Фортране все передается через COMMON-блоки

Любителям Си и других прогрессивных языков:

Напишите мне, пожалуйста, аналог:

PRINT *, F( (/ .TRUE., .FALSE., .TRUE. /) )
PRINT *, F(.TRUE.,.TRUE.)
PRINT *, F( (/.TRUE., .TRUE. /), C = (/ .TRUE., .TRUE. /) )

CONTAINS

LOGICAL ELEMENTAL FUNCTION F(A,B,C)
   LOGICAL, INTENT(IN) :: A
   LOGICAL, INTENT(IN), OPTIONAL :: B
   LOGICAL, INTENT(IN), OPTIONAL :: C
   IF (PRESENT(B).AND..NOT.PRESENT(C)) THEN
      F = IEOR(A,B)
   ELSE IF (PRESENT(C)) THEN
      F = IOR(A,C)
   ELSE
      F = .NOT.A
   END IF
END FUNCTION

END

Фортран-Анонимус

Сорри, проглючил чуток:

PRINT *, F(.TRUE., .TRUE., .TRUE.) PRINT *, F( (/ .TRUE., .FALSE., .TRUE. /) ) PRINT *, F(.TRUE.,.TRUE.) PRINT *, F( (/.TRUE., .TRUE. /), C = (/ .TRUE., .TRUE. /) )

CONTAINS

LOGICAL ELEMENTAL FUNCTION F(A,B,C) LOGICAL, INTENT(IN) :: A LOGICAL, INTENT(IN), OPTIONAL :: B LOGICAL, INTENT(IN), OPTIONAL :: C IF (PRESENT(B).AND..NOT.PRESENT(C)) THEN F = IEOR(A,B) ELSE IF (PRESENT(C).AND..NOT.PRESENT(B)) THEN F = IOR(A,C) ELSE F = .NOT.A END IF END FUNCTION

END

ЗЫ: да поможет вам STL!

Фортран-Анонимус.

Сорри, проглючил чуток:

PRINT *, F(.TRUE., .TRUE., .TRUE.)
PRINT *, F( (/ .TRUE., .FALSE., .TRUE. /) )
PRINT *, F(.TRUE.,.TRUE.)
PRINT *, F( (/.TRUE., .TRUE. /), C = (/ .TRUE., .TRUE. /) )

CONTAINS

LOGICAL ELEMENTAL FUNCTION F(A,B,C)
   LOGICAL, INTENT(IN) :: A
   LOGICAL, INTENT(IN), OPTIONAL :: B
   LOGICAL, INTENT(IN), OPTIONAL :: C
   IF (PRESENT(B).AND..NOT.PRESENT(C)) THEN
      F = IEOR(A,B)
   ELSE IF (PRESENT(C).AND..NOT.PRESENT(B)) THEN
      F = IOR(A,C)
   ELSE
      F = .NOT.A
   END IF
END FUNCTION

END

ЗЫ: да поможет вам STL!

Фортран-Анонимус.

2Фортран-Анонимус:

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

anonymous (*) (2002-12-16 14:41:49.353):
> ...Вы уводите диспут в сторону.
Прежде, чем критиковать, некисло бы почитать критикуемое:

Portos (*) (2002-12-16 12:39:58.096)to Dselect:
> Зря вы так на фортран, он отнюдь не для тупых числоперемалывающих задач.
> ...на нем реализовано достаточно много сложных алгоритмов ... на С, их
> реализовывать ...сложнее ...
В ответ (ok, он отвечает сразу двоим) Dselect приводит
(Dselect (*) (2002-12-16 13:55:09.101)) пример симметризации произведения
Дираковских матриц на Гинаке.

> ...Фортран-Анонимус говорил о ВЫЧИСЛИТЕЛЬНЫХ задачах и
> скорости работы Фортран-программ
Он мешает в кучу язык, компиляторы и библиотеки. В бенчмарках же он сравнивает
супероптимизированный на числодробильню компаковской компилер с ... VC.

Я повтрял его бенчмарк на gcc (cc vs. f77) - код на f77 сгенерился в разы
медленнее. Потом сравнивал те же процедурки на родных дековских компилерах
под Альфой. Разницы практически не оказалось - скорость и у Сишного, и у Фортранного
кода была одинаковой почти такт в такт.

> супероптимизированный на числодробильню

Так значит-таки "супероптимизированный на числодробильню"?

> Я повтрял его бенчмарк на gcc (cc vs. f77)

GNU f77? Это анекдот дня?

2Dselect (*) (2002-12-14 18:41:41.646): Несколько оффтопик, но все ж.

>А Вермассерен написал Schoonship [программа для аналитических вычислений рад. поправок] на asm'-е - [без каких-то lib'-ов вообще], долгое время она была одной из лучших в мире. Что ж теперь, всем срочно бросить C++ и писать на asm'-е? [Только FORM-то все равно на C++ писан].

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

Вермассерен никогда не писАл Schoonship, вернее, мысль такая была, но он вместо этого написал Форм.

>Только FORM-то все равно на C++ писан

Нет, Форм писан на чистых сях.

> GNU f77

Убогий препроцессор FORTRAN77 в gcc vs. сам gcc? No comments...

О! Опять пришел нас смешить! :)))

======

Он мешает в кучу язык, компиляторы и библиотеки.

======

Как попугай заучил эту фразу. Самому не надоело? :) Я не мешаю, а сравниваю все возможные компилеры для интел с с/cpp и фортрана. И ты пытаешься в меру сил делать то же самое, между прочим. И опытным путем нахожу: самыми быстрыми оказываются не сишные компиляторы, а фортрановские (даже когда их делает одна и та же фирма, интел например). При этом вдобавок численный фортрановский исходник выглядит короче и проще сишного. Из этого я делаю вывод - продолжать использовать фортран, так как записать такст программы я успеваю быстрее (хотя бы за счет того, что не кодирую, как обезьяна, кучу дурацких циклов там, где есть более удобные языковые средства), а откомпилированная программа обычно быстрее (в худших случаях не медленнее) сишной. Что, мля, тебе представляется глобально логически неправильным в этих рассуждениях?

======

В бенчмарках же он сравнивает супероптимизированный на числодробильню компаковской компилер с ... VC.

======

Окстись! Уже давно сравнивали с линуксовым как icc, так и gcc (звиняйте, нету у нас под интел компаковского це, да и все равно альфа сдохла, а компаковская команда разработчиков ушла развивать интеловский _фортран_, а не С++). И оба они пососали (см. выше в треде результаты, если умеешь-таки читать).

======

Я повтрял его бенчмарк на gcc (cc vs. f77) - код на f77 сгенерился в разы медленнее.

======

Кого-то волнует, как долго идет компиляция? :)

======

Потом сравнивал те же процедурки на родных дековских компилерах под Альфой. Разницы практически не оказалось - скорость и у Сишного, и у Фортранного кода была одинаковой почти такт в такт.

======

Вначале мне некоторые тут нагло врали о _превосходстве_ Си в скорости (при этом скромно умалчивая не только о мешанине языков, компиляторов и библиотек, но и о спагетти). Хорошо, хоть это уже не повторяется. И запости для начала хотя бы подробный листинг для каждого теста, чудило. Ты даже этого не можешь сделать, не то что корректный тестовый пример самому написать. К тому же об "одинаковости" - да, я допускаю, что компаковский си может сделать циклами умножение матриц так же быстро. Поскольку компаковскому же фортрану хватает ума на то, чтобы для относительно простых исходников вроде умножения матриц приводить обход циклов для всех возможных случаев (см. выше в треде) к оптимальному (интеловский этого не умеет, и не факт кстати, что даже компаковский для более сложных циклов это умеет). Но! 1) Это не единственный пример из приведенных в треде. 2) Ты так и не привел мне бинарник (линуксовый или виндовый) с использованием любых сишных средств, языковых и прочих (можешь использовать любые сишные и ассемблерные библиотеки), чтобы на моем 3-м пне хотя бы повторился рекорд интеловской matmul (0.86). 3) Речь шла не только о производительности программы, а и об эффективности труда программиста. Аналога той же matmul в C и C++, включая все стандартные библиотеки, нет. Следовательно, любая _стандартная_ реализация Фортрана лучше любой _стандартной_ реальзации C/C++, поскольку не требует от программиста перебирать 6 циклов (если, конечно, программист в отличие от некоторых не идиот и понимает, что выбор порядка обхода в общем случае существенно влияет на скорость), а дает ему возможность вызвать matmul (или воспользоваться массивными операциями, например).

На бис выйдешь?

Фортран-Анонимус.

2 anonymous (*) (2002-12-16 14:00:20.519)

> Акимов и Шипов С++ используют. Говорят круто!
> Специальный класс Torsion c помощью STL написали.

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

2 anonymous (*) (2002-12-16 14:41:49.353)

> Я не специалист в Фортране и LaTex'e,

Дак чего Вы сюда суетесь?

> но Фортран-Анонимус говорил о ВЫЧИСЛИТЕЛЬНЫХ задачах и скорости
> работы Фортран-программ,

А я тоже говорю о вычислительных задачах, только в реальных
вычислениях слагаемых немного побольше, порядков эдак на 8 -- 9,
да и самих матриц в каждом слагаемом тоже не две.

> а не о печати в LaTex. Вы уводите диспут в сторону.

Мелочь, а приятно. Сразу можно в статью вставлять формулу :)

> Я еще могу сказать: "COBOL лучше C++, поскольку там есть встроенная
> проверка орфографии (не говоря уж об операции возведения в
> степень)." Это будет некорректным софистическим приемом ведения
> дискуссии.

Лучше ДЛЯ КАКОЙ ЗАДАЧИ? И какое возведение в степень?
pow(ex a, symbol b)?

> Так что извольте показать мне, стороннему наблюдателю,преимущества
> С++ в СКОРОСТИ вычислений.

Мне неизвестны реализации некоммутативных величин на FORTRAN,
а изобретать велосипед я не собираюсь. Так что в данный момент
преимущество по скорости в бесконечное число раз :).
К тому же, если писать на asm'-е, СЧЕТ получится еще быстрее
( если получится вообще :) ), но писать Вы ее [программу]
будете до пенсии.

> А уж LaTeX-С++ связку к вычислительному блоку Фортран-анонимус
> напишет.

См. предыдущий пункт, к тому же это довольно муторная работа даже
на C++ ( мне как-то надо было из FORM'-а в LaTeX преобразовывать,
я возился-возился и в конце концов написал на awk).

2 Фортран-Анонимус:

> Реализацию, разумеется. "Математический аппарат" в Фихтенгольце
> изложен (ну, и еще в паре книжек). А физический - в Ландау-Лифшице.

Погорячились Вы, видимо, по поводу "Фихтенгольца и еще пары книжек".
Чтоб доказать устойчивость метода, знаний из Фихтенгольца
маловато будет. А что за 'know-how' в реализации
методов [коль скоро математика уже известна] ?

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


> PRINT *, F(.TRUE., .TRUE., .TRUE.)
> PRINT *, F( (/ .TRUE., .FALSE., .TRUE. /) )
> PRINT *, F(.TRUE.,.TRUE.)
> PRINT *, F( (/.TRUE., .TRUE. /), C = (/ .TRUE., .TRUE. /) )

> CONTAINS

> LOGICAL ELEMENTAL FUNCTION F(A,B,C)

Прелесть C/C++ состоит в том, что подобный _уродский_ код там невозможен. Переменная, объявленная в функции, вне этой функции
"не видна". Нужно ли доказывать, что это хорошо(TM)?

Поэтому надо определить [в Вашем примере] 3 разные функции.

f(bool a, bool b, bool c);
f(bool a, bool b);
ff(bool a,bool c);

В случае

> PRINT *, F( (/.TRUE., .TRUE. /), C = (/ .TRUE., .TRUE. /) )

действительно поможет упомянутая Вами STL.


P.S.
Не стоит считать, что я считаю C++ верхом совершенства вообще,
и для вычислительных задач в частности - есть и получше вещи
( Ocaml, например, но это от задачи зависит ). Но FORTRAN определенно
к ним не относится.

anonymous (*) (2002-12-16 17:49:06.812):
> Убогий препроцессор FORTRAN77 в gcc vs. сам gcc?

Ты IMHO путаешь g77 и f2c. Раньше (до 99 года), действительно, в качестве
g77 выступал некий скрипт, звавший f2c. Уже несколько лет g77 - отдельный
компилер, использующий, правда, ядро gcc.

> Дак чего Вы сюда суетесь?

Для объективности.

И как независимый наблюдатель скажу, что Вы так и не привели примера, когда any C++ быстрее any Fortran'а на одной и той же any платформе.

А использование GNU f77 - это просто смешно.

2 Фортран-Анонимус

Сравнение производительности FORTRAN и C:

http://thsun1.jinr.ru/guide/alpha/#performance

anonymous (*) (2002-12-16 18:29:18.118):
> Я не мешаю, а сравниваю все возможные компилеры для интел с с/cpp и фортрана
Ты делаешь это предвзято, постоянно утверждая об отстойности всего, чего ты сам
не знаешь, постоянно при этом на личности. Извини, у меня есть более важные дела,
нежели споры с неадекватными субъектами ;) Я сравнил Фортран и Си на простейшем
примере - разницы нет. От того, что ТЫ не нашел matmul для Си, не следует, что ее
не существует. Кроме того, меня менее всего волнует некая конкретная библиотека.

> ...что выбор порядка обхода в общем случае существенно влияет на скорость
Ключевое понятие - "в общем случае". В том конкретном случае, до которого ты
докопался, оно не влияло. Я проверил это, и написАл об этом. Ты, как обычно,
ответил 3-4 постингами с содержанием: "Ну ты и придурок!"

======

Погорячились Вы, видимо, по поводу "Фихтенгольца и еще пары книжек". Чтоб доказать устойчивость метода, знаний из Фихтенгольца маловато будет.

=====

Да, я пошутил. Просто я хочу сказать, что вся литература доступна в библиотеках. В отличие от нетривиальных исходников, сделанных после прочтения этой литературы применительно к _конкретным_ задачам. Нету их ни в каких цернлибах. Потому что реальные практические решения (не сделанные на соросовские гранты поделки, о которых надо доложить спонсору, а реальные комплексы программ, за которые можно хоть какие-то деньги получать), на халяву никто никому не отдает. Да, в статьях обо всем бывает написано. Но это лишь схема, идея, а есть и много практических, нематематических моментов. Как однажды сказал Крайко некоему народу из одного известного научного учреждения (пытавшимся зачморить какого-то аспиранта за то, что в его дисере мало формул) - расситайте мне в своей организации со своей чистой математикой и всякими доказательствами хотя бы затупленный конус под углом атаки 30 градусов, а потом ляля разводите. Вот так и здесь.

======

А что за 'know-how' в реализации методов [коль скоро математика уже известна] ?

======

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

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

======

> PRINT *, F(.TRUE., .TRUE., .TRUE.) > PRINT *, F( (/ .TRUE., .FALSE., .TRUE. /) ) > PRINT *, F(.TRUE.,.TRUE.) > PRINT *, F( (/.TRUE., .TRUE. /), C = (/ .TRUE., .TRUE. /) )

> CONTAINS

> LOGICAL ELEMENTAL FUNCTION F(A,B,C)

Прелесть C/C++ состоит в том, что подобный _уродский_ код там невозможен. Переменная, объявленная в функции, вне этой функции "не видна". Нужно ли доказывать, что это хорошо(TM)?

Поэтому надо определить [в Вашем примере] 3 разные функции.

======

Вы не разобрались в примере. Учите Фортран. Hint: Перегрузка функций и операций есть и в Фортране, но это не тот случай. Прочтите раздел о необязательных параметрах функций. В качестве конкретного примера посмотрите реализацию встроенной функции RESHAPE. А главное - приведите плиз _законченный аналогично работающий аналог_. Если сможете.

Фортран-Анонимус.

>( Ocaml, например, но это от задачи зависит ). > Но FORTRAN определенно к ним не относится

Объясните ламеру-наблюдателю, почему Intel сделал такой нехороший Фортран и не сделал такой хороший oсaml?

Sorry, но со стороны видно, что Вы:

1. стремитесь уйти в свою частную предметную область;

2. делаете однозначные субъективные выводы;

3. переключаетесь на другой предмет, подменяете компайлеры.

Фортран-Анонимус показал, что пример с матрицами работает быстрее на Фортране, чем на Си.

======

> Я не мешаю, а сравниваю все возможные компилеры для интел с с/cpp и фортрана Ты делаешь это предвзято, постоянно утверждая об отстойности всего, чего ты сам не знаешь, постоянно при этом на личности. Извини, у меня есть более важные дела, нежели споры с неадекватными субъектами ;)

======

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

======

Я сравнил Фортран и Си на простейшем примере - разницы нет. От того, что ТЫ не нашел matmul для Си, не следует, что ее не существует. Кроме того, меня менее всего волнует некая конкретная

======

Можно подумать, ТЫ ее можешь найти.

======

> ...что выбор порядка обхода в общем случае существенно влияет на скорость Ключевое понятие - "в общем случае". В том конкретном случае, до которого ты докопался, оно не влияло. Я проверил это, и написАл об этом. Ты, как обычно, ответил 3-4 постингами с содержанием: "Ну ты и придурок!"

======

В том случае, до готорого докопался Я, оно влияет. Пример с 6-ю вариантами выложен, возьми интеловский компилятор и проверь сам. Книжки почитай. А то, что на коленке написал ТЫ, не являлось даже корректным умножением матриц, между прочим. По поводу того, что компаковский компилятор приводит подобные простые случаи к общему знаменателю, тебе повезло. Так ты вместо того, чтобы здраво рассудить о причинах и сравнить с другими компиляторами (хоть с интелом, который теперь на интеловской платформе ведущий), радостно заявил, что перестановка цикла вообще не нужна. Все видели, что на тот момент ты искренне полагал, что это именно так. =)

Ладно, всем пока и удачи в работе. =) До 4 сотен сообщений тред разгонять мне уже точно западло.

Фортран-Анонимус.

2 DSelect:

Правильные, кстати, вещи там пишут. Уважаю.

====== Fortran Наиболее сильной стороной процессора Alpha являются вычисления с плавающей точкой, поэтому основным инстументом, предлагаемым пользователям компьютера 'unas1', является Fortran. ======

Фортран-Аномимус.

> До 4 сотен сообщений тред разгонять мне уже точно западло.
> Фортран-Анонимус.

Интересно, ответишь?
IMHO один из твоих любимых приемов ведения дискуссии состоит в том, что
ты из принципа всегда оставляешь за собой последнее слово.

:-)

2 Фортран-Анонимус.

> Правильные, кстати, вещи там пишут. Уважаю.

> ====== Fortran Наиболее сильной стороной процессора Alpha являются
> вычисления с плавающей точкой, поэтому основным инстументом,
> предлагаемым пользователям компьютера 'unas1', является Fortran.======

Конечно, потому как Mathematica и Reduce там тормозят, см.

http://thsun1.jinr.ru/guide/athlon/#performance

2 anonymous (*) (2002-12-16 19:04:17.647)

> Sorry, но со стороны видно, что Вы:

> 1. стремитесь уйти в свою частную предметную область;

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

> 2. делаете однозначные субъективные выводы;

Результаты тестов [с указанием аппаратной/программной конфигурации]
не являются субъективными, но в то же время являются однозначными.
И показывают они именно то, что FORTRAN годится только как тупая
числомолотилка, причем даже в этом качестве его превосходство над C
незначительно. См. две приведенные выше ссылки.

> 3. переключаетесь на другой предмет, подменяете компайлеры.

Снова, см. результаты тестов. Там четко указано, где какая машина,
какой компиллятор и какие опции.

И (IMHO) ничего, кроме вычислений я не обсуждал.

> Объясните ламеру-наблюдателю, почему Intel сделал такой нехороший
> Фортран и не сделал такой хороший oсaml?

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

======

> До 4 сотен сообщений тред разгонять мне уже точно западло. > Фортран-Анонимус.

Интересно, ответишь?

======

Ну, глобально что-то новое мне и правда некогда затевать в плане дискуссий. Но послать куда подальше смогу, если потребуется. =)

А так (черт с ним, с флэймом, все равно все останутся при своем мнении), меня реально интересуют 2 момента:

1) кто найдет и предъявит сишный аналог интеловского matmul

2) удастся ли взглянуть на _законченный_ сишный аналог примера с опциональными параметрами и элементностью (ну интересно мне, насколько длинным и навороченным будет этот пример на C/С++ :) )

Фортран-Анонимус.

======

> Объясните ламеру-наблюдателю, почему Intel сделал такой нехороший > Фортран и не сделал такой хороший oсaml?

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

======

О! Супер! Отсюда 3-я хотелка: перемножить матрицы кэмлом с использованием этого компилера! =)

ЗЫ: правда, здесь уже приводиль форвард из кэмловской рассылки. Там какой-то чувак, взявшийся сравнивать, никак въехать не мог, почему на фортране медленнее получилось, чем на Си. (см. выше в треде) :)))

Фортран-Анонимус.

2 All:

Сорри, я уже забыл, что основная дискуссия шла в другом треде, чуть покороче этого. Так что звиняйте за неоднократную отсылку к началу треда. Как только позволит время, соберу все примеры (плюс что-нибудь газодинамическое), проверю еще раз на баги, откомпиляю icc, ifl, gcc, lf95, df (вроде ничего приличного не пропустил, что есть под интел?) и выложу все красиво в табличном виде. Под Линукс и под мастдай отдельно. Чтобы потом не было ругани, кто, что и как сравнивает.

Фортран-Анонимус.

2 Фортран-Анонимус: фортран сравнивать с плюсами будете, или с Си. Если с плюсами, под интел не забудьте почивший KAI. Компилятор вроде до сих пор можно взять. Интел раньше он делал конкретно. Теперь K&A интелом приобретена.

2 Фортран-Анонимус.
Только, если можно, сравнивай на ОДИНАКОВЫХ задачах. Если матрицы - чтоб размеры были одинаковые. Если разные системы - чтоб разные операционки проходили на одном железе (по возможности). А то все расплывчато как-то...
Виндузятник

AC (*) (2002-12-16 22:26:13.398):
> ...не забудьте почивший KAI.
Интересные (хотя и устаревшие) бенчмарки с KAI (хотя и не под Интелом)
vs. "Fortran 77 code was compiled with XL":
http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html

ну люди, ну надо-же иметь мозги в конце-то концов, надеюсь всем здравомыслящим людям очевидно, что методы решения/выражения одного и того-же алгоритма на разных языках разные?

понятно можно прикрутить С++ этот пример фортранимуса, но зачем? он там нафиг не уперся, и показывает исключительно способность фортранимуса мыслить фортрановым стилем и никак иначе.

по поводу "покажите мне то-то и то-то там-то и там-то" ну давайте я вам скажу напишите мне такой-то алгоритм (типа сортировки) на фортране и _докажите_ что он быстрее плюсовой реализации. и не получится у вас. хинт: шаблонирование по встраивоемой объект-функции сравнения. к тому-же реализация на С++ будет более проста в использовании (без извратов типа sort_int, sort_float итд, о них --- ниже)

также к фортранимусу, скажите, как просто(заменой одной строчки или флагом компилятора) прогнать готовую отлаженную расчетную схему(со всем вводом-выводом) реализованную на фортране (в double-precision float numbers) в скажем single-precision или там long double или еще в какой (в С++ -- элементарно, при правильно написаном коде)

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

PS. я не спорю, что переписав конкретный кусок кода (по крайней мере под x86) на асме под конкретный процессор можно уделать _любой_ компилятор (хоть фортран хоть С хоть окамл) в _разы_ вот только трудоемко это, зависимо от проца и совершенно лишено возможности использования где-то в другом месте чем было написано.

/С++ пользователь/преподаватель.

PPS. сам использую фортрановсий код исключительно путем написания враперов в C/C++

2 AC: поищем. Будет и KAI, если найдем.

2 пользователь-преподаватель.

======

ну люди, ну надо-же иметь мозги в конце-то концов, надеюсь всем здравомыслящим людям очевидно, что методы решения/выражения одного и того-же алгоритма на разных языках разные?

======

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

======

по поводу "покажите мне то-то и то-то там-то и там-то" ну давайте я вам скажу

======

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

======

без извратов типа sort_int, sort_float итд, о них --- ниже)

======

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

======

флагом компилятора) прогнать готовую отлаженную расчетную схему(со всем вводом-выводом) реализованную на фортране (в double-precision float numbers) в скажем single-precision или там long double или еще в какой (в С++ -- элементарно, при правильно написаном коде)

======

Легко. В языке есть такая штука, как KIND (разновидность типа). А в компаковском компиляторе (значит, и в интеловском) есть и ключи, о которых вы говорите. Термин double precision, кстати, в Фортране уже давно устарел. Есть REAL[(KIND)].

Фортран-Анонимус.

> /С++ пользователь/преподаватель.

А что преподаете и где? Сейчас каждый аспирант преподаватель.

2 Фортран-Анонимус:

let rec mmf f array1 array2 = match array2 with

[] -> []
| hd :: tl -> msf f array1 hd :: mmf f array1 tl

and msf f array x = match array with

[] -> []
| he :: ta -> f he x :: mf f ta x ;;

let rec mf f array = match array with

[] -> []
| hd :: tl -> f hd :: mf f tl ;;


let f1 a b = not (a or b) ;; (* или еще что-то - не важно*)

let f2 a b = a or (not b) ;; (* просто другая функция *)

let f3 a = not a;;

let r = mf f3 [true;true;true];;

(* PRINT *, F( (/ .TRUE., .FALSE., .TRUE. /) ) *)

let s = f1 true true ;;

(* PRINT *, F(.TRUE.,.TRUE.) *)


let g = mmf f2 [true;true] [true; true] ;;

Ой, только там вот очепятка в msf, правильно так:


and msf f array x = match array with

[] -> []

| he :: ta -> f he x :: msf f ta x ;;

2 Dselect:

Ну, скачал я ваше "шамо". =) Щас поглядим, какой это Сухов. Пока я читаю введение, не соблаговолите ли привести _законченную_ версию 
камловского аналога такого кода (хотя бы один вариант обхода циклов), 
раз уж начали примеры постить:

======
PROGRAM TESTMATMUL3

   IMPLICIT NONE

   INTEGER, PARAMETER :: M = 513, R = 513, N = 513
   REAL(8), DIMENSION(:, :), ALLOCATABLE :: A
   REAL(8), DIMENSION(:, :), ALLOCATABLE :: B
   REAL(8), DIMENSION(:, :), ALLOCATABLE :: C

   REAL(4) S, F
   INTEGER I, J, K

   ALLOCATE( A(M,R), B(R,N), C(M,N) )

   K = 1.
   DO I = 1, M
      DO J = 1, N
         K = K + 1
         A(I,J) = K
      END DO
   END DO

   K = 1.
   DO I = 1, M
      DO J = 1, N
         K = K + 1
         B(I,J) = K
      END DO
   END DO

   CALL CPU_TIME(S)
   CALL MATMUL_IJK(A,B,C,M,R,N)
   CALL CPU_TIME(F)
   PRINT *, 'IJK: ', F-S, C(510,510)

   CALL CPU_TIME(S)
   CALL MATMUL_JIK(A,B,C,M,R,N)
   CALL CPU_TIME(F)
   PRINT *, 'JIK: ', F-S, C(510,510)

   CALL CPU_TIME(S)
   CALL MATMUL_IKJ(A,B,C,M,R,N)
   CALL CPU_TIME(F)
   PRINT *, 'IKJ: ', F-S, C(510,510)

   CALL CPU_TIME(S)
   CALL MATMUL_JKI(A,B,C,M,R,N)
   CALL CPU_TIME(F)
   PRINT *, 'JKI: ', F-S, C(510,510)

   CALL CPU_TIME(S)
   CALL MATMUL_KIJ(A,B,C,M,R,N)
   CALL CPU_TIME(F)
   PRINT *, 'KIJ: ', F-S, C(510,510)

   CALL CPU_TIME(S)
   CALL MATMUL_KJI(A,B,C,M,R,N)
   CALL CPU_TIME(F)
   PRINT *, 'KJI: ', F-S, C(510,510)

   CALL CPU_TIME(S)
   C = MATMUL(A,B)
   CALL CPU_TIME(F)
   PRINT *, ':-): ', F-S, C(510,510)

END PROGRAM

PURE SUBROUTINE MATMUL_KJI(A,B,C,M,R,N)

   IMPLICIT NONE

   INTEGER, INTENT(IN)                  :: M, R, N
   REAL(8), DIMENSION(M,R), INTENT(IN)  :: A(M, R)
   REAL(8), DIMENSION(R,N), INTENT(IN)  :: B(R, N)
   REAL(8), INTENT(OUT), DIMENSION(M,N) :: C(M, N)

   INTEGER I, J, K

   DO J = 1, N
      DO I = 1, M
         C(I,J) = 0.
      END DO
   END DO

   DO K = 1, R
      DO J = 1, N
         DO I = 1, M
            C(I,J) = C(I,J) + A(I,K)*B(K,J)
         END DO
      END DO
   END DO

END SUBROUTINE MATMUL_KJI
PURE SUBROUTINE MATMUL_KIJ(A,B,C,M,R,N)

   IMPLICIT NONE

   INTEGER, INTENT(IN)                  :: M, R, N
   REAL(8), DIMENSION(M,R), INTENT(IN)  :: A(M, R)
   REAL(8), DIMENSION(R,N), INTENT(IN)  :: B(R, N)
   REAL(8), INTENT(OUT), DIMENSION(M,N) :: C(M, N)

   INTEGER I, J, K

   DO J = 1, N
      DO I = 1, M
         C(I,J) = 0.
      END DO
   END DO

   DO K = 1, R
      DO I = 1, M
         DO J = 1, N
            C(I,J) = C(I,J) + A(I,K)*B(K,J)
         END DO
      END DO
   END DO

END SUBROUTINE MATMUL_KIJ

PURE SUBROUTINE MATMUL_JKI(A,B,C,M,R,N)

   IMPLICIT NONE

   INTEGER, INTENT(IN)                  :: M, R, N
   REAL(8), DIMENSION(M,R), INTENT(IN)  :: A(M, R)
   REAL(8), DIMENSION(R,N), INTENT(IN)  :: B(R, N)
   REAL(8), INTENT(OUT), DIMENSION(M,N) :: C(M, N)

   INTEGER I, J, K

   DO J = 1, N
      DO I = 1, M
         C(I,J) = 0.
      END DO
   END DO

   DO J = 1, N
      DO K = 1, R
         DO I = 1, M
            C(I,J) = C(I,J) + A(I,K)*B(K,J)
         END DO
      END DO
   END DO

END SUBROUTINE MATMUL_JKI

PURE SUBROUTINE MATMUL_JIK(A,B,C,M,R,N)

   IMPLICIT NONE

   INTEGER, INTENT(IN)                  :: M, R, N
   REAL(8), DIMENSION(M,R), INTENT(IN)  :: A(M, R)
   REAL(8), DIMENSION(R,N), INTENT(IN)  :: B(R, N)
   REAL(8), INTENT(OUT), DIMENSION(M,N) :: C(M, N)

   INTEGER I, J, K

   DO J = 1, N
      DO I = 1, M
         C(I,J) = 0.
      END DO
   END DO

   DO J = 1, N
      DO I = 1, M
         DO K = 1, R
            C(I,J) = C(I,J) + A(I,K)*B(K,J)
         END DO
      END DO
   END DO

END SUBROUTINE MATMUL_JIK

PURE SUBROUTINE MATMUL_IKJ(A,B,C,M,R,N)

   IMPLICIT NONE

   INTEGER, INTENT(IN)                  :: M, R, N
   REAL(8), DIMENSION(M,R), INTENT(IN)  :: A(M, R)
   REAL(8), DIMENSION(R,N), INTENT(IN)  :: B(R, N)
   REAL(8), INTENT(OUT), DIMENSION(M,N) :: C(M, N)

   INTEGER I, J, K

   DO J = 1, N
      DO I = 1, M
         C(I,J) = 0.
      END DO
   END DO

   DO I = 1, M
      DO K = 1, R
         DO J = 1, N
            C(I,J) = C(I,J) + A(I,K)*B(K,J)
         END DO
      END DO
   END DO

END SUBROUTINE MATMUL_IKJ

PURE SUBROUTINE MATMUL_IJK(A,B,C,M,R,N)

   IMPLICIT NONE

   INTEGER, INTENT(IN)                  :: M, R, N
   REAL(8), DIMENSION(M,R), INTENT(IN)  :: A(M, R)
   REAL(8), DIMENSION(R,N), INTENT(IN)  :: B(R, N)
   REAL(8), INTENT(OUT), DIMENSION(M,N) :: C(M, N)

   INTEGER I, J, K

   DO J = 1, N
      DO I = 1, M
         C(I,J) = 0.
      END DO
   END DO

   DO I = 1, M
      DO J = 1, N
         DO K = 1, R
            C(I,J) = C(I,J) + A(I,K)*B(K,J)
         END DO
      END DO
   END DO

END SUBROUTINE MATMUL_IJK

======

Любопытно все же проверить, не ошибся ли Интел, предпочтя ОКамлу
Фортран. =) А заодно определиться, стоит ли дальше введения читать.

Фортран-Анонимус.

Похоже, не стоит дальше читать. Исходник кэмловский я взял отсюда:

http://www.bagley.org/~doug/shootout/bench/matrix/

Кэмл использовался версии 3.06 (нативный порт). То, что для ocamlopt нужен, как оказалось, MASM :-) - это супер, кстати! :)

Так как уже влом было придумывать код для замера времени в камле, я просто везде увеличил размерности до 800 (чтоб работало помедленнее и в таскбаре можно было бы оценить время). Результат:

df:

======

IJK: 3.394881 104416312293200.

JIK: 3.374853 104416312293200.

IKJ: 3.414910 104416312293200.

JKI: 3.384868 104416312293200.

KIJ: 3.414909 104416312293200.

KJI: 3.394882 104416312293200.

:-): 3.464983 104416312293200.

======

ifl (увлеклись ребяты интеловые саморекламой - отстой они пока, выходит, против компака):

======

IJK: 45.31516 104416312293200.

JIK: 37.18346 104416312293200.

IKJ: 44.97467 104416312293200.

JKI: 12.50798 104416312293200.

KIJ: 78.43279 104416312293200.

KJI: 22.76274 104416312293200.

:-): 4.075851 104416312293200.

======

ocamlopt:

Пропал из таскбара через 14 секунд. =)

Выводы: интел пока не идеал, но язык для компилятора им выбран правильно.

ЗЫ: или вы мне возразите, что MASM - отстой? Но тогда почему погонщики шамо сами законченный продукт не сделали? ,)

ЗЗЫ: завтра надо под линухом попробовать для очистки совести.

Фортран-Анонимус.

2фортран-анонимус:

" Легко. В языке есть такая штука, как KIND (разновидность типа). А в компаковском компиляторе (значит, и в интеловском) есть и ключи, о которых вы говорите. Термин double precision, кстати, в Фортране уже давно устарел. Есть REAL[(KIND)]. "

ну в это я могу поверить, далее я-же сразу попрошу числа например "четверной" точности или там числа с проверкой диапазона или еще что-нибудь такое, которых в камне(процессоре) нет. как это сделать? имхо никак, а мне часто это полезно.

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

вы недопоняли, речь не про перегрузку имени функции(в данном случае не имеет отношения к производительности) речь про передачу критерия сравнения в алгоритм сортировки. надеюсь не надо объяснять, что в этом случае скорость "вызова" inline функции оказывает значительное вляиние на производительность.

/С++ пользователь/преподаватель.

PS. про матрицы слишком длинный пример у вас, не спец я в фортране :) но можно написать весьма неплохой код(который компилятор будет чудесно разворачивать итд) если хотите давайте "померяемся" на перемножении матриц NxN для простоты.

хинт: template<unsigned N, class X = double> struct Matrix { X m[N*N]; .... };

template<unsigned N, class X> mulmat(const Matrix<N, X>& m1, const Matrix<N, X>& m2, Matrix<N, X>& result);

PPS. не могу пхвастаться наличие большого числа модных компиляторов фортрана, могу скачать intel fortran, но ключей там не дают вроде для free for noncommercial use.

======

ну в это я могу поверить, далее я-же сразу попрошу числа например "четверной" точности или там числа с проверкой диапазона или еще что-нибудь такое, которых в камне(процессоре) нет. как это сделать? имхо никак, а мне часто это полезно.

======

Разновидность может выбираться встроенными функциями в зависимости от нужных диапазонов. Четверная точность есть в компиляторах intel и lahey (сам работал только с двойной, в моей области этого предостаточно).

======

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

вы недопоняли, речь не про перегрузку имени функции(в данном случае не имеет отношения к производительности) речь про передачу критерия сравнения в алгоритм сортировки. надеюсь не надо объяснять, что в этом случае скорость "вызова" inline функции оказывает значительное вляиние на производительность.

======

Гм... В фортране (исходя из его предназначения) обычно сортируется не непонятно что, а числа (ну, или компоненты структур, которые тоже на конечном уровне числа), лежащие в массивах. Прилагаются и функции специальные (QSORT в компаковском фортране, например. И критерий сравнения там передается, если интересно). Для выбора min/max значения из масива есть и стандартные функции. Зачем мне мне все по-плюсовому усложнять и обобщать для реальной работы? Спорим, массив _чисел_ я быстрее отсортирую, чем вы? Причем даже без использования нестандартных функций.

======

PS. про матрицы слишком длинный пример у вас, не спец я в фортране :) но можно написать весьма неплохой код(который компилятор будет чудесно разворачивать итд) если хотите давайте "померяемся" на перемножении матриц NxN для простоты.

======

Про матрицы пример не длинный, а просто правильный (см. литературу, например Голуб/Ван-Лоан "Матричные вычсления", и как доказательство его правильности - результат для интеловского компилятора). Я, кстати, мессагой выше уже померялся. Ваша очередь.

Фортран-Анонимус.

"Я, кстати, мессагой выше уже померялся. Ваша очередь."

моя очередь чего? процы-то у нас разные, давайте коротенькую програмку написанную вами правильно, делающую какую-нить операцию типа перемножаем матрицы NxN, матрицу для результата возвращаем или передаем?

очень желательно для f77 потому как нету у меня f90, и я вообще ничего не знаю про f90 :( про f77 --- чуть-чуть. intel fortran v7 понимает f90? может ключиком поделитесь или url где intel их раздает?

я соответственно сейчас пишу эту операцию на C++ и посчу результаты сюда, попробую еще выкачать icc v7

======

процы-то у нас разные, давайте коротенькую програмку написанную вами правильно, делающую какую-нить операцию типа перемножаем матрицы NxN, матрицу для результата возвращаем или передаем?

======

А что сложного в том, чтобы повторить вышеприведенное? Задача предельно ясна и проста в общем-то - перемножить 2 матрицы.

======

очень желательно для f77 потому как нету у меня f90, и я вообще ничего не знаю про f90 :( про f77 --- чуть-чуть. intel fortran v7 понимает f90? может ключиком поделитесь или url где intel их раздает?

======

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

ЗЫ: фортран интеловский можете с их сайта триальный выкачать, командная строка для моего примера была "ifl /optimize:5 blabla.f90 /link /stack:10000000" Этого вам вполне хватит, если хотите мои результаты масштабировать на свой проц.

Фортран-Анонимус.

<хинт: template<unsigned N, class X = double> struct Matrix { X m[N*N]; .... }; >

Ну, с таким представлением матрицы можно дальше и не соревноваться -- сольете. Далее, будете делать развертку по N для больших N с помощью template metaprogram -- еще раз сольете.

<я соответственно сейчас пишу эту операцию на C++ и посчу результаты сюда, попробую еще выкачать icc v7 >

Нда, и с ICC на сильно шаблонном коде -- еще раз в конечном итоге сольете -- он на этом деле туповат, по крайней мере шестая версия была лишь чуть быстрее g++, и конкретно сливала kai. На LU-разложении небольших матриц.

AC, постите свой пример в студию!

Извините, что вмешиваюсь в сугубо личный флейм, но не мог бы господинс с распадником (см. выше) сообщить (если он еще здесь), есть ли у него что в электронном виде по нелинейным вариантам метода Годунова ? Очень нужно...

Сорри, по неявному варианту метода ... Оговорился после 20 часов бессоницы и чтения этого флейма ....

Сейчас появилась модная книжка Куликовский, Погорелов, Семенов Математические вопросы численного решения гиперболических систем уравнений --- М: Физматлит, 2001

Ооочень рульная, хотя подход сугубо математический. Много по Риман-солверам, методам Годунова, КИРу и т.д. и т.п.

А так, ищите лекции Колелло (Colello) - там много чего есть. Это сейчас видимо самый большой специалист по методу Годунова (Годунов-то жив еще или уже нет ?)

ARia

Сорри, Colella

А точнее Collella, Puckett "Modern Numerical Methods For Fluid Flow" (Откуда в Инете взяял не помню, но могу прислать)

+ где-то пробегала статья по всяким Риман солверам

Собственно, когда пришлось вставлять реальный УРС, они очень пригодились. Надеюсь, вы именно этого хотели ?

ARia

2 Фортран-Анонимус:

> ЗЫ: или вы мне возразите, что MASM - отстой?

Не буду возражать. Только он и НЕ нужен:

[dselect@pc7235b]:~ $apt-cache depends ocaml ocaml

Depends: libc6 Depends: libncurses5-dev Depends: ocaml-base Depends: <ocaml-base-3.06-1> ocaml-base Suggests: xlibs-dev Suggests: tcl8.3-dev Suggests: tk8.3-dev Suggests: ocaml-doc Suggests: libgdbmg1-dev

Где тут MASM?

> О! Супер! Отсюда 3-я хотелка: перемножить матрицы кэмлом с > использованием этого компилера! =)

Как я раньше писАл, как раз для такой тупой числомолотилки FORTRAN и нужен [если на blitz++ получается медленно].

Кроме того, у меня тоже есть хотелка: а давайте мы эти матрицы продифференцируем ... с помощью ifc :))

2 Фортран-Анонимус:

> ЗЫ: или вы мне возразите, что MASM - отстой?

Не буду возражать. Только он и НЕ нужен:

[dselect@pc7235b]:~ $apt-cache depends ocaml
ocaml

Depends: libc6
Depends: libncurses5-dev
Depends: ocaml-base
Depends: <ocaml-base-3.06-1>
ocaml-base
Suggests: xlibs-dev
Suggests: tcl8.3-dev
Suggests: tk8.3-dev
Suggests: ocaml-doc
Suggests: libgdbmg1-dev

Где тут MASM?

> О! Супер! Отсюда 3-я хотелка: перемножить матрицы кэмлом с
> использованием этого компилера! =)

Как я раньше писАл, как раз для такой тупой числомолотилки FORTRAN и
нужен [если на blitz++ получается медленно].

Кроме того, у меня тоже есть хотелка: а давайте мы эти матрицы
продифференцируем ... с помощью ifc :))

Да, по ходу дела MASM и на винде не нужен. Берется cygnus и под ним собирается ocaml - и никаких проблем :)

ARia

<Кроме того, у меня тоже есть хотелка: а давайте мы эти матрицы
продифференцируем ... с помощью ifc :)) >

Кстати, библиотеки для точной арифметики для Фортрана есть? Что-то как-то все больше для плюсов доводилось видеть...

AC (*) (2002-12-18 14:02:49.35):
> Что-то как-то все больше для плюсов доводилось видеть...
Вот это да!

Первые широко известные пакеты с точной арифметикой писал, наверное,
Вельтман на CDC ассемблере. AFAIK первый "доведенный до ума" пакет
принадлежит Бейли, который написАл даже транслятор на Фортране! Он
все еще "жив", http://www.nersc.gov/~dhb/mpdist/mpdist.html