Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Fortran > [General] Сомнения в необходимости языка

Автор: kemiisto 18.1.2009, 13:44

Цитата

А зачем, все равно я на нем не пишу [ 9 ] [64.29%]

Забавно, однако. Даже среди тех, кто заходит в тему, большинству FORTRAN уже не нужен. smile

Не помню, где то читал, что смерть ALGOL'а (PASCAL'я ?) как языка для научных и инженерных вычислений была в первую очередь обусловлена отсутствием поддержки крупных корпораций. А вот FORTRAN'у больше повезло. А мне, соответственно, меньше smile

- навеяно попытками чтения FORTRAN'овского кода. smile

Ну, да ладно, это всё оффтоп.

Cr@$h, а есть хоть сколь-нибудь достоверные данные (если такие вообще существуют smile

) об эффективности FORTRAN? Т.е. бенчмарки в сравнении с C, C++, ... Просто интересно вот что. Обычно, когда "пиарять" FORTAN, скорость исполнения кода - основной аргумент. Но, что я вижу на http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ifc&lang2=fpascal? Free Pascal уже в спину дышит... smile

Автор: Cr@$h 18.1.2009, 14:25

Цитата(kemiisto @ 18.1.2009, 14:44

)

А зачем, все равно я на нем не пишу [ 9 ] [64.29%]

Тогда можно сразу не стандартизовывать сразу даже многие другие развивающиеся языки, не говоря уже о мастодонтах. Ada вообще не нуждается в стандартах новых, да..

Цитата(kemiisto @ 18.1.2009, 14:44

)

Перегруженный Algol 68 по большей части.

Цитата(kemiisto @ 18.1.2009, 14:44

)

навеяно попытками чтения FORTRAN'овского кода

Почитай любой код давности того кода, что ты читал. Это раз. Мы говорим по современное положение дел. Там, где другие языки утопают в циклах, Fortran элегантно записывает всё в несколько строк, повышая уровень абстракции и надёжность кода. Там, где на других языках спотыкаются об ошибки программисты при выполнении программ, спотыкается компилятор Fortran ещё на стадии трансляции.

Цитата(kemiisto @ 18.1.2009, 14:44

)

есть хоть сколь-нибудь достоверные данные (если такие вообще существуют smile ) об эффективности FORTRAN?

Дай определение эффективности, что ты понимаешь. Да, производительные программы на Fortran писать эффективнее -- намного больше шансов, что быстрее напишешь верно.

Ту страницу лучше даже не открывать. Скажи, как ты вообще напишешь на Free Pascal программу, которая будет работать на 4-ядерном процессоре, и при этом потратишь на это меньше времени. У тебя и времени больше уйдёт на разработку до определённого процента ошибок, и работать будет дольше, а если ты пишешь не в своём гараже и твой код собираются повторно использовать, то икать будешь часто, поверь мне.

Автор: kemiisto 18.1.2009, 14:43

Цитата(Cr@$h @ 18.1.2009, 12:25

)

Почитай любой код давности того кода, что ты читал. Это раз.

Код новый. Профессионализм писавших сомнения не вызывает.

Цитата(Cr@$h @ 18.1.2009, 12:25

)

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

Это всё - лозунги. Если можно, примеры.

Цитата(Cr@$h @ 18.1.2009, 12:25

)

Дай определение эффективности, что ты понимаешь.

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

Автор: Cr@$h 18.1.2009, 15:13

Цитата(kemiisto @ 18.1.2009, 15:43

)

Код новый. Профессионализм писавших сомнения не вызывает.

Приведи код, приведи его на Pascal, посмотрим.

Цитата(kemiisto @ 18.1.2009, 15:43

)

Это всё - лозунги. Если можно, примеры.

Баш на баш. Если я приведу тебе реальный пример из 12 строк, не включая пару-тройку строк на объявления переменных, ты обещаешь привести его аналог на Pascal, чтобы я мог не показать, а объяснить, почему на Fortran шансов больше? Тогда предыдущий абзац отменяется.

Цитата(kemiisto @ 18.1.2009, 15:43

)

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

