» Работа с Intel Fortran через Visual Studio 2003 и не только

dima333a

Цитата:

писать новые куски кода

Не надо.
Насколько я понял, просто оптимизация делается в ручную


Цитата:

не жесткие оптимизации

Наверное стоит их и использовать.

А для жестких можно попробовать такой вариант:
Есть проги, которые позволяют подменять инфу по железу
Обозвать Атлон Р3 - глядишь и заработает...


Цитата:

что за форум

Форум сообщества общежития МГУ.
Но я бы не стал его рекомендовать как хороший форум по программированию, особенно на фортране. Похоже там только мы двое работаем с фортраном.
Но если очень хочется - могу ссылку дать.

KChernov


Цитата:

Насколько я понял, просто оптимизация делается в ручную

Просто подпрограммы функций которые были заложенны в возможностях компилятора, были замененны на написанные им самим.... по крайне мере так я понял содержимое make файла....



Цитата:

А для жестких можно попробовать такой вариант:
Есть проги, которые позволяют подменять инфу по железу
Обозвать Атлон Р3 - глядишь и заработает...

Точно не заработает. Athlon и Pentium III только условно похожи друг на друга, т.к. конвеер у них одинаково короткий по сравнению с архитектурой NetBurts @ Pentium4. А в деталях Pentium III и Атthlon очень даже разные.

коллеги, а вы IMSL пользуетесь? Хотелось бы на эту темку поговорить, но решил новый топик не открывать. Меня лично там сейчас вот что интересует

1) функции по решению нелинейных уравнений,
2) работа с разреженными матрицами.

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

azertyuu

Библиотеками я не пользуюсь. Но ИМХО , библиотеки написанны были для того что бы люди не изобретали велосипед во второй раз. Т.е. это грубо говоря оптимизированные решения их учебников.

Для решения простого уравнения как вы уже сами написали, можно простенкую програмку и самому написать, а если что то посложней? К тому же , узконаправленные решения буду всегда более эффективны. Т.е. для решения какого-то определенного типа уравнений написать решатель проще чем относительно универсальный решатель.

Соответственно для универсального решателя надо больше входных параметров.

Цитата:

Библиотеками я не пользуюсь. Но ИМХО , библиотеки написанны были для того что бы люди не изобретали велосипед во второй раз.

