Здравствуйте, Programador, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

А>>Афегительный код! Твой?
P>Мой, ночами писаный!

Уволить без выходного пособия!

Аноним 405 пишет:
>
> Разные люди говорят что вычислительные программы работают быстрее если
> они были написаны на Fortran-е а не на C++.
Сказка из серии: "Когда мы были молодыми..."

> Что можете сказать по этому поводу.
Ну трава в прошлом веке зеленее была.

Erop пишет:
>
>
> Долго и лень.
> Если коротко, то фортраны промышленные обычно заточены под традиционные
> вычматы.
Вообще-то под традиционные вычматы заточены или нет руки (голова) того
програмера, который пишет.

> Типа когда матрицы с векторамии жуют. И пр этом они ещё и очень
> портабл. А С/С++ не заточены...
Опять же из области веры. На С/С++ просто больше зависит от программиста.

> Так что фортран реально удобнее быстрее и надёжнее получается...
Опять вера в серебряную пулю.

P.S. Я достаточно много раньше на фортране писал (ощущение, что в
прошлой жизни), исключительно субъективное мнение: С/С++ гораздо
удобнее, но накладывает более жесткие требования на квалификацию
программиста.
Возможно, если бы фортран развивался также как С, то, вполне возможно,
что сейчас он бы и был удобнее и эффективнее, но он остался фактически
тем же, что и был.

Добрый день,

Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
Сам ответа на этот вопрос не знаю и отношусь к этому скептически.
Что можете сказать по этому поводу.

С Уважением.

Здравствуйте, Аноним, Вы писали:


А>Добрый день,

А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
А>Сам ответа на этот вопрос не знаю и отношусь к этому скептически.
А>Что можете сказать по этому поводу.

Если они написаны хорошо на фортране и плохо на С++, то запросто.

You will always get what you always got
  If you always do  what you always did

PS собственно обращение в одной процедуре

     //  (c) Drobotenko    http://drobotenko.com
     inline static  void  invers(DMat m)
     {
       int N= dimA(m);
       int *rn=(int*)alloca((sizeof(int))*N),*cn=(int*)alloca((sizeof(int))*N);
       //int rn[N],cn[N];

       int j,k;   

       for(j=N;j--;)
         rn[j]=cn[j]=j;
       gaus_minved=1e99;
       gaus_deter=1;
       for(gaus_ostatok=N;gaus_ostatok;gaus_ostatok--)
       {  int jved,kved;
          double vved=-1,t;
          for(j=N;j--;)
          {  if(~rn[j])
             for(k=N;k--;)
               if(~cn[k])
               if(vved<fabs(m[j][k]))
                  vved=fabs(m[j][k]),jved=j,kved=k;
          }
          if(gaus_minved>vved)
             gaus_minved=vved;
          gaus_deter*=m[jved][kved];
          if(vved<1e-99)
          {  for(j=N;j--;)
             {  if(~rn[j]) for(k=N;k--;)
                  m[j][k]=_NaN();
                if(~cn[j]) for(k=N;k--;)
                  m[k][j]=_NaN();
             }
             return;
          }
          int jt=rn[jved],kt=cn[kved];
          for(j=N;j--;)
              t=m[kt][j],m[kt][j]=m[jved][j],m[jved][j]=t;
          for(j=N;j--;)
              t=m[j][jt],m[j][jt]=m[j][kved],m[j][kved]=t;

          rn[jved]=rn[kt];
          cn[kved]=cn[jt];
          rn[kt]=cn[jt]=-1;

          vved=m[kt][jt];   m[kt][jt]=1;
          for(j=N;j--;)
          {  if(j==kt)
               continue;
             double mul=m[j][jt]/vved;
             m[j][jt]=0;
             for(k=N;k--;)
               m[j][k]-=m[kt][k]*mul;
          }
          for(k=N;k--;)
              m[kt][k]/=vved;
       }
     }

против 500 строк из LINPAK

Antikrot пишет:

> нет, со ссылками/указателями далеко не всегда может (я там даже ниже
> пример — на фортране — привел). если бы алиасинг был бы только явным,
> оптимизатор точно бы знал что делать. при неявном (а он всегда будет,
> хотя бы через параметры функций/указатели, что есть в С, и в фортране)
> делается дофига проверок, и если в результате всё равно "хз",
> потенциально опасная оптимизация не делается.

Родной, common block и EQUIVALENCE такого могут нагородить,
что там чёрт ногу сломит. Оно может произвольно в принципе
накладывать байтики одного массива/структуры/объекта на
другой. О чём ты говоришь тогда ?

Всё, убеждать устал. БОльше не буду.

> а с equivalence/common block таки да, явно знает (в пределах функции),
> но кому от этого легче? сам факт наличия equivalence уже может

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

Хотя кажется, ты мой сторонник тогда извини если что.

Здравствуйте, Erop, Вы писали:


E>Это да. Сильная сторона FORTRAN -- это довольно сильная переносимость. Типа отладился на PC на задаче можельного размера гоняешь реальные размеры на супер-машинке, где время -- большие деньги

есть тесты типа такие где C/Fortran несколько ткнул — микстура. Нет хорошего свободного. Внизу результаты для чего-то там как-то хило у фортрана с воспроизводимостью. Идем к интелю здесь здесь видим у фортрана 9 фичей против 11 у Си. А интел единственный кажется поставщик фортрана для х86 на текущи момент.

Vzhyk пишет:

> Возможно, если бы фортран развивался также как С, то, вполне возможно,
> что сейчас он бы и был удобнее и эффективнее, но он остался фактически
> тем же, что и был.

"Также как С" -- это как? Никак ? А фортран очень сильно развивается,
если бы не развивался бы, давно его не было бы. Почти каждые 10 лет
стандарт новый выходит. А в последнее время вообще зачастили.

Здравствуйте, Аноним, Вы писали:


А>Добрый день,

А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
А>Сам ответа на этот вопрос не знаю и отношусь к этому скептически.
А>Что можете сказать по этому поводу.

