Компиляция .f95 в ifort

[Freude]

Подскажите пожалуйса, как компилировать файлы 95 Фортрана. Компилятор ifort. До этого момента компилировал только файлы .f90. Теперь хочу откомпилировать программу, написанную на Fortran95. Она ведь должна иметь расширение .f95, верно? Может нужно добавить в строку

ifort myprogramm.f95

какое-то ключевое слово. В мануале написано, что ifort может компилировать как файлы Фортран 90, так и Фортран 95. Спасибо

[Freude]

Кажется проблема в расширении. Исходники девяностопятого фортрана тоже имеют расширение .f90?

Забыл библиотеки подключить

ifort proba.f90 -lmkl_lapack95 -lmkl_lapack -lmkl_ia32 -lguide -lpthread

[Yuri Gendelman]

Freude писал(а):

Кажется проблема в расширении. Исходники девяностопятого фортрана тоже имеют расширение .f90?
Забыл библиотеки подключить

Просто любопытно, а Вы не пробовали расширение .f95 с подключенной библиотекой?

[Freude]

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

-lmkl_lapack95

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

[Yuri Gendelman]

Freude писал(а):

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

...и почему в Британии движение левостороннее.
Фортран был первым, так что "наоборот" - это у последующих языков.

[Freude]

Еще вопрос по программированию на Фортране и не только. Типы real и double precision отличаются числом бит, выделяемых для хранения числа. Понятно, что если в программе все real поменять на double precision, то она будет использовать больше оперативной памяти, а на скорости ее работы это как-нибудь скажется?

[worm2]

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

[e2e4]

Freude писал(а):

Еще вопрос по программированию на Фортране и не только. Типы real и double precision отличаются числом бит, выделяемых для хранения числа. Понятно, что если в программе все real поменять на double precision, то она будет использовать больше оперативной памяти, а на скорости ее работы это как-нибудь скажется?

worm2 писал(а):

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

Основная проблема здесь даже не кэш.
Из беглого поиска в гугле, я понял, что real в фортране - это 32 бита, т.е. 1 слово на PC. Double precicion - 64 бита, т.е. 2 слова.
Во-первых, на 32-битных платформах, какими являются все PC на процессорах 80386...Core 2, для обработки double precicion потребуется 2 команды, 2 выборки из памяти и т.п. (EMT64 не рассматриваем, вряд ли автор использует соотв. проц+ОС+компилятор).
Тут, конечно, можно понадеяться на умное кэширование, конвейер процессора, предвыборку команд и данных, но для этого очень желательно, чтобы компилятор генерировал оптимизированный для данной процессорной архитектуры код. Что, в компиляторах 90-х годов (а Вы ведь используете Fortran 95), конечно, не реализовано.
Кроме того, формат чисел с плавающей запятой в представлении Фортрана может не совпадать с представлением процессора (вот тут Вам бы самим поискать информацию). Если вдруг не совпадает, то это очень сильно замедляет работу программы, т.к. работа с ними происходит на программном, а не аппаратном уровне.

В общем, worm2 совершенно верно отметил - простой численный эксперимент, например цикл на 10 000 000 вычислений с real, а такое же кол-во с double precicion. Засекаете время средствами Фортрана, или, на крайний случай - секундомером (только тут надо бы обеспечить время счета, хотя бы, секунд 30). Только прогонов цикла надо делать 2, засекать во второй раз - это связано с работой кэша.

Добавлено спустя 6 минут 13 секунд:

А вот неправ я насчет компилятора. Оказывается, такой раритет как Фортран еще не только поддерживают, но и переиздают с поддержкой всего самого современного: http://www.intel.com/cd/software/products/asmo-na/eng/282048.htm

Однако, все что я написал выше - справедливо. И ifort может только на бумагах intel пытаться что-то там оптимизировать под SSE4 и даже под IA-64 (!).

Экперимент, только эксперимент .

[Yuri Gendelman]

Freude писал(а):

Типы real и double precision ... а на скорости ее работы это как-нибудь скажется?

Как-то скажется конечно. Другое дело - насколько это будет существенно.
1) На 32-разрядных архитектурах самый эффективный размер данных - 32 бита. Поэтому для пересылки данных real эффективнее double precision, но integer (32b) эффективнее integer*2(16b).
2) При обработке больших массивов данных переполнение кэша (и замедление обработки) более вероятно для данных в double precision.