Дык про то ж и разговор. Но интересно было бы увидеть кого-нибудь, кто в реальности пользуется IMSL (не в качестве источника кода для своих программ,а "as is" - то есть именно подсоединять библиотеку и вызывать ее родные функции.

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

Цитата:

пример с использованием len_trim()

http://softwareforums.intel.com/ids/board/message?board.id=5&message.id=6164

azertyuu
Спасибо, разобрался

А вот еще вопрос по самому фортрану (хотя мб стоит отдельную тему создать?..):

Как передать в процедуру только массив, а индексы выдернуть из него, а не передавать как параметры?

KChernov


Цитата:

Как передать в процедуру только массив, а индексы выдернуть из него, а не передавать как параметры?

Не уверен что в тему, и что вам это поможет, но я длительное время пользовался программой на FORTRAN где была использованна система pointer-ов. Если знаете что это такое то может поможет.


А вообще в FORTRAN, все массивы реально одномерные. Т.е. как я думаю можно создать массив Alpha(1:20,1:20,1:20) a передать его в подпрограмму как

program test
integer:: A
real Alpha(1:20,1:20,1:20)
A=20*20*20
call podpr(Alpha,A)
end


subroutine podpr(Beta,B)
integer:: B
real Beta(1:B)
...........
..........
return


З.Ы. Думаю что если жестко задать индексы в подпрограмме и основной программе то все тоже будет работать


program test
real Alpha(1:20,1:20,1:20)
call podpr(Alpha)
end


subroutine podpr(Beta)
real Beta(1:20,1:20,1:20)
...........
..........
return


A еще индексы можно задать один раз в include файле, а потом его прописать в основную программу и подпрограмму


файл include.fhp
INTEGER, parameter::A=20
INTEGER, parameter::B=20
INTEGER, parameter::C=20

end of file include.fhp


program test
INCLUDE 'include.fhp'
real:: Alpha(A,B,C)
call podpr(Alpha)
end


subroutine podpr(Beta)
INCLUDE 'include.fhp'
real::Beta(A,B,C)
...........
..........
return

dima333a

Цитата:

система pointer-ов

А кусок из этой проги не выложите?
В поинтере есть инфа о размерностях массива?


Цитата:

все массивы реально одномерные

Возможно из-за этого и приходится передавать размерности
Но хотя бы общую длину массива получить можно?

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


Цитата:

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

Будет, конечно. Только действительно лучше использовать константы.
Вместо include-а возможно лучше будет использовать common-блоки переменных.

Но гораздо интереснее было бы описывать измерения массива одной переменной
А то для 7-мерного массива, например, вообще говоря надо 14 чисел для описания измерений (и все это передавать через параметры процедуры не хочется)

KChernov


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


call podpr( Alpha(10)) - отправляем массив Alpha начиная с 10-го элемента. Но, там в подрограмме всеравно надо знать размер масива.


Одномерность массивов в FORTRAN реально описана во многих книгах. ИМХО это стандарт. Типичный пример оптимизаций когда надо обойти многомерный массив через DO циклы. Вот например два варианта абсолютно неиквевалентных по скорости:


DO i
DO k
alpha(i,k)
END DO
END DO

DO к
DO i
alpha(i,k)
END DO
END DO


Насчет
Цитата:

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

Как то мне надо было написать программу для двумерной численной модели, геометрия: большой прямоугольник разбитый сеткой на маленькие. 200 елементов на 300 елементов. Некоторые части программы было удобно писать для столбцов и строк в сетке, соответственно я использовал индексацию массива как (i,j)
i-строка, j-столбец. соответственно элемент (10,5) -5-й элемент в 10-й строке, или 10-й элемент в пятом столбце . С другой стороны решатель был использован Gauss-Seidel - там нет необходимости в двумерной индексации, i*J элементов, i*j уравнений. Соответственно я теже массивы использовал с как одномерные



Цитата:

Будет, конечно. Только действительно лучше использовать константы.
Вместо include-а возможно лучше будет использовать common-блоки переменных.

include - это не заменитель common block. Идея include в том что бы не задумыватся и не прописывать много преременных и common block в каждой подпрограмме. Один раз задал переменные (и common bloks кстати в include прописать тоже можно) а потом вставляеш весь набор переменных одним стейтментом. В больших программах, когда переменных много, очень помогает.... ( представте если какуюто переменную надо править... а проинициализированна она в каждой подпрограмме.... )

A для констант так вообще зачем common block? include делает свое дело.


Цитата:

Но гораздо интереснее было бы описывать измерения массива одной переменной
А то для 7-мерного массива, например, вообще говоря надо 14 чисел для описания измерений (и все это передавать через параметры процедуры не хочется)

Пользуйтесь include и будет вам счасьтье. Один раз в include прописали параметры массивов, и все !


З.Ы. Приведите пример программа и подпрограмма: обе испозуют common blok что бы не передавать значения через call. А потом подумайте как бы это выглядело с использованием include и common blok. А теперь представте что подпрограмм у вас очень много и все они используют теже самые переменные..

dima333a

Цитата:

просто не обязательно сначала

Это и без поинтеров можно сделать - сечением массива.


Цитата:

Пользуйтесь include и будет вам счасьтье. Один раз в include прописали параметры массивов, и все !

И как это сделать одной переменной?

KChernov


Цитата:

И как это сделать одной переменной?

Не совсем понял вопрос... По конкретнее можно?

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

Include позволяет вам не передавать размерности массивов при вызовах подпрограммы, сколько бы этих размерностей небыло (хоть одна, хоть семь), а жестко прописать размерности массивов в одном месте, и включать их во все необходимые подпрограммы одной строчкой.... T.e. можно зделать так что бы подпрограммы вообще вызывались без аргументов, а все идет через common block с save стейтментом, прописанными в хидер файле. А хидер включен через include в основную программу и подпрограммы.

Цитата:

А вот еще вопрос по самому фортрану (хотя мб стоит отдельную тему создать?..):

может и надо раз пошла такая пьянка


Цитата:

Как передать в процедуру только массив, а индексы выдернуть из него, а не передавать как параметры?

передаешь в процедуру только массив, а потом узнаешь его размер при помоши команды size().

dima333a

Цитата:

И как это сделать одной переменной?
Не совсем понял вопрос... По конкретнее можно?

Например:
d = '-5:5,0:10,-1:1'
real a(d) ! чтобы было бы то же самое, что и real a(-5:5,0:10,-1:1)

Ну или массивом размерности задавать, например, как в reshape...



Цитата:

жестко прописать размерности массивов в одном месте

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

Хочу развеять некоторые заблуждения по поводу оптимизации тоько под ИНтел у Интел Фортрана.
Всё зависит от используемых флажков.
-axW отлично работает на АМД, не используется SSE3
-axP +SSE3, все что не поддерживает SSE3 будет работать на generic code

-xP - получим невозможность запуска на А64 приложений, из-за отсутствия SSE3.

KChernov



Цитата:

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

Я сечас работаю с коммерческой программой с открытым кодом ( по крайне мере большей его частью) Программа позволяет симулировать различные физические явления, т.е. теплоперенос, гидродинамика, химические реакции, кристализация, механическая деформация... и так далее. Естественно можно симулировать все сразу или в любых физически возможных комбинациях. Количество переменных и массивов просто огромное. Соответственно каждый отдельный модуль имеет свой собственный хидер файл. Например часть кода ответственная за решение теплопшереноса имеет хидер файл "heat.fh" . Если мне гдето не хватает заданных переменных относяшихся к решению теплопереноса, я просто вначале подпрограммы пропишу:
INCLUDE 'heat.fh'
Все. Естественно хидер файлов может быть несколько, соответственно все глобальные переменные (которые вы используете не только в локально в подпрограмме) прописанны в хидерах и отсортированны по физическому смыслу. Так что зря вы жалуетесь на нелогичность. Не нравится собирать все константы в одном файле, зделайте несколько. Рассортируйте как вам удобно. При желании весь проэк можно разбить на папки. В одной папке хидеры, в другой папке только вайлы решателя, в третей файлы расчета тепла,... и так далее....


Цитата:

В моих задачах размерности могут меняться, а задавать так все возможные варианты - не выход.

Ну хороше, не нравятся константы, задайте как переменные, запихните их в common block совместно с SAVE стайтментом и все это в хидере.
Но только недавно вы говорили что вы хотите массывы задавать через параметр... Ну и если вам нужны переменные границы массива то вы либо чегото вырезаете или меняете форму массива, и небойсь еще и динамически задаете массив как allocatable. Иначе при чем здесь переменные размеры массива???
На использование хидера(ов) это не как не влияет. Из за использования SAVE переменные измененные в подпрограмме в commmon блоке будут сохранятся. Соответственно ничего не надо передавать из подпрограммы в основную программу и назад. Вся передача данных через common block, прописанный в хидере.

Пример использования хидеров я уже давал.... Но если массив переменных размеров и динамически задаваемый... то тут нюансов я сам не представляю... Наверно можно зделать так:

! файл bounds.fh
INTEGER Amin,Amax
INTEGER Bmin,Bmax
INTEGER Cmin,Cmax
COMMON /bounds_d/ Amin,Amax,Bmin,Bmax,Cmin,Cmax
SAVE /bounds_d/
! конец файла bounds.fh

PROGRAM testB
implicit none
include 'bounds.fh'
real, allocatable d
! Задаем размеры массива ( можно и расчитать....)
Аmin=-5
Amax=5
Bmin=0
Bmax=10
Cmin=-1
Cmax=1
! allocate array in memory
allocate (d(Amin:Amax,Bmin:Bmax,Cmin:Cmax))
! Передаем массив в подрпрограмму:
! границы передавать нет необходимости
call podrpr(d)
deallocate(d)
END


SUBROUTINE podrpr(d)
implicit none
include 'bounds.fh'
real d(Amin:Amax,Bmin:Bmax,Cmin:Cmax)
! операции внутри подпрограммы
return

Думаю что работать будет. Можно еще использовать module. S.Chapman писал про это с одной из своих книженций... типа "Sharing data using modules" Но тут я уже не советчик. Самому интересно почитать.

azertyuu

Цитата:

передаешь в процедуру только массив, а потом узнаешь его размер при помоши команды size()

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

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

Dust
Спасибо за информацию

dima333a

Цитата:

Не нравится собирать все константы в одном файле, зделайте несколько

Об этом я как-то не подумал. Спасибо за идею

KChernov


Цитата:

Проверка на выход за пределы массива есть + функции size и shape работают, но почему-то сами диапазоны получить нельзя - бред

Ну честно говоря мне особо небыло нужды иметь диапазон массива отличный от 1:n .

Т.е. если мне есть необходимость пометить данные в массиве как то по другому, я просто задам два массива. Например ваш массив с идексами -5, -4, -3, -2, -1, 0, 1,2,3,4,5 (-5:5)

Можно просто задать массив как y(1:11), и дополнительный массив x(1:11)

index 1 2 3 4 5 6 7 8 9 10 11
value x -5 -4 -3 -2 -1 0 1 2 3 4 5
value y y1 y2 y3 y4 y5 y6 y7 y8 y9 y10 y11

dima333a

Цитата:

я просто задам два массива

А зачем второй массив?

Цитата:

А зачем второй массив?

А зачем вам данные в массиве нумеровать начиная не с еденицы? Затем и второй массив: Все массивы задаем начиная с еденицы, тогда если знаем размер массива, то нет проблем с обходом всего массива.

Наприме 'неправильный массив' d(-5:5)
если мы знаем размер массива (11) то это нам никак не помогает, т.к. мы не знаем откуда массив начинается...

do i=????
d(i)
end do


'правильный' массив d(1:11). Если во всей программе все массивы начинаются с еденицы, тогда просто узнав размер массива (11) мы легко пройдемся по всем элементам массива. Нет необходимости гадать откуда массив начинается.

do i=1,11,1
d(i)
end do

И вы ведь сами писали что

Цитата:

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

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


Или я вас неправильно понял. Вам интересны не границы, а размеры многомерного массива в различных измерениях? Если так то извините что морочу голову

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

То есть я понял, как нельзя, и как можно это обойти.
Всем спасибо

Созрел еще один вопрос:
Как к IVF поставленному под VS 2003 прикрутить интеловский файл помощи?
Вроде бы как-то можно, но вчера все перерыл - не нашел

Еще вопрос:
Когда вы пишете новые вычислительные алгоритмы, то как определяете, что оно все правильно работает, и как отлавливаете багов в противном случае?

KChernov


Цитата:

Когда вы пишете новые вычислительные алгоритмы, то как определяете, что оно все правильно работает, и как отлавливаете багов в противном случае?

Вообще вопрос не про FORTRAN конечно. флеймим потихонечку.


1.Ну самое простое это подсчитать несколько случаев 'вручную'.

2.Если вручную слишком сложно, то тогда 'стандартные' ситатуации, т.е. пишем программу и считаем на ней варианты для которых уже знаем ответы или сушествует аналитическое решение.

3. Реалистичное поведение. Допустим нету таких вариантов где мы знаем ответ. Тогда проверяем реалистичность поведения.

dima333a

Цитата:

Вообще вопрос не про FORTRAN конечно. флеймим потихонечку.

Забыл написать, что в первую очередь интересует, как это делается под фортраном.

1. И вручную отслеживать правильность работы программы?
2.3. А как само отслеживание осуществляется?

Скорее интересует такое:
Запуск алгоритмов параллельно и сравнение их "жизненных показателей".

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

Мб есть ли готовые реализации подобных систем контроля?
И какие обычно используются подходы для этого?

Hell o, all пользую я CFV 6.6c3 - чудный компилятор с кучей багов, глючит в нём и такой код
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
program make_gird
implicit none
integer, pointer :: a(:,: ),b(:,: ) !если тут поставить allocatable - то бага нету
integer n,m

n=1000000
m= 900000
allocate(a(2,n),b(2,n))
a=1
b=2
a(:,:m)=b(:,:m) !вот здеся stack overflow происходит

read(*,*)
end program make_gird
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
почему с заменой pointer на allocatable баг исчезает
баг заключается в том что прога вылетает с stack overflow на строчке копирования из массива в массив
зы: может это не баг? - а я так криво стандарт знаю
зыы: знает тут кто нить нормальный активный форум по прогань на фортране

Aleksandr_count

А просто увеличить размер стека не пробовали? А?
Ведь default размера стека у CVF далеко не оптимален, и может быть отрегулирован

A в вашем примере вполне возможно операции с поинтерами идут через стек, вот и делов то.

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

Aleksandr_count


Цитата:

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

Можете попробовать спросить на форуме Intel по компиляторам. Там могут и про CVF ответить.

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