Ищите бенчмарки, смотрите на них, пробуйте их и думайте, насколько объективно и .т.п.

Здравствуйте, Аноним, Вы писали:

А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
По-моему, это ерунда.
Скорость работы программ не зависит от того, на каком из этих двух языков они написаны.
Если вычислительные задачи достаточно хорошо реализованы и там и там, то скорость работы зависит от используемых компиляторов, а также от ключей компиляции.
Быстрее всего будут работать программы на ассемблере, если они правильны. Только программировать вычислительные задачи на ассемблере не удобно.
Если в наличии хорошие оптимизирующие компиляторы и для Fortran и для С++, то они будут работать одинаково быстро.
Т.о. программировать можно на том, на чем удобнее (лучше получается).
Еще могут играть роль доступные возможности. Например, MS VC не умеет работать с 80-битным long double, весьма полезным для многих вычислительных задач.

Здравствуйте, Аноним, Вы писали:

А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
А>Сам ответа на этот вопрос не знаю и отношусь к этому скептически.
А>Что можете сказать по этому поводу.

ИМХО, правильный ответ такой: если предельно оптимизировать по скорости вычислительный код на С++ (с учетом промахов в кэше процессора и т.п.), он станет похож на фортрановский. Например, массив структур хуже по времени доступа, чем параллельные массивы.

Здравствуйте, TheBeard, Вы писали:

TB>ИМХО, правильный ответ такой: если предельно оптимизировать по скорости вычислительный код на С++ (с учетом промахов в кэше процессора и т.п.), он станет похож на фортрановский. Например, массив структур хуже по времени доступа, чем параллельные массивы.

У меня сомнения тщательная оптимизация франтовского кода какую-то пользу приносит. Она сделана неизвестно кем и неизвестно под какой процессор. LINPAk сплошные вставки низкоуровневых процедур эта древность тянется с еще с Крееев. А FFTW выбрали для себя Си

Здравствуйте, Programador, Вы писали:


P>У меня сомнения тщательная оптимизация франтовского кода какую-то пользу приносит. Она сделана неизвестно кем и неизвестно под какой процессор. LINPAk сплошные вставки низкоуровневых процедур эта древность тянется с еще с Крееев. А FFTW выбрали для себя Си

FFTW ЕМНИП написана на Окамле, который генерит сишный код, который уже собирается в бинарник

Здравствуйте, <Аноним>, Вы писали:


А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
А>Сам ответа на этот вопрос не знаю и отношусь к этому скептически.
А>Что можете сказать по этому поводу.


Нет, это не так, другое дело что выбороптимизированных фортрановских исходников все же побольше.
Тенденция переписывания с Фортрана на С также существует(пример — CVODE), но это происходит крайне медленно.

Здравствуйте, Sergey Chadov, Вы писали:

SC>FFTW ЕМНИП написана на Окамле, который генерит сишный код, который уже собирается в бинарник
ДЛЛку пользую, исходники не смотрел . Там есть опция сборки конечно навороченные, еще и рунтайм оптимизация

Здравствуйте, Sergey Chadov, Вы писали:

SC>Нет, это не так, другое дело что выбороптимизированных фортрановских исходников все же побольше.
SC>Тенденция переписывания с Фортрана на С также существует(пример — CVODE), но это происходит крайне медленно.

уже пора на C# переводить, а они только на C переводят шутка

Здравствуйте, TheBeard, Вы писали:

TB>Например, массив структур хуже по времени доступа, чем параллельные массивы.

Хочется услышать обоснование.

Здравствуйте, Аноним, Вы писали:

Да, скорее всего так и есть. Но! Разговор не идёт о абстрактном Fortran или C++. Если мы говорим про "оптимальные" в некотором смысле реализации, скажем от производителей процессора, то да, вычисления на fortran'е будут быстрее чем на C++. Но вот, мне кажется, что не всякие вычисления. Скажем вычисленения с векторами и матрицами будут безусловно быстрее по нескольким причинам. Одна из которых, кроется в том, что сам язык для этого собственно и говоря предазначен, НО я никогда вплотную не занимался работой оптимизирующих компиляторов, поэтому не знаю, может тут C++ при ОПРЕДЕЛЁННОМ варианте написания и догонит fortran.
Вторая и более существенная причина кроется в том, что в современных процесорах есть наборы инструкций специально для выполнения некоторых векторных и матричных операций, есть такие вещи, как суперскалярность и многое другое, что делает векторные и матричные вычисления ОЧЕНЬ быстрыми(думаете GPU выдают такое дикое число Gigaflops просто так?). И если компилятор знает про все эти вкусности, то в силу устройства языка всё будет просто летать.
Я немного представляю про то что пишу, потому что работаю в организации занимающейся разработкой процессоров.

Если не убедил, то посмотрите в Википедии на чём написан LAPACK -- тот пакет на котором обязательно тестируется производительность всех суперкомпьютеров в мире.

А>Добрый день,

А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
А>Сам ответа на этот вопрос не знаю и отношусь к этому скептически.
А>Что можете сказать по этому поводу.

А>С Уважением.

Стоп. По-определению, С позволяет сделать все то же самое, что фортран. Вопрос только в трудозатратах программиста.

Здравствуйте, Аноним, Вы писали:

А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
А>Сам ответа на этот вопрос не знаю и отношусь к этому скептически.
А>Что можете сказать по этому поводу.

Ну а как вы на C++, например, напишете 2-мерную матрицу чисел, размеры которой неизвестны во время компиляции? А в Фортране это встроенный тип...

Здравствуйте, Аноним, Вы писали:

А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.

Ну, в целом, да, будет. Но если цель поставить, то на С++ будет также, а может не будет.

Здравствуйте, Pzz, Вы писали:

Pzz>Ну а как вы на C++, например, напишете 2-мерную матрицу чисел, размеры которой неизвестны во время компиляции? А в Фортране это встроенный тип...
без проблем — g++ встроенный тип...

Здравствуйте, zerone, Вы писали:

Z>Если не убедил, то посмотрите в Википедии на чём написан LAPACK -- тот пакет на котором обязательно тестируется производительность всех суперкомпьютеров в мире.

Да нет никакого быстрого LAPACK написанного на Фортране. Я както придумал алгоритм обращения квадратной матрицы более быстрый чем через LU. У меня компактная жорданоподобная схема. Говорят не может быть чтоб самописное было быстрей LAPACK , а ежели быстрей то с неправильным LAPACK сравнивается. А где канонические лапаковские алгоритмы на СПП — нетути. Дело в том что LAPACKовскае сорсы весьма ветвистые и сами ничего не делает. Это фортрановский workaround над многочисленным низкоуровневым векторным операциям типа XERBLA и т.д. канонический набор именуется BLAST, ИМХО его на ассемблере пишут. Поскольку вектора предполагаются длинными совершенно всеравно на чем сам LAPACK написан.

сравнить можно http://www.drobotenko.com/code_rus.html и здесь

Здравствуйте, Аноним, Вы писали:

А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
Это реальный факт.

Дело в том, что у оптимизатора Фортрана намного больше свободы — там нет указателей (и алиасинга) и ряда других трудностей. Ну и ещё мелочи типа computed goto помогают (их нет в С, хотя есть в определённых реализациях).

Впрочем, часть проблем с алиасингом решается с помощью ключевого слова restrict в С. А expression templates в С++ помогают автоматически оптимизировать некоторые выражения.

Здравствуйте, Programador, Вы писали:

P>PS собственно обращение в одной процедуре
P>против 500 строк из LINPAK

Афегительный код! Твой?

Здравствуйте, Sergey Chadov, Вы писали:

SC>FFTW ЕМНИП написана на Окамле, который генерит сишный код, который уже собирается в бинарник

то есть все-таки сишный код, а не фортрановский?

You will always get what you always got
  If you always do  what you always did

Аноним 405 пишет:

> Разные люди говорят что вычислительные программы работают быстрее если
> они были написаны на Fortran-е а не на C++.

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

_Ursus_ пишет:

> TB>Например, массив структур хуже по времени доступа, чем параллельные
> массивы.
>
> Хочется услышать обоснование.
Да нет этому обоснования, потому что это не так.
Параллельные массивы делали в фортране :
-- потому что ещё не было структур (теперь уже есть)
-- потому что были ограничения один сегмент на один large-массив в DOS.

А так два массива парралельных -- это
от 2-х баз индексированое смещение получить,
или для массива структур от одной базы получить
смещение индексированное и потом ещё смещение внутри
структуры получить. Ну да, если одно поле -- на одну
операцию сложения больше. Но если одновременно доступ
к 5-6 полям, что в общем от структуры и требуется,
то наоборот, экономия может быть за счёт использования
предвычисленного смещения к началу структуры.

Cyberax пишет:

> Дело в том, что у оптимизатора Фортрана намного больше свободы — там нет
> указателей (и алиасинга) и ряда других трудностей.

Что такое алиасинг ? А указатели (ссылки) в фортране есть. Есть
выделение памяти -- есть и указатели. Адресной арифметики нет, это да.
Но и в С++/С ты можешь её не использовать. В общем, всё на самом деле
зависит от качества оптимизирующего компилятора. ХОроший -- программы
будут быстрые, плохой -- будут медленные. Это естественно при условии,
что есть базовое качество программы на языке, которое обеспечивает
отсутствие деградации производительности, заложенной в самой программе.

Ну и ещё мелочи типа
> computed goto помогают (их нет в С, хотя есть в определённых реализациях).

Ага, ты ещё про константы Холерита вспомни, и расскажи, как они помогают
оптимизации программ на фортране.

Здравствуйте, Аноним, Вы писали:

А>Афегительный код! Твой?
Мой, ночами писаный!

Здравствуйте, MasterZiv, Вы писали:

MZ>Адресной арифметики нет, это да.
MZ>Но и в С++/С ты можешь её не использовать.

Это каким же образом массив в функцию без адресной арифметики передать можно?

Здравствуйте, jazzer, Вы писали:

J>то есть все-таки сишный код, а не фортрановский?
не фортрановский

Question 2.10. Why isn't FFTW written in Fortran/C++?
Because we don't like those languages, and neither approaches the portability of C.

Question 2.7. Which language is FFTW written in?
FFTW is written in ANSI C. Most of the code, however, was automatically generated by a program called genfft, written in the Objective Caml dialect of ML. You do not need to know ML or to have an Objective Caml compiler in order to use FFTW.

genfft is provided with the FFTW sources, which means that you can play with the code generator if you want. In this case, you need a working Objective Caml system. Objective Caml is available from the Caml web page.

Здравствуйте, Programador, Вы писали:

P>сравнить можно http://www.drobotenko.com/code_rus.html

А смысл сравнивать РАЗНЫЕ алгоритмы? И с чем? C Intel MKL, AMD ACML?

Здравствуйте, Programador, Вы писали:

P>PS собственно обращение в одной процедуре

P>против 500 строк из LINPAK

Нет ничего удивительного в том. что на каком-то коркретном частном случае более простой код и даже худший алгоритм окажется лучше универсального кода, написанного по последним достижениям науки. К тому же reference linpack все же не эталон производительности, нужно брать оптимизированные под конкретную платформу варианты, например Intel MKL, AMD core math library.
А код такой я бы если и написал — то точно бы постыдился показывать

Здравствуйте, MasterZiv, Вы писали:

>> Дело в том, что у оптимизатора Фортрана намного больше свободы — там нет
>> указателей (и алиасинга) и ряда других трудностей.
MZ>Что такое алиасинг ? А указатели (ссылки) в фортране есть.
http://en.wikipedia.org/wiki/Aliasing_%28computing%29

MZ>Есть выделение памяти -- есть и указатели. Адресной арифметики нет, это да.
Указатели есть в глубине реализации, в явном виде их нет.