Всё. Pascal отстаёт в 3,5 раза где-то. Вопрос закрыт. Или скажи, как будешь распараллеливать приложение под 4 ядра.

Автор: kemiisto 18.1.2009, 15:23

Цитата(Cr@$h @ 18.1.2009, 13:13

)

Если я приведу тебе реальный пример из 12 строк, не включая пару-тройку строк на объявления переменных, ты обещаешь привести его аналог на Pascal, чтобы я мог не показать, а объяснить, почему на Fortran шансов больше? Тогда предыдущий абзац отменяется.

Лады, токлько я не обязательно за PASCAL попытаюсь аналог привести.

Автор: Cr@$h 18.1.2009, 18:01

Цитата(kemiisto @ 18.1.2009, 16:23

)

Лады, токлько я не обязательно за PASCAL попытаюсь аналог привести.

Хорошо, но Matlab не в счёт, мы его не касались. А с Pascal я бы тебе помог или с Delphi.

Гауссово исключение с частичным выбором ведущего элемента.
Подробности алгоритма, если интересно почитай там, где тебе удобно в Инете.

Код


subroutine Gauss(N, A, IPvt)
    integer, intent(in) :: N
    real, intent(inout) :: A(N, N)
    integer, intent(out) :: IPvt(N)
                
    real :: Work(N)
    integer :: k, M

    do k = 1, N - 1
        ! Поиск ведущего элемента.
                    
        M = MaxLoc( Abs( A(k:N, k) ), dim = 1 ) + k - 1
        IPvt(k) = M
        if( M /= k )&
            IPvt(N) = - IPvt(N)

        ! Пропуск этот шага, если ведущий элемент равен нулю.
        if( A(M, k) /= 0. ) then
            ! Перестановка.
            Work(k:N) = A(M, k:N)
            A(M, k:N) = A(k, k:N)
            A(k, k:N) = Work(k:N)

            ! Вычисление множителей.
            A(k+1:N, k) = -A(k+1:N, k) / work(k)
                        
            ! Исключение.
            A(k+1:N, k+1:N) = A(k+1:N, k+1:N) + Spread(A(k+1:N, k), 2, N-k-2) * Spread(Work(k+1:N), 1, N-k-2)
        end if
    end do
end subroutine Gauss

Как я и обещал, начиная с первого императивного оператора и заканчивая последним (а это цикл do), всего задействовано 12 операторных строк, if разделил, т.к. у меня такой стиль.

Не поверишь, но ты тоже знаешь Fortran, т.к. наверняка знаешь кого-то из потомков от его первых версий. Дам пояснения.

Код


M = MaxLoc( Abs( A(k:N, k) ), dim = 1 ) + k - 1

Ищется номер максимального по модулю элемента в k-ом столбце, начиная с k-ой строчки и до N (A(k:N, k)).

Код


Work(k:N) = A(M, k:N)

В элементы k:N массива Work заносятся элементы k:N строки M матрицы A.

Код


A(k+1:N, k) = -A(k+1:N, k) / work(k)

Соответствующие элементы столбца k берутся с обратным знаком и все делятся на число work(k) (ведущий элемент).

Код


A(k+1:N, k+1:N) = A(k+1:N, k+1:N) + Spread(A(k+1:N, k), 2, N-k-2) * Spread(Work(k+1:N), 1, N-k-2)

К элементам матрицы A(k+1:N, k+1:N) прибавляются соответствующие элементы матрицы, получаемой произведением к-ого столбца (его части) A(k+1:N, k) на строку Work(k+1:N) (её часть).

Добавлено @ 18:02
Тему потом разделю.

Автор: Фантом 18.1.2009, 19:03

Цитата(kemiisto @ 18.1.2009, 13:44

)

Просто интересно вот что. Обычно, когда "пиарять" FORTAN, скорость исполнения кода - основной аргумент. Но, что я вижу на простых тестах? Free Pascal уже в спину дышит...

Эти "простые тесты" - чушь полная. Если на всех языках писать "в стиле C++", то именно C++ и выиграет, что неудивительно.
Вот, например, n-body из этого набора тестов. За такой код на Фортране:

Код


  subroutine offsetMomentum(k, bodies)
    integer, intent(in) :: k
    type(body), dimension(:), intent(inout) :: bodies
    real*8 :: px, py, pz
    px = 0.0d0
    py = 0.0d0
    pz = 0.0d0
    do i=1,size(bodies)
       px = px + bodies(i)%vx * bodies(i)%mass;
       py = py + bodies(i)%vy * bodies(i)%mass;
       pz = pz + bodies(i)%vz * bodies(i)%mass;
    end do
    bodies(k)%vx = -px/SOLAR_MASS
    bodies(k)%vy = -py/SOLAR_MASS
    bodies(k)%vz = -pz/SOLAR_MASS
  end subroutine offsetMomentum

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

Автор: kemiisto 18.1.2009, 19:14

Цитата(Cr@$h @ 18.1.2009, 16:01

)

А с Pascal я бы тебе помог или с Delphi.

Ну, возьмём, например, реализацию вот http://alglib.sources.ru/linequations/obsolete/gaussm.php:

Код


function GaussSolveM(A : TReal2DArray;
     const N : Integer;
     var X : TReal1DArray;
     const Epsilon : Double):Boolean;
var
    I : Integer;
    J : Integer;
    K : Integer;
    M : Double;
    T : Double;
begin
    A := DynamicArrayCopy(A);
    SetLength(X, N+1);
    Result := True;
    i:=1;
    while i<=n do
    begin
        k := i;
        m := AbsReal(a[i,i]);
        j:=i+1;
        while j<=n do
        begin
            if m<AbsReal(a[j,i]) then
            begin
                m := AbsReal(a[j,i]);
                k := j;
            end;
            Inc(j);
        end;
        if AbsReal(m)>0 then
        begin
            j:=i;
            while j<=n+1 do
            begin
                t := a[i,j];
                a[i,j] := a[k,j];
                a[k,j] := t;
                Inc(j);
            end;
            k:=i+1;
            while k<=n do
            begin
                t := a[k,i]/a[i,i];
                a[k,i] := 0;
                j:=i+1;
                while j<=n+1 do
                begin
                    a[k,j] := a[k,j]-t*a[i,j];
                    Inc(j);
                end;
                Inc(k);
            end;
        end
        else
        begin
            Result := False;
            Break;
        end;
        Inc(i);
    end;
    if Result then
    begin
        i := n;
        repeat
            x[i] := a[i,n+1];
            j := i+1;
            while j<=n do
            begin
                x[i] := x[i]-a[i,j]*x[j];
                j := j+1;
            end;
            x[i] := x[i]/a[i,i];
            i := i-1;
        until  not (i>=1);
    end;
end;

Cr@$h, только давай не будем меряться количеством строк. На том же Ruby http://ru.wikibooks.org/wiki/Ruby/%D0%9C%D0%B0%D1%82%D1%80%D0%B8%D1%86%D1%8B_%D0%B8_%D0%B2%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D1%8B. smile

Это не показатель. Хотя в случае Ruby итераторы трудно причислить к императивному стилю...

Что видно сразу, так то, что в FORTRAN матричная арифметика (и не только арифметика) есть, что называется, "из коробки". А в PASCAL нету, зато есть в PASCAL-XSC. Код на последнем не привожу, ибо несмотря на обладание двумя книжками, руки так и не дошли. А ещё эти интервальные вычисления... smile

Но, это ладно.

Цитата(Cr@$h @ 18.1.2009, 16:01

)

Дам пояснения.

Не помогло, я всё равно ничего не понял. smile

Ну и ладно. Меня больше интересует, почему же всё таки

Цитата(Cr@$h @ 18.1.2009, 12:25

)

производительные программы на Fortran писать эффективнее -- намного больше шансов, что быстрее напишешь верно.

Даже пусть и в сравнении с приведённым кодом Delphi.

Автор: Cr@$h 18.1.2009, 19:51

Цитата(Фантом @ 18.1.2009, 20:03

)

тупо скопировал структуры из C++ (судя по текстам, "базовым" языком был именно он)

Даже точки с запятой остались smile

)

