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

MZN

Цитата:

1. Наличие исходников обеспечивает полную свободу действий. Оптимизация под AMD64 ложится на плечи компилятора.

О какой свободе действия можно говорить в данном случае и о какой оптимизации на уровне компилятора, если в Фортране (как в языке) и в его компиляторах нет ни поддержки описанного мною деления, ни поддержки типов с произвольной точностью?!
Можно говорить только о том, что Фортран не способен решать задачу построения библиотеки для работы с числами с произвольной точностью для всех процессоров, у которых операция такого умножения поддерживается железом (по крайней мере все Интел и АМД х86-совместимые 32/64-битные процессоры как раз такие).
Конечно можно говорить, что поддержка такой операции не нужна, но тогда получается, что в угоду использования Фортрана, мы отказываемся от повышения производительности по крайней мере порядка 1.5-2 раз

Добавлено:
Возникла проблема с установкой EM64 версии IVF9.

В процессе работы инсталятора выдается сообщение о том, что не найден Microsoft Platform SDK
Что это за SDK такой и почему он нужен именно для 64-битной версии IVF?

Если не обращать на это внимание и ставить так, как предлагает инсталятор, при компиляции примера выдается сообщение об ошибке:
ifort: warning: option '-Qvc8' or higher used with '-ML[d]' is not supported
ifort: error: could not find 'cl'

При этом тот же пример с теми же опциями компилируется и работает...

Добавлено:
(Работает на 32-х битной версии компилятора)

KChernov



Цитата:

О какой свободе действия можно говорить в данном случае и о какой оптимизации на уровне компилятора, если в Фортране (как в языке) и в его компиляторах нет ни поддержки описанного мною деления, ни поддержки типов с произвольной точностью?!

В этой библиотеке все это и реализовано. А Вы думаете, что Real*16 Вам поможет? Если потеря значности 16-20 знаков - да, а если 35?


Цитата:

Можно говорить только о том, что Фортран не способен решать задачу построения библиотеки для работы с числами с произвольной точностью для всех процессоров, у которых операция такого умножения поддерживается железом (по крайней мере все Интел и АМД х86-совместимые 32/64-битные процессоры как раз такие).

Нет, нельзя! Само наличие данной библиотеки это опровергает. А она, кстати, не одна.
И портирована она помимо Intel и AMD еще на десяток платформ.


Цитата:

Что это за SDK такой и почему он нужен именно для 64-битной версии IVF?

Надо скачать и поставить. Без него никакого 64 разрядного кода не генерируется.



Цитата:

Конечно можно говорить, что поддержка такой операции не нужна, но тогда получается, что в угоду использования Фортрана, мы отказываемся от повышения производительности по крайней мере порядка 1.5-2 раз

Вы намекаете на повышение разрядности с 32 до 64 бит? Если так, то с чего Вы взяли, что это одно лишь даст увеличение производительности? Кстати, на внутренне представление данных, это может и не влиять.

MZN

Цитата:

В этой библиотеке все это и реализовано

Не понимаю, как в библиотеке может быть реализовано что-то средствами, не предусмотренными компилятором
Или библиотека на С с ассемблерными вставками (еще не добрался поизучать исходники библиотеки)?


Цитата:

А Вы думаете, что Real*16 Вам поможет? Если потеря значности 16-20 знаков - да, а если 35?

Если библиотека работы с длинными числами построена на основе integer4 или integer8 - это разница во времени при выполнении того же сложения этих длинных чисел в 2 раза - это мало?


Цитата:

Цитата:
Можно говорить только о том, что Фортран не способен решать задачу построения библиотеки для работы с числами с произвольной точностью для всех процессоров, у которых операция такого умножения поддерживается железом (по крайней мере все Интел и АМД х86-совместимые 32/64-битные процессоры как раз такие).     

Нет, нельзя! Само наличие данной библиотеки это опровергает. А она, кстати, не одна.
И портирована она помимо Intel и AMD еще на десяток платформ.

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


Цитата:

Вы намекаете на повышение разрядности с 32 до 64 бит?

Да.

Цитата:

то с чего Вы взяли, что это одно лишь даст увеличение производительности

Ну если больше ничего не делать - конечно не даст.
А вот если настроить под него библиотеку - вполне

Цитата:

Кстати, на внутренне представление данных, это может и не влиять.

Вы это про что?