MZ>Но и в С++/С ты можешь её не использовать. В общем, всё на самом деле
MZ>зависит от качества оптимизирующего компилятора. ХОроший -- программы
MZ>будут быстрые, плохой -- будут медленные.
У оптимизатора С++ банально меньше возможностей, так как оптимизатор Фортрана имеет право делать предположения, которые для С++ часто будут неверными.

MZ>Ага, ты ещё про константы Холерита вспомни, и расскажи, как они помогают
MZ>оптимизации программ на фортране.
Computed goto ускорило интерпретатор Питона на 20%. Так что думай.

Здравствуйте, _Ursus_, Вы писали:

TB>>Например, массив структур хуже по времени доступа, чем параллельные массивы.
_U_>Хочется услышать обоснование.

Вот занимательно расказано
http://szotin.livejournal.com/13335.html

Здравствуйте, MasterZiv, Вы писали:

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

1) Это всё сильно зависит от платформы. Всё-таки всякие разные веккторные процессоры ещё никто не отменял.
2) Если речь идёт о i86, и если вспомнить о том, что в выч. хадачах обычно все поля одного типа -- double или long double, что само по себе зависит от обстоятельств. То можно сообразить что в параллельных массивах можно использовать предвычисленное смещение в массиве

Здравствуйте, D14, Вы писали:

D14>А смысл сравнивать РАЗНЫЕ алгоритмы? И с чем? C Intel MKL, AMD ACML?
Так я и сравнивал алгоритмы — мой, с обращением матриц из LAPAk. Мой быстрее.

Здравствуйте, Sergey Chadov, Вы писали:

SC>Нет ничего удивительного в том. что на каком-то коркретном частном случае более простой код и даже худший алгоритм окажется лучше универсального кода, написанного по последним достижениям науки. К тому же reference linpack все же не эталон производительности, нужно брать оптимизированные под конкретную платформу варианты, например Intel MKL, AMD core math library.
Я сравнивал АЛГОРИТМЫ у меня ровно N^3 операций, у них больше. 2/3*N^3 на LU разложение и там еще на нахождение обратной, итого у них больше получается.

SC>А код такой я бы если и написал — то точно бы постыдился показывать
Да че в нем не так? Уж удобней чем 2 библиотеки тянуть

Здравствуйте, Programador, Вы писали:


SC>>Нет ничего удивительного в том. что на каком-то коркретном частном случае более простой код и даже худший алгоритм окажется лучше универсального кода, написанного по последним достижениям науки. К тому же reference linpack все же не эталон производительности, нужно брать оптимизированные под конкретную платформу варианты, например Intel MKL, AMD core math library.
P>Я сравнивал АЛГОРИТМЫ у меня ровно N^3 операций, у них больше. 2/3*N^3 на LU разложение и там еще на нахождение обратной, итого у них больше получается.
В жизни все как правило не так просто. Например, для решения задачи линейного программирования, например, существует алгоритм с полиномиальной сложностью(метод эллипсоидов), но пользуются все симплекс-методом, который на большинстве реальных задач значительно быстрее. Знаешь сколько статей типа "исследование производительности метода N в применении к матрицам типа M" существует? Их не просто так пишут.

SC>>А код такой я бы если и написал — то точно бы постыдился показывать
P>Да че в нем не так? Уж удобней чем 2 библиотеки тянуть

Как бы это помягче, у меня создалось впечатление, что автор намеренно пытался ввести в заблуждение читателей этого кода. Форматирование и названия переменных просто психоделические, константы типа 1e99 вызывают нервный смех Что так или не так в самом алгоритме сказать не могу — мне жалко мозг разбираться.

Здравствуйте, Programador, Вы писали:

P>PS собственно обращение в одной процедуре
...
P>против 500 строк из LINPAK

Там из 500 строк наверное половина — комментарии. Что делает код понятным. Поэтому в этом конкретно сравнении Фортран побеждает С
(C++ там как-то не видно)

Здравствуйте, Cyberax, Вы писали:

А>>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
C>Это реальный факт.
+1

C>Дело в том, что у оптимизатора Фортрана намного больше свободы — там нет указателей (и алиасинга) и ряда других трудностей.
есть там и указатели, и динамическая память (но пользуются там этим скажем так несколько меньше чем new в плюсах), и про equivalence не забудь

C>Ну и ещё мелочи типа computed goto помогают (их нет в С, хотя есть в определённых реализациях).
о да, goto там просто шедевр

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

Здравствуйте, Antikrot, Вы писали:

C>>Дело в том, что у оптимизатора Фортрана намного больше свободы — там нет указателей (и алиасинга) и ряда других трудностей.
A>есть там и указатели, и динамическая память (но пользуются там этим скажем так несколько меньше чем new в плюсах), и про equivalence не забудь
Ну это явная операция, а в С оно неявно может быть.

C>>Впрочем, часть проблем с алиасингом решается с помощью ключевого слова restrict в С.
A>это замечательно выглядит для всяких там тройных указателей
Ну не хуже const volatile, наверное

Здравствуйте, Sergey Chadov, Вы писали:

SC>Как бы это помягче, у меня создалось впечатление, что автор намеренно пытался ввести в заблуждение читателей этого кода. Форматирование и названия переменных просто психоделические, константы типа 1e99 вызывают нервный смех Что так или не так в самом алгоритме сказать не могу — мне жалко мозг разбираться.

У меня очень понятное название invers, а их DGETRI вводит меня в ступор, как и все остальные имена, кроме одного EXTERNAL ( а их там не мало ) error message related XERBLA — это по нашему .

Здравствуйте, Cyberax, Вы писали:

C>>>Дело в том, что у оптимизатора Фортрана намного больше свободы — там нет указателей (и алиасинга) и ряда других трудностей.
A>>есть там и указатели, и динамическая память (но пользуются там этим скажем так несколько меньше чем new в плюсах), и про equivalence не забудь
C>Ну это явная операция, а в С оно неявно может быть.
явно, неявно... хотите помучать фортрановский оптимизатор на предмет алиасинга (я про аргументы функций молчу)? а запросто —