Но
1) Тип real на Intel дает слишком малую точность. Это особенно было заметно при сравнении с БЭСМ-4 (45-битовые слова) и БЭСМ-6 (48-битовые слова).
2) Внутренние операции в CPU выполняются с 80-бит. FP числами.
3) в C тип double (real*8) считается стандартным, а float (real*4) - дополнительным.

[Freude]

У меня еcть subroutine, написанный на фортране. Последние его строчки выполняют запись в файл: открываю файл

open()

, записываю в файл

write()

, все. Если я обращаюсь к подпрограмме несколько раз, то, соответсвенно, несколько раз происходит запись в файл. Странно для меня, но данные дописываются в файл, а не перезаписываются. Т.е. если у меня в файл записывается массив [1:2], то после двух обращений к subroutine в файле будет находится массив [1:4].

Как сделать так, чтобы информация не дописывалась в файл, а перезаписывалась? Может проблема в том, что я не закрываю файлы?

[Finve]

исторически так сложилось, что в фортране было два типа данних с плавающей точкой. Один real - 4 байт, второй - double precison - 8 байт. Начиная с 90 фотрана тип double precison формально был упразднен, остался только real с указание необходимого кол-ва байт, например real(4),real(8),real(16), последний на програмном уровне поддерживает интеловский компилятор.

Числа с плавающей точкой на x86/x64 представленны 80 битами, поэтому 4 и 8 байтовый real целиком помещаются в необходимые регистры, и соответственно по скорости должен быть паритет. По памяти естественно будет проигрыш в два раза у 8 байтовой модели.

Использовать сейчас 4 байтный real совсем как то несерьезно, если интересует точность, хоча задачи бывают разные. В той же NVIDIA CUDA поддержываються только 4 байтные real что не очень радует многих, и большинство ждет 8 байтных.

А относительно 32/64 платформ, так это кол-во бит относимое для целых чисел, то есть размер целочисленных регистров, и к числам с плавающей точкой это не имет абсолютно никакого отношения.

Я не волшебник, я только учусь, поэтому поправьте если что не правильно сказал. :)

Добавлено спустя 34 минуты 3 секунды:

Freude писал(а):

Как сделать так, чтобы информация не дописывалась в файл, а перезаписывалась? Может проблема в том, что я не закрываю файлы?

по правилам хорошего тона, и в стандарте думаю написано, что каждый оператор open() должен идти в паре с close(), если вы не хотите непредвиденых проблем - лучше так и делать ;)

Относительно дозаписи/перезаписи. У параметра open(), как и у других, есть список спецификаторов, которые позволяют выставлять нужный режим оператора. У оператора open() их 13 штук, и только один обязательный - unit, номер устройства, все остальные имеют значение по умолчанию. За дозапись/перезапись отвечает спецификатор position, он отвечает с какой позиции начинается работа с файлом, имеет три значения: 'rewind', 'append', 'asis'.

'rewind' - работа начинается с начала файла, соответственно все вытирается и пишится с чистого листа.
'append' - работа начинается с конца файла, идет дозапись, как в вашем варианте.
'asis' - работа по умолчанию, в Compaq Fortran 6.6 'asis' работает как 'rewind'.

Вам нужно посмотреть не задан ли у вас position="append", если нет, то задать принудительно position="rewind".

Добавлено спустя 11 минут 42 секунды:

Re: Компиляция .f95 в ifort

Freude писал(а):

Подскажите пожалуйса, как компилировать файлы 95 Фортрана. Компилятор ifort. До этого момента компилировал только файлы .f90. Теперь хочу откомпилировать программу, написанную на Fortran95. Она ведь должна иметь расширение .f95, верно? Может нужно добавить в строку

ifort myprogramm.f95

какое-то ключевое слово. В мануале написано, что ifort может компилировать как файлы Фортран 90, так и Фортран 95. Спасибо

компилировать так же как и Фортрана 90. На сколько я понял расширения f95 просто не существует, компиляторы от Compaq и Intel говорят о неправильно формате, а для Фортрана 95 используется f90. Если вам надо проверить ваши исходные коды на относительно правильности для того или иного стандарта, то в Intel Fortran существуют опции /w90 или /w95 а также много других в разделе Compiler Diagnostics справки ifort.