_Ursus_ пишет:
> TB>Например, массив структур хуже по времени доступа, чем параллельные > массивы. > > Хочется услышать обоснование.
Да нет этому обоснования, потому что это не так.
Параллельные массивы делали в фортране :
-- потому что ещё не было структур (теперь уже есть)
-- потому что были ограничения один сегмент на один large-массив в DOS.
А так два массива парралельных -- это
от 2-х баз индексированое смещение получить,
или для массива структур от одной базы получить
смещение индексированное и потом ещё смещение внутри
структуры получить. Ну да, если одно поле -- на одну
операцию сложения больше. Но если одновременно доступ
к 5-6 полям, что в общем от структуры и требуется,
то наоборот, экономия может быть за счёт использования
предвычисленного смещения к началу структуры.
Cyberax пишет:
> Дело в том, что у оптимизатора Фортрана намного больше свободы — там нет > указателей (и алиасинга) и ряда других трудностей.
Что такое алиасинг ? А указатели (ссылки) в фортране есть. Есть
выделение памяти -- есть и указатели. Адресной арифметики нет, это да.
Но и в С++/С ты можешь её не использовать. В общем, всё на самом деле
зависит от качества оптимизирующего компилятора. ХОроший -- программы
будут быстрые, плохой -- будут медленные. Это естественно при условии,
что есть базовое качество программы на языке, которое обеспечивает
отсутствие деградации производительности, заложенной в самой программе.
Ну и ещё мелочи типа > computed goto помогают (их нет в С, хотя есть в определённых реализациях).
Ага, ты ещё про константы Холерита вспомни, и расскажи, как они помогают
оптимизации программ на фортране.
Здравствуйте, 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>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%. Так что думай.
Аноним 405 пишет: > > Разные люди говорят что вычислительные программы работают быстрее если > они были написаны на Fortran-е а не на C++.
Сказка из серии: "Когда мы были молодыми..."
> Что можете сказать по этому поводу.
Ну трава в прошлом веке зеленее была.
Здравствуйте, 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 библиотеки тянуть
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 — это по нашему .
.