integer, pointer :: P(:)
integer, target :: A(100)
integer, target :: B(100)
integer N
read (*,10) N
if(N .lt. 42) then
  P=>A
else
  P=>B
end if

! а чёрт его знает, есть тут алиасинг или нет
do i=1,100-N
  P(i) = A(i+N)
enddo

10 format (1I5)
end

ну и опять же man <любимый компилятор фортрана> | grep alias ... неспроста оно там, ой неспроста

C>>>Впрочем, часть проблем с алиасингом решается с помощью ключевого слова restrict в С.
A>>это замечательно выглядит для всяких там тройных указателей
C>Ну не хуже const volatile, наверное
точно но ведь это С(99), а не С++?

Erop пишет:

> 1) Это всё сильно зависит от платформы. Всё-таки всякие разные
> веккторные процессоры ещё никто не отменял.

Да ну естественно я на все случаи жизни не смогу расписать.

> 2) Если речь идёт о i86, и если вспомнить о том, что в выч. хадачах
> обычно все поля одного типа -- double или long double, что само по себе
> зависит от обстоятельств. То можно сообразить что в параллельных
> массивах можно использовать предвычисленное смещение в массиве
> Все эмоциональные формулировки не соотвествуют действительному положению
> вещей и приведены мной исключительно "ради красного словца". За
> корректными формулировками и неискажённым изложением идей, следует
> обращаться к их автором или воспользоваться поиском


Это я не понял. Какие--такие предвычисленные смещения можно
вычислить для параллельных массивов ?

Один массив -- это (кстати, независимо от типа и платформы)
-- адрес начала массива
-- размер элемента (возможно, 2 размера -- с выравниванием и без)
-- кол-во элементов (нужно только для контроля выхода за границы)

Далее мы по этим данным на основе индекса в массиве
вычисляем адрес в памяти элемента. Делается это
путём прибавления к базе I размеров элементов.

Так что тут можно ещё предвычислить, и так одна комманда
машинная.

Хотя наверное это уже малоинтересно.

Cyberax пишет:

>> > Дело в том, что у оптимизатора Фортрана намного больше свободы — там нет
>> > указателей (и алиасинга) и ряда других трудностей.
> MZ>Что такое алиасинг ? А указатели (ссылки) в фортране есть.
> http://en.wikipedia.org/wiki/Aliasing_%28computing%29

Тогда он ЕСТЬ и в фортране. EQUIVALENCE, COMMON BLOCK

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

Что-то я всё больше сомневаюсь. Ну да ладно.

Здравствуйте, MasterZiv, Вы писали:

>> MZ>Что такое алиасинг ? А указатели (ссылки) в фортране есть.
>> http://en.wikipedia.org/wiki/Aliasing_%28computing%29
MZ>Тогда он ЕСТЬ и в фортране. EQUIVALENCE, COMMON BLOCK
Он _явный_.

Здравствуйте, Mephisto666, Вы писали:

M>Здравствуйте, _Ursus_, Вы писали:

TB>>>Например, массив структур хуже по времени доступа, чем параллельные массивы.
_U_>>Хочется услышать обоснование.

M>Вот занимательно расказано
M>http://szotin.livejournal.com/13335.html

Автор отстал от жизни. Современные компиляторы прекрасно паплайнят циклы. Надо только не забывать restrict вставлять в нужных местах.
Оптимизация кода "параллельными" массивами -- вещь ненужная и вредная, т.к. приводит к плохо структурированному коду.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Cyberax пишет:

> MZ>Тогда он ЕСТЬ и в фортране. EQUIVALENCE, COMMON BLOCK
> Он _явный_.

А неявный это как ? ССылки / указатели ? Чем это плохо для
оптимизатора ? что он этот код не имеет ? Имеет. Что не
может разобраться, что это одно и то же ? может.

А в фортране в общем то же самое твориться.

Здравствуйте, Programador, Вы писали:

D14>>А смысл сравнивать РАЗНЫЕ алгоритмы? И с чем? C Intel MKL, AMD ACML?
P>Так я и сравнивал алгоритмы — мой, с обращением матриц из LAPAk. Мой быстрее.

Попробовал потестировать обращение матриц 2000*2000. Ваш алгоритм оказался порядка 20 раз медленнее Matlab. Подумал, что не так померил что. Сравнил с boost ublas. Не так сильно, на снова Ваш алгоритм медленнее.

matrix<double,column_major> m (n, n);
matrix<double,column_major> invm (n, n);
permutation_matrix<double> pm(m.size1());
invm.assign(identity_matrix<double>(m.size1()));
lu_factorize(m,pm);
lu_substitute(m, pm,invm);

Здравствуйте, Programador, Вы писали:

P>Здравствуйте, Sergey Chadov, Вы писали:

SC>>Как бы это помягче, у меня создалось впечатление, что автор намеренно пытался ввести в заблуждение читателей этого кода. Форматирование и названия переменных просто психоделические, константы типа 1e99 вызывают нервный смех Что так или не так в самом алгоритме сказать не могу — мне жалко мозг разбираться.

P>У меня очень понятное название invers, а их DGETRI вводит меня в ступор, как и все остальные имена, кроме одного EXTERNAL ( а их там не мало ) error message related XERBLA — это по нашему .

Это было придумано черт знает когда, когда современных понятий о качестве кода просто не существовало. И в любом случае то, что где-то еще сделано плохо — не повод делать плохо самому. А насчет понятного названия invers — лично мне логика наименования непонятна, либо мы используем распространенное сокращение "inv", либо пишем слово целиком, "inverse". Впрочем, название функции — это еще далеко не самое страшное.

Здравствуйте, Sergey Chadov, Вы писали:

SC>Это было придумано черт знает когда, когда современных понятий о качестве кода просто не существовало. И в любом случае то, что где-то еще сделано плохо — не повод делать плохо самому. А насчет понятного названия invers — лично мне логика наименования непонятна, либо мы используем распространенное сокращение "inv", либо пишем слово целиком, "inverse". Впрочем, название функции — это еще далеко не самое страшное.