Добавлено:
Обнаружил один неприятный момент от перехода с CVF к IVF - библиотеки dfport больше нет, зато вместо нее есть библиотека ifport.
Все бы ничего, но теперь все функции для работы с временем выдают время с точностью до секунды (в dfport-е функции используют все знаки после запятой)
Можно ли как-то получить хотя бы микросекунды?

Я уже подумал о том, что можно попробовать использовать dfport и с интеловским компилятором, но мб это можно сделать не выходя за пределы библиотек IVF-а?

KChernov


Цитата:

Не понимаю, как в библиотеке может быть реализовано что-то средствами, не предусмотренными компилятором
Или библиотека на С с ассемблерными вставками (еще не добрался поизучать исходники библиотеки)?

Думаю, это будет ответ на большинство Ваших вопросов. Библиотека реализует произвольную точность специальными алгоритмами, это, безусловно, неэффективно в смысле времени выполнения, но дает решить задачи, где потеря знаков достигает, например, 100.


Цитата:

Вы это про что?

64 битный процессор может работать с таким же представлением данных, как и 32 битный. Как в случае AMD я не знаю, но был 32bit процессор VAX, его технологическим развитием был 64bit процессор Alpha. Так вот, у второго и мантисса, и порядок в плавающей арифметике были МЕНЬШЕ(!)

И еще. Если Вы делаете программу под AMD, использовать компилятор Intel - это, как минимум, не получить никакой оптимизации. В худшем случае - резкое падение производительности. AMD уже и в суд за это подала.

MZN

Цитата:

Думаю, это будет ответ на большинство Ваших вопросов

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


Цитата:

64 битный процессор может работать с таким же представлением данных, как и 32 битный

Цитата:

Так вот, у второго и мантисса, и порядок в плавающей арифметике были МЕНЬШЕ(!)

Я имел в виду не переход от абстрактного 32-х битного проца к абстрактному 64-х битному, а конкретно от Р4 к АМД64.
Но идея понятна - необходимо знать реальные различия между процами.
Я, например, не сразу узнал, что у Р4 и АМД64 разрядность регистров для работы с действительными числами одинаковая (80) и не привязана к 32-х/64-х битности.

Цитата:

http://forum.ru-board.com/topic.cgi?forum=5&topic=5811&start=1780#17

