С фортраном всегда так?

0

0

Попросили тут на днях халтурку сделать небольшую. Переписать одну мини-утилитку (~ 250 строк кода) переписать с фортрана на плюсы.

Присылают код, действительно 250 строк. Но какой это код:

      WRITE(16,9)(NBC(I),NFIX(I),I=1,NB)
   9  FORMAT(2i8)
      call FRMEG(imax,nband,nszf,ne,ndfg,ncnm,
     *nop,estifm,nstm,a,nb,nfix,nbc,ndis,knul)

if(ncol.gt.nband) write(16,901)ncol,l,k,km,ncolb,nrowb,nop(n,kk)
     *,n,kk,ndfg
 901  format(1x,'NCOL=',10i9)
      a(im,ncol)=a(im,ncol)+estifm(i,nfx+k)
 322  continue
 320  continue
 321  continue
 360  continue
      if(ie.ne.n) read(8)

Продакшн код на фортране всегда так выглядит? Я когда-то книжку по нему листал, там всё приличнее было...

PS И предлагали в этом разбираться за 1000р =)

Ссылка

←	А вы говорите — нытик

Встречаем OpenGL 3.1 на открытых дровах amd

→

← 1 2 →

Программу на фортране можно написать на любом языке (б)ойан

DNA_Seq ★★☆☆☆
(13.01.13 23:26:50 MSK)

Ссылка

Ответ на: комментарий от Archer73 13.01.13 23:24:19 MSK

Все от задачи зависит.

Ага. Я 30-50% на своих задачах вывел некоторое время назад. А вообще видно, что gfortran на некоторых задачах жестоко сливает Intel Fortran в несколько раз, но на этих же задачах другие компиляторы сливают ещё хуже, а на многих задачах отставание от IF невелико.

anonymous_incognito ★★★★★
(14.01.13 02:16:41 MSK)

Ответ на: комментарий от yvv 13.01.13 22:25:34 MSK

Обсуждается утилита, которую почему-то хотят переписать с Fortran77 за 1000 рублей. Это скорее всего означает что а) она работает б) на математическую библиотеку и ускорение как бы всё равно, в) внешних библиотек не использует

Ну воспользуетесь вы оптимизирующим компилятором от фирмы XXX и будет у вас ускорение 10%, но зато вы получите массу интересных проблем связанных с линковкой если в качестве основного компилятора используется нечто от фирма YYY.

Evgueni ★★★★★
(14.01.13 05:26:11 MSK)

Ответ на: комментарий от drBatty 13.01.13 22:28:22 MSK

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

Evgueni ★★★★★
(14.01.13 05:29:40 MSK)

Ответ на: комментарий от anonymous_incognito 13.01.13 22:24:24 MSK

Не. DECовские расширения похоронили.

Evgueni ★★★★★
(14.01.13 05:31:05 MSK)

Ссылка

Ответ на: комментарий от Evgueni 14.01.13 05:26:11 MSK

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

~~yvv~~ ★★☆
(14.01.13 06:09:03 MSK)

Ответ на: комментарий от yvv 14.01.13 06:09:03 MSK

Ога, ога и _все_ внешние библиотеки (типа этой) под ним собирать? У вас весьма странные идеи по поводу отсутствия проблем.

Evgueni ★★★★★
(14.01.13 06:10:34 MSK)
Последнее исправление: Evgueni 14.01.13 06:13:13 MSK (всего исправлений: 1)

Ответ на: комментарий от Evgueni 14.01.13 06:10:34 MSK

Ога, ога и все внешние библиотеки под ним собирать?

Конечно. Не под g77 же. Это сэкономит время в итоге. Мне неприятно об этом говорить, но на сегодняшний день свободные компиляторы фортрана - полное г.... Мне вот лично хотелось бы качественного, свободного, но его же нет.

~~yvv~~ ★★☆
(14.01.13 06:15:39 MSK)

Ответ на: комментарий от Evgueni 14.01.13 06:10:34 MSK

библиотеки (типа этой) под ним собирать?

Разработчики этой библиотеки - сами себе злобные буратины. Нельзя так делать.

~~yvv~~ ★★☆
(14.01.13 06:17:17 MSK)

Ответ на: комментарий от yvv 14.01.13 06:15:39 MSK

10% _компьютерного_ кое дёшево и его легко в случае нехватки можно приобрести. Люди много дороже. Основной тормоз в мозгах.