Исторически, Фортран различал только первые 6 символов в названиях функций. Так что что INVERS, что INVERSE для него одно и то же. Соответственно, никто и не заморачивался писать "лишние" символы, которые ни на что не влияют.

Здравствуйте, D14, Вы писали:

D14>Здравствуйте, Programador, Вы писали:

D14>>>А смысл сравнивать РАЗНЫЕ алгоритмы? И с чем? C Intel MKL, AMD ACML?
P>>Так я и сравнивал алгоритмы — мой, с обращением матриц из LAPAk. Мой быстрее.

D14>Попробовал потестировать обращение матриц 2000*2000. Ваш алгоритм оказался порядка 20 раз медленнее Matlab. Подумал, что не так померил что. Сравнил с boost ublas. Не так сильно, на снова Ваш алгоритм медленнее.

Там полный выбор ведущего элемента ( с пропуском обработанных строк/столбцов, помеченных -1 ), обычно ограничиваются первой попавшейся строкой, на него половина времени уходит, но я предпочитаю полный.

  for(j=N;j--;)
  {  if(~rn[j])
     for(k=N;k--;)
       if(~cn[k])
       if(vved<fabs(m[j][k]))
          vved=fabs(m[j][k]),jved=j,kved=k;
  }

И если конкретный матричный шаблон DMat, то он тормознутый . На сайте еще тексты есть, где (i,j) вместо [i][j] , както нет стабильных контейнеров, часто тексты допиливаю по месту. А так хороший алгоритм, быстрый.

Здравствуйте, Programador, Вы писали:

P>Там полный выбор ведущего элемента ( с пропуском обработанных строк/столбцов, помеченных -1 ), обычно ограничиваются первой попавшейся строкой, на
Без выбора ведущего элемента там есть версия без permutation_matrix. Выбор в boost тоже есть.
P>И если конкретный матричный шаблон DMat, то он тормознутый . На сайте еще тексты есть, где (i,j) вместо [i][j] , както нет стабильных контейнеров, часто тексты допиливаю по месту.
"(i,j) вместо [i][j]" оптимизаторы давно как орехи щелкают и инлайнят, выбрасывая временные объекты строк/столбцов.

Здравствуйте, Pzz, Вы писали:


Pzz>Исторически, Фортран различал только первые 6 символов в названиях функций. Так что что INVERS, что INVERSE для него одно и то же. Соответственно, никто и не заморачивался писать "лишние" символы, которые ни на что не влияют.

Это понятно, однако ж это не повод так писать сейчас. Поэтому ИМХО нужно либо писать нормально, либо использовать хоть и уродские, но привычные имена из BLAS/LAPACK. Зачем останавливаться на полпути?

Здравствуйте, MasterZiv, Вы писали:

>> MZ>Тогда он ЕСТЬ и в фортране. EQUIVALENCE, COMMON BLOCK
>> Он _явный_.
MZ>А неявный это как ? ССылки / указатели ? Чем это плохо для
MZ>оптимизатора ? что он этот код не имеет ? Имеет. Что не
MZ>может разобраться, что это одно и то же ? может.
нет, со ссылками/указателями далеко не всегда может (я там даже ниже пример — на фортране — привел). если бы алиасинг был бы только явным, оптимизатор точно бы знал что делать. при неявном (а он всегда будет, хотя бы через параметры функций/указатели, что есть в С, и в фортране) делается дофига проверок, и если в результате всё равно "хз", потенциально опасная оптимизация не делается.