Попробовал - получилось
Только теперь непонятно что делать, если нужно будет использовать обе библиотеки одновременно
Сколько проблем из-за того, что Интел почему-то урезала функции работы со временем (

Ну вот, оказывается мое решение не работает с 64-битным компилятором
Так что проблема актуальна...

Возвращаясь к вопросу 3. Можно ли настроить, чтобы для консольных приложений кодировка в окне консоли совпадала с кодировкой редактора vs?

Обнаружил следующее:
На одном из компов на CVF при использовании типа проекта QuickWin в окне нормально отображаются русские буквы!
В консоли все равно ненормально. И на других компах QuickWin тоже плохо себя ведет
Куда смотреть? С чем это мб связано?
Было бы очень приятно использовать эту возможность везде, а не только на одном компе до перестановки винды.

Вопрос по IVF 8:
Столкнулся со следующим неприятным поведением - одинаковые числа при сравнении давали false Переключился в hex - получил, что числа отличались на 16-ричную единицу в младшем знаке (которая округлялась при 10-тичном представлении до нуля, но однако никуда не исчезала). Появилось это судя по всему из-за накопления ошибки округления. Проблема решилась использованием real8 вместо real4, но сам факт означает, что подобные ошибки могут быть повсюду
Можно ли добиться того, чтобы проблема решилась кардинально?

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

Нету у меня Intel Fortran, тем не менее попытаюсь кое-какие ответы дать.

1. Кодировка в окне консоли - ДОСовская, а в редакторе M$ VS, понятное дело, ANSI. В принципе, в винде есть такая функция: перевода выводящегося текста в ОЕМ-кодировку (ДОСовскую), я нашел инфу про нее в MSDN, но на практике не применял. Я лично использую редактор KoEdit, у него есть подсветка синтаксиса: Fortran и куча других языков, работа с несколькими русскими кодировками... Просто набрать там что нужно, кодировку поставить ДОСовскую, и все. А потом файл можно загрузить в VS.

2. QuickWin дает не консольное окно, а ущербное виндовое, притворяющееся консольным. С него можно копировать текст в буфер обмена и делать другие операции, невозможные для консоли. Поэтому кодировка для него ANSI, со всеми последствиями. Почему эти последствия не на всех компах, мне не понятно. Возможно, по умолчанию в окне не тот шрифт ставится, без поддержки русского языка.

3. Кардинальное решение проблемы со сравнением чисел с плавающей точкой НЕ ВОЗМОЖНО в принципе: они представляются в памяти компьютера ПРИБЛИЖЕННО, отсюда все фокусы. Вот если бы ЦЕЛЫЕ числа при сравнении оказались не равными, тогда можно было бы закатывать скандалы и требовать с Intel напрасно потраченных денежек. Да, подобные ошибки действительно могут быть повсюду. Именно поэтому из стандарта Фортрана исключено использование дробного числа в качестве счетчика цикла - потому что результат при его изменении, с точки зрения компьютера, может оказаться совсем не тот, что ожидался программистом.

4. Про оптимизацию - лучше не надеяться на компилятор и прописать все самому. Мне кажется, что когда компилятор дойдет до повтора, он вряд ли вспомнит, что такое выражение уже встречалось раньше.

KChernov


Цитата:

Появилось это судя по всему из-за накопления ошибки округления. Проблема решилась использованием real8 вместо real4, но сам факт означает, что подобные ошибки могут быть повсюду
Можно ли добиться того, чтобы проблема решилась кардинально?

ИМХО самое элегантное и каардинальное решение это не сравнивать REAL числа со строгими условиями типа

REAL*8 A,B


A=1.0
B=1.0

IF (A .EQ. B ) THEN
blax blax blax
END IF


Значительно лучше сравнивать с некоторой точностью (точность можно задать исходя из типа REAL.:

REAL*8 A,B,T

A=1.0
B=1.0
T=0.000001

IF ( abs(A-B) .LT. T ) THEN
blax blax blax
END IF


P.S. Помоему я уже писал об этом.

1. Вариант, конечно, но у IVF в интеграции со студией есть достаточно интересные плюшки, чтобы использовать именно его в качестве редактора

2. Спасибо, попробую поиграться со шрифтами.

3. Это понятно. Но здесь как раз проблема в том, что 16-ричные числа некорректно преобразуются в 10-чные

4. Мне кажется, что лучше просто знать, что делает, а что не делает в этом отношении компилятор. Чтобы не делать за него лишнюю работу (или делать, если он такой непродвинутый).

Цитата:

3. Это понятно. Но здесь как раз проблема в том, что 16-ричные числа некорректно преобразуются в 10-чные

Это как?


Цитата:

Мне кажется, что лучше просто знать, что делает, а что не делает в этом отношении компилятор.

А вот это вам могут и не сказать ) придется запускать много много тестов, хотя нужно тут сказать, что фортрановский компилятор в этом плане довольно "продвинутый" и оптимизирует оччень неплохо.

Результат преобразования 16-битных чисел в 10-битные (или 8-битные) - это классический пример вычислений с потерей точности. В общем, все законно, жаловаться не на кого.

Про процесс оптимизации при желании кое-что могут сказать. В частности, указывают на объединение постоянных: если было х*4*8, станет х*32. То есть какие-то константы могут быть не как числа, а как переменные с некоторым значением, которое для данного случая компилятору точно известно; их тоже объединят.

Одинаковые куски тоже не вычисляют два раза, но только в границах ОДНОГО ВЫРАЖЕНИЯ:

Elimination of common subexpressions within a statement. Again, this applies equally to expressions which form subscript calculations. Consider the following assignment:

A(I,J+K) = A(I,J+K) + 3 - здесь I,J+K посчитают один раз, а вставят два раза. Цитата из справки к компилятору Salford FTN95. Замена ранее сосчитанным выражением (где-то в другой строчке) возможна, похоже, только в пределах цикла, их причесывают наиболее тщательно.

Метки и переходы GOTO ухудшают условия оптимизации.

Оптимизация может привести и к несколько неожиданным результатам в плане точности:

Some additional optimisations based on the 80486 and Pentium instruction set. In some cases integer instructions are used instead of floating point instructions. This often results in different behaviour... - короче, если в хвосте у числа с плавающей точкой мусор, не обижайтесь, это следствие оптимизации.

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

Цитата:

3. Это понятно. Но здесь как раз проблема в том, что 16-ричные числа некорректно преобразуются в 10-чные

Цитата:

Результат преобразования 16-битных чисел в 10-битные (или 8-битные) - это классический пример вычислений с потерей точности.

Ни...чего себе разница: 16ричные в 10чные и 16-битные в 10-ти )
А потеря точности вполне естественна, есть куча приемов (в зависимости от случая) позволяющих по максимуму сохранять точность.