Evgueni ★★★★★
(14.01.13 06:26:37 MSK)

Ссылка

Ответ на: комментарий от yvv 14.01.13 06:17:17 MSK

По мне так злобные буратины Intel, который не озадачился проблемой совместимости с gcc.

Evgueni ★★★★★
(14.01.13 06:27:38 MSK)

Ответ на: комментарий от Evgueni 14.01.13 06:27:38 MSK

По мне так злобные буратины Intel, который не озадачился проблемой совместимости с gcc.

Нет. Они сделали очень классный компилятор, с mkl, и mpi. Причём дают в нагрузку к железу, т.е. купил кластер, а там уже всё есть.

~~yvv~~ ★★☆
(14.01.13 06:31:48 MSK)

Ответ на: комментарий от anonymous_incognito 14.01.13 02:16:41 MSK

Ага. Я 30-50% на своих задачах вывел некоторое время назад. А вообще видно, что gfortran на некоторых задачах жестоко сливает Intel Fortran в несколько раз, но на этих же задачах другие компиляторы сливают ещё хуже, а на многих задачах отставание от IF невелико.

может заодно расскажешь, как сейчас с вопросом cc vs fortran? (просто для интереса, не флейма ради. Я в этом вопросе некомпетентен если что).

~~drBatty~~ ★★
(14.01.13 06:42:31 MSK)

Ответ на: комментарий от Evgueni 14.01.13 05:29:40 MSK

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

хм... ты наверное никогда не видел рабочих программ для MS-DOS/Win без исходников. Код есть, работает, требуется его как-то исправить (на самом деле, оно не слишком сложно, только возни много. с фортраном я наблюдал такое же).

~~drBatty~~ ★★
(14.01.13 06:46:57 MSK)

Ответ на: комментарий от drBatty 14.01.13 06:46:57 MSK

Я вообще не использую для работы программ без исходников, а выбор языка программирования на работоспособности программ весьма слабо сказывается. Основной затык в предметной области.

Evgueni ★★★★★
(14.01.13 06:55:33 MSK)
Последнее исправление: Evgueni 14.01.13 06:58:10 MSK (всего исправлений: 1)

Ответ на: комментарий от yvv 14.01.13 06:31:48 MSK

Это осмысленно если всё пишется с нуля и задача ограничена по времени — нет необходимости заботиться о переносимости. Человеческое же время много дороже компьютерного. Ну и вендор-лок тоже ничего хорошего.

Evgueni ★★★★★
(14.01.13 06:57:09 MSK)
Последнее исправление: Evgueni 14.01.13 06:59:20 MSK (всего исправлений: 2)

Ответ на: комментарий от Evgueni 14.01.13 06:55:33 MSK

Я вообще не использую для работы программ без исходников

я тоже. Однако для меня, программа на фортране ненамного лучше программы в кодах без сырцов, особенно такого плана как в первом посте.

а выбор языка программирования на работоспособности программ весьма слабо сказывается. Основной затык в предметной области.

задачи разные бывают. Часто в предметной области разберётся даже ребёнок.

~~drBatty~~ ★★
(14.01.13 07:21:20 MSK)

Ссылка

Ответ на: комментарий от Evgueni 14.01.13 06:57:09 MSK

Это осмысленно если всё пишется с нуля и задача ограничена по времени — нет необходимости заботиться о переносимости. Человеческое же время много дороже компьютерного.

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

И да, ВСЕ программы пишутся с нуля и с ограничением по времени. Изначально.

~~drBatty~~ ★★
(14.01.13 07:28:15 MSK)

Ответ на: комментарий от drBatty 14.01.13 07:28:15 MSK

Есть одно но: кроме своего кода есть ещё и код, который был написан задолго до (в качестве примера я давал ссылку на библиотеку CERNLIB — по объёму кода она сравнима с кодом ядра Linux). И даже если он переносимый, задача доказательства того, что при новом компиляторе он работает ожидаемо вполне может быть неразрешимой, поэтому со сторонними библиотеками совместимость необходима.

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

Evgueni ★★★★★
(14.01.13 08:11:13 MSK)

Ответ на: комментарий от drBatty 14.01.13 07:28:15 MSK

И да, ВСЕ программы пишутся с нуля и с ограничением по времени. Изначально.

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