а с equivalence/common block таки да, явно знает (в пределах функции), но кому от этого легче? сам факт наличия equivalence уже может напакостить оптимизации, для которой важно выравнивание (то есть практически все simd'ы)

MZ>А в фортране в общем то же самое твориться.
да, там всё так же плохо

Здравствуйте, MasterZiv, Вы писали:

>> MZ>Тогда он ЕСТЬ и в фортране. EQUIVALENCE, COMMON BLOCK
>> Он _явный_.
MZ>А неявный это как ? ССылки / указатели ?
Да.

MZ>Чем это плохо для оптимизатора ? что он этот код не имеет ? Имеет. Что не
MZ>может разобраться, что это одно и то же ? может.
Он не может разобраться в общем случае, что алиасинга нет и делает всё пессимистично.

Здравствуйте, D14, Вы писали:

D14>Здравствуйте, Programador, Вы писали:

Так значит матрица 2000х2000 весь кэш поела, а размерчик актуальным для меня скоро станет . Правда для отладки можно тренироваться "на кошечках"

А подробней не расскажете? Сколько в минутах выходило, матлаб чем пользуется? AMD ACML мне кажется бесплатно, он к minGW линкуется? Кроме интел, амд еще кто-то может большие матрицы бороть?

Здравствуйте, Programador, Вы писали:
P>А подробней не расскажете? Сколько в минутах выходило, матлаб чем пользуется?
На Celeron 1700:
-boost ublas partial pivoting 151 сек.
-(c) Drobotenko 213 сек.
-Matlab 19 сек.
Насчет Matlaba, оказалось, я держал в голове цифры меньшей для размерности, когда писал про 20х преимущество
P> AMD ACML мне кажется бесплатно, он к minGW линкуется?
Не в курсе.
P> Кроме интел, амд еще кто-то может большие матрицы бороть?
Можно поискать по blas vendors, но по-моему под win32 только MKL и ACML в ходу. Последние версии IMSL дергают тот же MKL внутри. Матлаб использует их обе.

Здравствуйте, D14, Вы писали:

D14>На Celeron 1700:
D14>-boost ublas partial pivoting 151 сек.
D14>-(c) Drobotenko 213 сек.
D14>-Matlab 19 сек.

Странно у меня на Доу-2 2.13гг 233 сек, с полной оптимизацией. Но возможно не стоит осуждать GCC поскольку в DMat стоял мой range-chack с инлайн асм int 03.

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

Переход на указатели во внутреннем цикле + частичный поиск ведущего — 35
Переход на указатели во внутреннем цикле — 63 сек

против исходного при полной оптимизации — 233


Кэш в 10 раз ускоряе http://www.ixbt.com/cpu/rmma/yonah/ynh_mem_bw.png из http://www.ixbt.com/cpu/rmma-yonah.shtml , MKL конечно быстрая, но чудес не показывает. Думал если в 10 раз быстрее, может как-то блочно умеют влазить в кэш. Пока без них буду жить

     inline static  void  invers(DMat m)
     {
       int N= dimA(m);
       int *rn=(int*)alloca((sizeof(int))*N),*cn=(int*)alloca((sizeof(int))*N);
       //int rn[N],cn[N];

       int j,k;

       for(j=N;j--;)
         rn[j]=cn[j]=j;
       gaus_minved=1e99;
       gaus_deter=1;

         //  первый поск ведущего элемента
          double vved=-1,t;
          int next_jved,next_kved;
          for(j=N;j--;)
          for(k=N;k--;)
          if(vved<fabs(m[j][k]))
                  vved=fabs(m[j][k]),next_jved=j,next_kved=k;



       for(gaus_ostatok=N;gaus_ostatok;gaus_ostatok--)
       {  int jved=next_jved,kved=next_kved;
          if(gaus_minved>vved)
             gaus_minved=vved;
          gaus_deter*=m[jved][kved];
          if(vved<1e-99)
          {  for(j=N;j--;)
             {  if(~rn[j]) for(k=N;k--;)
                  m[j][k]=_NaN();
                if(~cn[j]) for(k=N;k--;)
                  m[k][j]=_NaN();
             }
             return;
          }
          int jt=rn[jved],kt=cn[kved];
          for(j=N;j--;)
              t=m[kt][j],m[kt][j]=m[jved][j],m[jved][j]=t;
          for(j=N;j--;)
              t=m[j][jt],m[j][jt]=m[j][kved],m[j][kved]=t;

          rn[jved]=rn[kt];
          cn[kved]=cn[jt];
          rn[kt]=cn[jt]=-1;

          vved=m[kt][jt];   m[kt][jt]=1;
          double next_vved=-1;
          int notvse=5;
          for(j=N;j--;)
          {  if(j==kt)
               continue;
             double mul=m[j][jt]/vved;
             m[j][jt]=0;


             #if 0
             for(k=N;k--;)
             //for(k=0;k<N;k++)
               m[j][k]-=m[kt][k]*mul;
             #else
             //   самый внутренний цикл через указатели
             double *mj=&m[j][0],*mkt=&m[kt][0];
             for(k=0;k<N;k++)
               mj[k]-=mkt[k]*mul;
             #endif

             #if 0
             // ограничение числа строк на поск следующего ведущего элемента
             if(notvse>0)
             #endif
             {
             if(~rn[j])
             { notvse--;
               for(k=N;k--;)
               //for(k=0;k<N;k++)
               if(~cn[k])
               if(next_vved<fabs(m[j][k]))
                  next_vved=fabs(m[j][k]),next_jved=j,next_kved=k;
             }
             }
          }
          for(k=N;k--;)
              m[kt][k]/=vved;
          vved=next_vved;

       }
     }

Здравствуйте, Programador, Вы писали:

P>Здравствуйте, D14, Вы писали:

D14>>На Celeron 1700:
D14>>-boost ublas partial pivoting 151 сек.
D14>>-(c) Drobotenko 213 сек.
D14>>-Matlab 19 сек.

P>Странно у меня на Доу-2 2.13гг 233 сек, с полной оптимизацией. Но возможно не стоит осуждать GCC поскольку в DMat стоял мой range-chack с инлайн асм int 03.
[/ccode]
Дык потому, что Intel C++. С выкинутым прочь ASSERT 130 сек.

Два аспекта:
* код целиком создаете сами;
* интенсивно пользуеетесь сторонними библиотеками.

1) Формально-то можно написать "одинаковый" по скорости. Но сильно сомневаюсь, что обычный програмер готов лезть в доки и изучать особенности архитектуры процессора (редкостные регистры и пр.). А при одинаковом алгоритме фортрановский компилятор лучше оптимизирОВАЛ (последние годы не в теме) индексные выражения. Т.е. фортрановский код чаще будет более быстрым.

2) В фортранАХ мощнейшие библиотеки по вычметодам. И если использовать их — рядового С-ишника "обыграешь" легко.
Приятель годами работает в Интеле, как раз на библиотеках. Видел примеры кода. ЭТО — не фортран и не С++! Скорей, суперпродвинутый ассемблер. Отдельные версии функций для 2/4 ядер... Но, подчеркну, библиотеки ДЛЯ фортрана.


А>Добрый день,
А>Разные люди говорят что вычислительные программы работают быстрее если они были написаны на Fortran-е а не на C++.
А>Сам ответа на этот вопрос не знаю и отношусь к этому скептически.
А>Что можете сказать по этому поводу.
А>С Уважением.

Здравствуйте, Аноним, Вы писали:


А>Приятель годами работает в Интеле, как раз на библиотеках. Видел примеры кода. ЭТО — не фортран и не С++! Скорей, суперпродвинутый ассемблер. Отдельные версии функций для 2/4 ядер...
У микрософта тоже есть некие приблуды к Си для всяких simd

А>Но, подчеркну, библиотеки ДЛЯ фортрана.
Первая попавшаяся ссылка http://software.intel.com/ru-ru/forums/95/topic/63232/ фортран даже не упоминается.

Здравствуйте, D14, Вы писали:


D14>Дык потому, что Intel C++. С выкинутым прочь ASSERT 130 сек.

Имеем 130 сек на full pivoting. Против 19 у MKL частичный. У меня на компе частичный выбор ведущего к полному как 35/65. Будет гдето 80 сек на celeron-е.