Ну, поторопился, не так понял...

dima333a
Наверное так и придется.
Спасибо, попробую.

Добавлено:
FuzzyLogic
// Это как?

Я написал, как - при показе 10-го эквивалента 16-ричного числа оно округляется, а при сравнении - нет (так как сравниваются именно 16-ричные)
Похоже, что это баг отладчика

// А вот это вам могут и не сказать
А я надеялся, что меня как раз пошлют по ссылке читать ман.
А его оказывается и нету
Безобразие.

Добавлено:
XPEHOMETP
Скорее они не подумали о том, что неплохо было бы использовать более вместительный шаблон. Тогда бы все отображалось правильно.

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

// но только в границах ОДНОГО ВЫРАЖЕНИЯ
А несколько выражений в одной строке (разделенных - это одно выражение?

То есть в пределах цикла это работает (как раз там обычно и надо)?

Добавлено:
FuzzyLogic
// есть куча приемов (в зависимости от случая) позволяющих по максимуму сохранять точность
А можно поподробнее?

Цитата:

// есть куча приемов (в зависимости от случая) позволяющих по максимуму сохранять точность
А можно поподробнее?

Ну, приведу конкретный пример из своей области. Есть мат. модель потока жидкости (скажем воды). Одна из переменных этой модели - плотность воды которая изменяется где-то в пределах от 1000 до 1030, а чаще этот интервал ещё меньше. Так вот зачастую пользуются след. приемом: уравнения модели выписывают не для плотности rho а для new_rho=(rho-rho_avg), где rho_avg потом устанавливаем скажем равной 1015 и работаем уже в программе с переменной new_rho, которая колеблется уже не от 1000 до 1030, а от -15 до 15 (или ещё меньше), таким образом выкраиваем дополнительные пару-тройку знаков после запятой.

XPEHOMETP
Осталось понять, где этот шрифт задавать для QuickWin.
В самих окнах ничего настроить нельзя
В среде тоже.

Добавлено:
FuzzyLogic
Да, я знаю про такое, спасибо.
А другие приемы?

Мне тут как-то говорили, что можно с помощью size() получить внутри процедуры размерность переданного массива и использовать его для объявления этого массива в процедуре.
Но у меня почему-то не получается
Вот такой пример не работает:
integer,parameter:: FnX = 3, FnY = 49
real x(FnX), y(FnX,FnY)
...
call map2d(x,y)
...
subroutine map2d(x,y)
integer::FnX=size(x),FnY=size(y,dim=2)


Что не так?

KChernov
Такое очучение что всё не так. В том смысле что так не получится сделать. То что мы видим внутри подпрограммы это не тоже самое что объявлено внутри программы (впиши в начало своей subroutine 'implicit none' и увидишь). Если массив глобальный, тогда можно и размер увидеть, а иначе ... в процедуру ничего кроме указателя ведь не передается.

Там какая-то с этим темная материя. Везде пишут, что указатели в Фортране - это не просто ссылки, там еще гонится какая-то инфа про сам массив, про его размерность и очертания, из-за чего не рекомендуют передавать указатель на фортрановский массив в подпрограммы, написанные на С. Будут, мол, взаимные непонятки. Так что, возможно, в каких-то условиях можно заставить эту инфу работать на 100%. Но я этих условий не знаю.

Я всегда просто передавал в подпрограмму размерность массива в качестве целого параметра, объявлял массив этого размера, и все туда нормально помещалось. Ну, правда, это тривиальные вещи.


ЗЫ: Во, вспомнил! Assumed size array! Эта фишка исключена из стандарта Fortran90, но большинство компиляторов должно поддерживать. Делается так: в подпрограмму передается массив, и он объявляется там примерно так:

real(kind=2) :: myarray(*)

В общем, существенна звездочка в качестве "размера" массива. Дальше с ним работают, как обычно. Никогда этим не пользовался. Как находят реальный размер массива, не знаю.

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

Цитата:

ЗЫ: Во, вспомнил! Assumed size array!

Угу, но и так, всё равно похоже приходится передавать размерность массива параметром, в противном случае компилятор говорит что не удается определить размерность (пробовал Intel и SGI). Может так оно должно и быть, а может просто реализация компиляторов такая...

KChernov


Не совсем понимаю зачем так мучать FORTRAN

Задаем переменную INTEGER size_of_array_A
Помещяем эту переменную в common block / interface (для common может потребоватся SAVE)
Потом вычилсяем значение этой переменной до того как вызвать подпрограмму
Обявляем наш common block/interface внутри подпрограммы
Обьявляем наш массив внутри подпрограммы через size_of_array_A

Надо, надо его мучать по утрам и вечерам! Вот более разумные разъяснения, как это делать:

Assumed-Size Arrays
В общем, в фортране-77 это дело действительно пишется со звездочкой:

SUBROUTINE PULLDOWN ( A, B, C )
INTEGER A(5, *), B(*), C(0:1, 2:*)

Массивы передаются в подпрограмму в качестве параметров, и описываются в ней со звездочкой в последнем (если их несколько) измерении. Пример взят из FORTRAN77 Language Reference от Sun Microsystems.

C Fortran90 вышла неточность: есть там эта штука, только синтаксис поменяли. В книжке Немнюгина и Стесик написано об этом финте как о массиве с подразумеваемой формой:

SUBROUTINE replace(a, b)
REAL, DIMENSION( : ) a, b
REAL, DIMENSION(SIZE(b)) r

Вместо звездочки стало двоеточие. Встроенная функция SIZE(b) возвращает длину массива; ее можно использовать в операторах описания.

А выкинули эту фишку, похоже, из фортрана-95. В справке к FTN95 причислили Assumed-size arrays (i.e. with ‘*’ in the last dimension) к Obsolescent features. Пока еще поддерживается, и даже обещают сохранить в будущих версиях FTN95, но техподдержки в этой области не будет.

Всем спасибо за отклики

dima333a
Располагать переменные текущего вызова в комон-блоке, имхо, не очень правильно.
Но как вариант можно иметь в виду.

XPEHOMETP
Спасибо, попробовал так - получилось.
Только вот сразу инициализировать переменную почему-то все равно нельзя


Например, такой пример не работает:
subroutine map2d(x,y)
real x( : ),y( : , : )
integer::FnX=size(x),FnY=size(y,dim=2)


Интересно, а что они тогда предлагают в замен?
Использовать вместо этого типы?

KChernov


Цитата:

Располагать переменные текущего вызова в комон-блоке, имхо, не очень правильно.

Что значить 'текушего вызова'?
И почему не очень правильно?

На самом деле я не предлагал никуда вызывать эту переменную, а именно хранить ее в common. Т.е. из программы в подпрограмму на прямую переменная не передается, а просто шарится через common block. Помоему это и есть основная функция common block-а..... Если common block будет 'save' то все ИМХО абсолютно по правилам FORTRAN- стандартная конструкция

dima333a

От использования COMMON-блока уже во всю отговаривают во всех новых книжках по Фортрану. Мол, есть уже варианты лучше - вроде через MODULE и USE для данного модуля. А вообще это не очень удобно: нужно четко следить за порядком, в котором прописаны переменные в COMMON-блоке, поскольку они там хранятся в указанном порядке. Написал в подпрограмме не так, значит получишь на выходе не то.

KChernov

subroutine map2d(x,y)
real x( : ),y( : , : )

- работать НЕ БУДЕТ по всем правилам Фортрана, т.к. аssumed size можно применять только для последнего измерения. Вот такое должно работать:

subroutine map2d(x,y)
real x( : ),y(0:6, : )

XPEHOMETP


Цитата:

А вообще это не очень удобно: нужно четко следить за порядком, в котором прописаны переменные в COMMON-блоке, поскольку они там хранятся в указанном порядке. Написал в подпрограмме не так, значит получишь на выходе не то.

А я не прописываю common в каждой сабрутине отдельно. Я использую хедер файлы. Один раз прописал все в хедер файле, а потом INCLUDE стейтментом включаю сразу все богатсва в подпрограмму.

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

XPEHOMETP

Цитата:

работать НЕ БУДЕТ по всем правилам Фортрана, т.к. аssumed size можно применять только для последнего измерения

Как раз это:
subroutine map2d(x,y)
real x( : ),y( : , : )
у меня работает - что я делаю не так?

Не работает именно попытка инициализации переменных размерностями массивов
Вот такой вариант, например, работает:
subroutine map2d(x,y)
real x( : ),y( : , : )
integer FnX, FnY
FnX=size(x)
FnY=size(y,dim=2)

Добавлено:
dima333a
С комон-блоком есть такой момент, что надо не забывать помещать в него правильные данные.
Если вызываешь подпрограмму с параметрами - забыть сложнее.
Особенно это актуально при передаче кода кому-то еще - такая передача параметров должна быть подробно описана.