Evgueni ★★★★★
(14.01.13 08:14:10 MSK)

Ссылка

Ответ на: комментарий от Evgueni 14.01.13 08:11:13 MSK

Есть одно но: кроме своего кода есть ещё и код, который был написан задолго до (в качестве примера я давал ссылку на библиотеку CERNLIB — по объёму кода она сравнима с кодом ядра Linux).

да. Мир не идеальный. Потому я и использовал слова «заботиться», и «в идеале».

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

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

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

нет конечно! сторонние библиотеки НАДО использовать, если они есть, конечно. В этом-то и заключается unix way ИМХО. Я говорю про само приложение. Если задача ТСа решается сторонней либой, то надо просто выкинуть этот код нафиг, и использовать либу. Но в рассматриваемом случае очевидно не решается. И я не думаю, что для C/C++ не написано нужной либы, хотя для фортрановского кода она таки написана.

~~drBatty~~ ★★
(14.01.13 09:50:53 MSK)

Ссылка

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

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

а написано всё по правилам и правильно, посмотри хотя-бы http://num-anal.srcc.msu.ru/

aiqu6Ait ★★★★
(14.01.13 11:38:57 MSK)

Ссылка

Ответ на: комментарий от yvv 13.01.13 22:25:34 MSK

а пруф можно? И сколько эта нагрузка будет стоить? Или железо? А то мы сейчас gfortranom пользуемся.

aiqu6Ait ★★★★
(14.01.13 11:40:30 MSK)

Ответ на: комментарий от drBatty 14.01.13 06:42:31 MSK

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

aiqu6Ait ★★★★
(14.01.13 11:45:11 MSK)

Ответ на: комментарий от aiqu6Ait 14.01.13 11:45:11 MSK

да никак.

ИМХО тогда есть смысл переписывать на C. Особенно учитывая, что судя по треду, хорошие компиляторы фортрана - коммерческие и совсем не гнутые.

~~drBatty~~ ★★
(14.01.13 12:25:21 MSK)

Ответ на: комментарий от drBatty 14.01.13 12:25:21 MSK

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

aiqu6Ait ★★★★
(14.01.13 12:34:03 MSK)

Ответ на: комментарий от aiqu6Ait 14.01.13 12:34:03 MSK

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

я не уверен. Но вообще говоря, уже лет 15 все поголовно считают математику i8087, там и какой-то IEEE на эту тему есть ЕМНИП.

И ИМХО, если автор программы ничего не напутал, и если он не использовал каких-то грязных хаков, то алгоритм по любому будет работать с допустимой погрешностью. Я не прав? (при условии, что точность моего FPU не хуже точности FPU автора конечно).

~~drBatty~~ ★★
(14.01.13 12:53:47 MSK)

Ответ на: комментарий от drBatty 14.01.13 12:53:47 MSK

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

aiqu6Ait ★★★★
(14.01.13 13:03:55 MSK)

Может для фортрана есть аналог astyle?

andreyu ★★★★★
(14.01.13 13:06:34 MSK)

Ссылка

Ответ на: комментарий от aiqu6Ait 14.01.13 13:03:55 MSK

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

дык это я и назвал «грязным хаком». Если сходимость твоего алгоритма зависит от кривизны твоего FPU - это УГ, а не алгоритм. Как-бы не набигала ошибка, алгоритм просто обязан завершаться, причём достаточно быстро. На то вычислительная математика как раз и нужна. Если мой FPU более точный, чем твой, то у меня алгоритм просто быстрее завершится, чем у тебя. Ну или также в худшем случае.

~~drBatty~~ ★★
(14.01.13 13:38:29 MSK)

Ссылка

Ответ на: комментарий от aiqu6Ait 14.01.13 11:40:30 MSK

а пруф можно?

Пруф?

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

~~yvv~~ ★★☆
(14.01.13 14:26:26 MSK)

Ответ на: комментарий от yvv 14.01.13 14:26:26 MSK

о, понял, кластер мы не потянем.

aiqu6Ait ★★★★
(14.01.13 14:31:29 MSK)

Ссылка

Подозреваю, что да. Я как-то хотел разобраться в чужом алгоритме. Исходник — на фортране. Читал-читал, да понял, что проще будет с нуля самому сделать.

~~Eddy_Em~~ ☆☆☆☆☆
(14.01.13 14:32:48 MSK)