Цитата(Фантом @ 18.1.2009, 20:03

)

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

Физику задачи я из кода не понял. А что допустимо менять там? В первом приближении хотя бы так:

Код


subroutine offsetMomentum(k, bodies)
    integer, intent(in) :: k
    type(body), dimension(:), intent(inout) :: bodies
    bodies(k)%vx = -Dot_Product(bodies(:)%vx, bodies(:)%mass)/SOLAR_MASS
    bodies(k)%vy = -Dot_Product(bodies(:)%vy, bodies(:)%mass)/SOLAR_MASS
    bodies(k)%vz = -Dot_Product(bodies(:)%vz, bodies(:)%mass)/SOLAR_MASS
end subroutine offsetMomentum

Если можно изменить структуру body в двумерный массив, то я бы не то, что процедуру укоротил, сам вызов бы её свёл к строчке smile

Код


bodies(k,1:3) = - MatMul(bodies(:,4), bodies(:,1:3)) / SOLAR_MASS

Но С-программисты не привыкли мыслить в терминах исходных задач. Просто надо привыкнуть к этому.

Добавлено через 10 минут и 40 секунд

Цитата(kemiisto @ 18.1.2009, 20:14

)

Cr@$h, только давай не будем меряться количеством строк.

Неет, не будем. Мы же не в детском саду в туалете. smile

Цитата(kemiisto @ 18.1.2009, 20:14

)

На том же Ruby строчек будет меньше.

Неа. Её физически не записать короче, только если нет встроенной функции обмена значениями двумя массивами. И помни, мы говорили про эффективность. Ruby отдыхает. Давай честно.

Цитата(kemiisto @ 18.1.2009, 20:14

)

Что видно сразу, так то, что в FORTRAN матричная арифметика (и не только арифметика) есть, что называется, "из коробки". А в PASCAL нету, зато есть в PASCAL-XSC. Код на последнем не привожу, ибо несмотря на обладание двумя книжками, руки так и не дошли. А ещё эти интервальные вычисления...

PASCAL-XSC для интервальный вычислений и создавался. Они есть и в некоторых реализациях Fortran.

Цитата(kemiisto @ 18.1.2009, 20:14

)

производительные программы на Fortran писать эффективнее -- намного больше шансов, что быстрее напишешь верно.

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

Поражён.

P.S. Оттуда больше подходит пример с LU-разложением, но не суть важно. Вывод ясен и доказан, я считаю.

Добавлено через 11 минут и 41 секунду
Параллельно по бокам наших с тобой изысканий я сократил процедуру из С++ до одной строчки.

Автор: Фантом 18.1.2009, 20:04

Цитата(Cr@$h @ 18.1.2009, 19:51

)

Если можно изменить структуру body в двумерный массив, то я бы не то, что процедуру укоротил, сам вызов бы её свёл к строчке

Вот именно, так и надо было сделать - если писать программу на Фортране, а не "подстрочный перевод" с другого языка. smile

Цитата(Cr@$h @ 18.1.2009, 19:51

)

Но С-программисты не привыкли мыслить в терминах исходных задач. Просто надо привыкнуть к этому.

Самое забавное, что в терминах исходной задачи наиболее адекватным вариантом будет именно эта одна строчка. Просто в C/C++ нет средств для такой ее реализации.

Автор: kemiisto 18.1.2009, 20:13

Цитата(Cr@$h @ 18.1.2009, 17:51

)

PASCAL-XSC для интервальный вычислений и создавался.

Cr@$h, BTW, а как по-твоему, оно вообще нужно (интервальные вычисления)? Интересно просто...

Цитата(Cr@$h @ 18.1.2009, 17:51

)

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

Я не спорю и не шучу. Я не о том спрашивал. А с этим то я согласен естественно.

Цитата(Cr@$h @ 18.1.2009, 17:51

)

Поражён.

Чем?

Цитата(Cr@$h @ 18.1.2009, 17:51

)

Вывод ясен и доказан, я считаю.

Ну...

Добавлено через 3 минуты и 22 секунды
Чтобы я убедился окончательно - надо самому "пощупать".

Автор: Cr@$h 18.1.2009, 20:17

