2014 dxdy logo

Научный форум dxdy

Математика, Физика, Computer Science, Machine Learning, LaTeX, Механика и Техника, Химия,
Биология и Медицина, Экономика и Финансовая Математика, Гуманитарные науки




 
 Компиляция .f95 в ifort
Сообщение30.01.2008, 13:34 
Аватара пользователя
Подскажите пожалуйса, как компилировать файлы 95 Фортрана. Компилятор ifort. До этого момента компилировал только файлы .f90. Теперь хочу откомпилировать программу, написанную на Fortran95. Она ведь должна иметь расширение .f95, верно? Может нужно добавить в строку
Код:
ifort myprogramm.f95
какое-то ключевое слово. В мануале написано, что ifort может компилировать как файлы Фортран 90, так и Фортран 95. Спасибо

 
 
 
 
Сообщение30.01.2008, 17:40 
Аватара пользователя
Кажется проблема в расширении. Исходники девяностопятого фортрана тоже имеют расширение .f90?

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

Код:
ifort proba.f90 -lmkl_lapack95 -lmkl_lapack -lmkl_ia32 -lguide -lpthread

 
 
 
 
Сообщение30.01.2008, 20:04 
Freude писал(а):
Кажется проблема в расширении. Исходники девяностопятого фортрана тоже имеют расширение .f90?
Забыл библиотеки подключить
Просто любопытно, а Вы не пробовали расширение .f95 с подключенной библиотекой?

 
 
 
 
Сообщение31.01.2008, 17:34 
Аватара пользователя
Не знаю, не получается проверить. Оказывается у меня нет библиотеки
Код:
-lmkl_lapack95

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

 
 
 
 
Сообщение31.01.2008, 18:20 
Freude писал(а):
Еще одна странность фортрана, как на мой вкус, - это нумерация элементов матрицы. Почему-то первая цифра является номером столбца, а вторая - номером строки. В моем понимании, должно быть наоборот :)
...и почему в Британии движение левостороннее. :)
Фортран был первым, так что "наоборот" - это у последующих языков.

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

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

 
 
 
 
Сообщение04.02.2008, 20:22 
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 (!).

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

 
 
 
 
Сообщение04.02.2008, 20:55 
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) - дополнительным.

 
 
 
 
Сообщение23.03.2008, 14:40 
Аватара пользователя
У меня еcть subroutine, написанный на фортране. Последние его строчки выполняют запись в файл: открываю файл
Код:
open()
, записываю в файл
Код:
write()
, все. Если я обращаюсь к подпрограмме несколько раз, то, соответсвенно, несколько раз происходит запись в файл. Странно для меня, но данные дописываются в файл, а не перезаписываются. Т.е. если у меня в файл записывается массив [1:2], то после двух обращений к subroutine в файле будет находится массив [1:4].

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

 
 
 
 
Сообщение10.04.2008, 03:46 
исторически так сложилось, что в фортране было два типа данних с плавающей точкой. Один 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.

 
 
 [ Сообщений: 11 ] 


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group