Для всех элементов матрицы делается m[j][k]-=(m[j][kv]/m[jv][kv])*m[jv][k] , за исключением мелких подробностей, которые здесь http://www.drobotenko.com/code_rus.html При продвижении по строке ( к++ ) первое, что в скобках, в регистре, второе (строка ведущего) в кэше. Я так подумал что чтение из кэша, чтение и обратная запись при промахе и арифметика будут примерно сбалансированы если ходить сразу с четырьмя строками по некешируемой матрице.

void fast4()
{   const int r=2000;
    // к..1234 это то что в кэше
    static double k1[r],k2[r],k3[r],k4[r],m[r][r];
    for(int j=r;j--;k1[j]=k2[j]=k3[j]=k4[j]=.001)
    for(int  k=r;k--;)
      m[j][k]=.002;

   // симкуляция обращения матрицы. r/4 раз проходим с ведущими [0][0] [1][1] [2][2] и  [3][3]
   for(int repeat=r/4;repeat--;)
   for(int j=3;j<r;j++)
   {  int a=m[j][0]/m[0][0],b=m[j][1]/m[1][1],c=m[j][2]/m[2][2],d=m[j][3]m[j][2]/m[3][3];
      for(int k=3;k<r;k++)
        m[j][k]-=k1[k]*a+k2[k]*b+k3[k]*c+k4[k]*d;
   }
}

и в общем не ошибся. Вышло 11 сек — таким не хитрым финтом скорость MKL достигается. Кстати еще можно через раз в обратном направлении строки перебирать, чтоб остатки, которые в кэше подобрать. А с полным перебором так не получится

PS minGW запятую сожрал без ошибки и предупреждения double k1[r],k2[r],k3[r],k4[r],m[r][r] , ;

P>можно через раз в обратном направлении строки перебирать, чтоб остатки, которые в кэше подобрать. А с полным перебором так не получится
Не получится по 4, а в обратном направлении чередовать можно

Здравствуйте, MasterZiv, Вы писали:

MZ>Так что тут можно ещё предвычислить, и так одна комманда
MZ>машинная.

Разные команды выполняются разное время...

MZ>Хотя наверное это уже малоинтересно.
Это да. Сильная сторона FORTRAN -- это довольно сильная переносимость. Типа отладился на PC на задаче можельного размера гоняешь реальные размеры на супер-машинке, где время -- большие деньги

Здравствуйте, Vzhyk, Вы писали:

V>Аноним 405 пишет:
>>
>> Разные люди говорят что вычислительные программы работают быстрее если
>> они были написаны на Fortran-е а не на C++.
V>Сказка из серии: "Когда мы были молодыми..."

>> Что можете сказать по этому поводу.
V>Ну трава в прошлом веке зеленее была.
Егор, единственный раз здесь на минус мне стало интересно с чем ты не согласен? Высказался бы уж.

Здравствуйте, Vzhyk, Вы писали:

V>Егор, единственный раз здесь на минус мне стало интересно с чем ты не согласен? Высказался бы уж.

Долго и лень.
Если коротко, то фортраны промышленные обычно заточены под традиционные вычматы. Типа когда матрицы с векторамии жуют. И пр этом они ещё и очень портабл. А С/С++ не заточены...
Так что фортран реально удобнее быстрее и надёжнее получается...

Здравствуйте, Programador, Вы писали:

P>есть тесты типа такие где C/Fortran несколько ткнул — микстура. Нет хорошего свободного. Внизу результаты для чего-то там как-то хило у фортрана с воспроизводимостью. Идем к интелю здесь здесь видим у фортрана 9 фичей против 11 у Си. А интел единственный кажется поставщик фортрана для х86 на текущий момент.

Это всё не важно.
Во-первых, FORTRAN, заточен под конкретные задачи, на них он и хорош. На других -- не очень...
Ну и, во-вторых, кого интересует производительность на РС? На РС надо отладиться, а реальный прогон делают на тачке помощнее

Здравствуйте, Vzhyk, Вы писали:

V>Вообще-то под традиционные вычматы заточены или нет руки (голова) того
V>програмера, который пишет.

На С нужен намного более "заточенный" программист...

V>Опять же из области веры. На С/С++ просто больше зависит от программиста.
Ну дык больше от программиста, меньше от языка...

>> Так что фортран реально удобнее быстрее и надёжнее получается...
V>Опять вера в серебряную пулю.
Просто опыт...

V>P.S. Я достаточно много раньше на фортране писал (ощущение, что в
V>прошлой жизни), исключительно субъективное мнение: С/С++ гораздо
V>удобнее, но накладывает более жесткие требования на квалификацию
V>программиста.
Ну если квалификация нужна выше, то язык значит подходит меньше

V>Возможно, если бы фортран развивался также как С, то, вполне возможно,
V>что сейчас он бы и был удобнее и эффективнее, но он остался фактически
V>тем же, что и был.

Так и хорошо. Как был машинкой для пережёвывания матриц, так и остался...

А зачем тебе было знать, с чем именно я несогласен, кстати? Ты же не понял что я написал

Здравствуйте, Erop, Вы писали:

E> На РС надо отладиться, а реальный прогон делают на тачке помощнее

Эти бенчмарки-2006 и были на тачка помощнее Xeon 2.5GHz with 16G memory machine. The operation system is 64bits Линух какойто

416.gamess     Fortran     abormal exit
465.tonto     Fortran     compile error
436.cactusADM     C/Fortran     fatal: fault (unalign) detected @ PC 0x120026614
410.bwaves     Fortran     o.k.
437.leslie3d     Fortran     o.k.
459.GemsFDTD     Fortran     o.k.
434.zeusmp     Fortran     output is different with the reference
435.gromacs     C/Fortran     output is wrong, mremap has problem
481.wrf     C/Fortran     STOP wrf_abort. Need library

Здравствуйте, Erop, Вы писали:

E>Ну и, во-вторых, кого интересует производительность на РС? На РС надо отладиться, а реальный прогон делают на тачке помощнее
Кстати на sf.net есть несколько студий для удаленной отладки, даже одна китайская — с виду красивые.