Цитата(kemiisto @ 18.1.2009, 21:13

)

как по-твоему, оно вообще нужно (интервальные вычисления)

Помогают чувствовать себя некоторым людям хорошо, ведь получаем не просто result, а result +- delta. Это если симметрично описывать погрешность вычислений. Такой подход требует иногда существенной модификации алгоритмов, ведь иногда можно получить result +- оо

Автор: kemiisto 18.1.2009, 20:24

Цитата(Cr@$h @ 18.1.2009, 18:17

)

Такой подход требует иногда существенной модификации алгоритмов, ведь иногда можно получить result +- оо

Да, я заметил. smile

Cr@$h, я ещё раз извиняюсь за оффтоп, устроенный в этой теме, ты бы не мог "подкинуть" ссылочку на хороший учебник по FORTRAN'у.

P.S. А почему нет подраздела FORTRAN в Красной книге? 3/4 (навскидку) вопросов касаются именно этого языка. LISP, Prolog, ... smile

Автор: Cr@$h 18.1.2009, 20:50

Цитата(kemiisto @ 18.1.2009, 21:24

)

Cr@$h, я ещё раз извиняюсь за оффтоп, устроенный в этой теме, ты бы не мог "подкинуть" ссылочку на хороший учебник по FORTRAN'у.

Ничего страшного. По-моему, только польза. Эту тему я вообще на 5 распиливаю.. В форуме Винград Литература -- Разыскивается. Посмотри Бартеньева или Рыжикова. Когда-то сам с Бартеньева начинал.

Цитата(kemiisto @ 18.1.2009, 21:24

)

P.S. А почему нет подраздела FORTRAN в Красной книге? 3/4 (навскидку) вопросов касаются именно этого языка. LISP, Prolog, ...

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

Автор: Фантом 18.1.2009, 21:15

Цитата(Cr@$h @ 18.1.2009, 20:50

)

Есть, кстати, еще книга А.М.Горелик "Программирование на современном Фортране". Это, пожалуй, лучший вариант - в остальных книгах авторы очень часто либо тянут "хвосты" устаревших стандартов языка, либо ориентируются на конкретные компиляторы (как правило - далеко не самый удачный Microsoft'овский). Впрочем, у Бартеньева и Рыжикова книги действительно неплохие.

Автор: Иванофф 19.1.2009, 00:55

Цитата(Cr@$h @ 18.1.2009, 19:51)

Физику задачи я из кода не понял. А что допустимо менять там? В первом приближении хотя бы так:

Код


subroutine offsetMomentum(k, bodies)
    integer, intent(in) :: k
    type(body), dimension(:), intent(inout) :: bodies
    bodies(k)%vx = -Dot_Product(bodies(:)%vx, bodies(:)%mass)/SOLAR_MASS
    bodies(k)%vy = -Dot_Product(bodies(:)%vy, bodies(:)%mass)/SOLAR_MASS
    bodies(k)%vz = -Dot_Product(bodies(:)%vz, bodies(:)%mass)/SOLAR_MASS
end subroutine offsetMomentum

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

чем плоха книга Горелик - теоретическим походом. Читать надо все подряд и не только по фортрану.

Автор: Cr@$h 19.1.2009, 07:07

Законные замечания, но.. не верьте своим глазам, не стоит всё буквально понимать.

Цитата(Иванофф @ 19.1.2009, 01:55

)

один цикл заменили на 3

Во-первых, выбор промежуточных переменных передан компилятору. Во-вторых, кто вам сказал, что эти три цикла будут выполнятся как три? В-третьих, это было первое промежуточное приближение. При такой записи лучше видно, что делать дальше. т.к. задачу приходилось поднимать снизу вверх с "низкоуровнего" С++. При записи же потом в одну строчку на полную катушку будет работать векторизация, а это ~x3.х при больших значениях.

Цитата(Иванофф @ 19.1.2009, 01:55

)

чем плоха книга Горелик - теоретическим походом.

А лично я её и не открываю. Она считает, что в Fortran есть указатели. Это не компетентно, формальный перевод, расходящаяся с практикой теоретическая обрисовка.