Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Работа с Intel Fortran через Visual Studio 2003 и не только

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

Открыть новую тему     Написать ответ в эту тему

KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
dima333a

Цитата:
 Я на самом деле пользуюсь старым добрым VS 6


Цитата:
 у меня Intel Fortran ver. 7.0

То есть компилятор Интеловский, а среда Компаковская?
А real 16 там есть?
 
Спасибо за информацию - попробую

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 17:31 05-12-2005
dima333a



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
KChernov
 
Помоему CVF не имеет возможности использовать REAL*16. Во всяком случае у меня не получилось скомпилировать программу когда я добавил переменнуюю REAL*16 ...
 
Насчет компиляторов, то я пользуюсь как Compaq Fortran, так и Intel Fortran.  Intel Fortran компилирую из командной строки, а Compaq Fortran уж когда как удобней. А VS для меня это скорей как продвинутый текстовый редактор

Всего записей: 798 | Зарегистр. 27-02-2004 | Отправлено: 03:40 06-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
dima333a

Цитата:
Помоему CVF не имеет возможности использовать REAL*16

А так называемый double precision?
 
Добавлено:
MZN

Цитата:
http://crd.lbl.gov/~dhbailey/mpdist/index.html

Посмотрел эту библиотеку и остальные по этой ссылке и у меня появились вопросы:
 
1. Не встретил никакого упоминания о АМД64 в их описании - только про Итаниумы и ПоуэрПС. Будут ли они использовать преимущества АМД64?
 
2. Код я тоже смотрел и наткнулся там на такой прием:
    real a,b,c,d
...
    c = a * b
    d = a * b - c
 
Вроде как они таким образом пытаются получить перенос, который получается при переполнении при умножении.
Но я попробовал такой прием и сравнил с умножением при более высокой точности - совпадений нет
Я что-то не так настроил, или это еще зачем надо?
 
3. Можно ли как-то получить этот самый перенос при переполнении в фортране (и при сложении, и при умножении)? Ведь ассемблерная команда, которой осуществляется умножение (например), имеет результатом два слова - то, что обрезается и само переполнение. Или это нельзя получить в фортране, а только через ассемблерные вставки в С?

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 11:25 06-12-2005
dima333a



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
KChernov
Цитата:
А так называемый double precision?

 
double precision дает REAL*8 -это помоему любой доступный компилятор FORTRAN-a имеет .

Всего записей: 798 | Зарегистр. 27-02-2004 | Отправлено: 17:20 06-12-2005 | Исправлено: dima333a, 17:26 06-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
dima333a

Цитата:
double precision дает REAL*8

Действительно, в CVF-е нет отдельной настройки.
Просто в IVF-е можно задавать double precision в 16 (правда там можно и real в 16 задать)...

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 17:52 06-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
А по другим вопросам совсем никто ничего не знает?

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 14:52 08-12-2005
XPEHOMETP

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
На счет использования преимуществ АМД64 - для этого лучше всего загрузить на сайте АМД библиотеки, заточенные специально под их процессоры. Требуется бесплатная регистрация.

Всего записей: 2485 | Зарегистр. 21-06-2005 | Отправлено: 14:56 09-12-2005
MZN

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
KChernov

Цитата:
1. Не встретил никакого упоминания о АМД64 в их описании - только про Итаниумы и ПоуэрПС. Будут ли они использовать преимущества АМД64?  

 
Есть же исходники. Теперь все зависит от компилятора.

Цитата:
2. Код я тоже смотрел и наткнулся там на такой прием:  
    real a,b,c,d  

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

Цитата:
3. Можно ли как-то получить этот самый перенос при переполнении в фортране  

В фортране, скорее всего, нет.

Всего записей: 1715 | Зарегистр. 23-10-2004 | Отправлено: 15:26 10-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
MZN

Цитата:
Есть же исходники. Теперь все зависит от компилятора.

Тогда так и надо говорить, что это все полуфабрикаты.
Кстати, что надо почитать, чтобы по исходнику это понять?
 

Цитата:
Я с этой библиотекой проводил очень много расчетов и все было в порядке. На своем опяте убедился, что самому ничего выдумывать не надо.

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

Цитата:
В фортране, скорее всего, нет.

Жаль
 
 
Добавлено:
Попробую переформулировать вопрос:
Можно ли получить выигрыш в производительности в задачах, где требуется большая точность (стандартных типов не хватает), если вместо Р4 (32-х битный) использовать АМД64?
И что для этого нужно?

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 10:42 12-12-2005
MZN

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
KChernov
 
Фортран процессоронезависимый язык. Любая попытка привязать его к конкретному процессору (что, вообще говоря, для языка высокого уровня, каким он является, ОЧЕНЬ сложно), ведет к потере портабельности. Например, не факт, что если мы "привяжем" код к одноядерному Opteron, он будет работать на двухядерном.
 
Называть исходники полуфабрикатом, вообще говоря, можно. Но что тогда есть законченный продукт? Библиотека. Так она же заточена под один компилятор (как правило). Единственный мне известный компилятор Фортрана, оптимизирующий под AMD64, это Pathscale. Есть еще и Absoft. Это все под Linux. Надеяться, что интеловский компилятор будет делать это хорошо, я бы не стал.
 
Резюме.  
1. Наличие исходников обеспечивает полную свободу действий. Оптимизация под AMD64 ложится на плечи компилятора.
2. MPFUN, вообще говоря, стандарт де факто. Конечно, там могут быть ошибки. В сомнительных случаях я всегда связывался с автором и он всегда отводил все подозрения. Кстати, примененные там алгоритмы много сложнее данного примера.
Библиотека на использует прямых аналогов REAL816 32 64 и т.п. Точность там произвольна.
 

Цитата:
Можно ли получить выигрыш в производительности в задачах, где требуется большая точность (стандартных типов не хватает), если вместо Р4 (32-х битный) использовать АМД64?  
И что для этого нужно?

Наверное можно. Как? Не знаю. Но MPFUN справится на P4 (если расчеты не гигантские)
 

Всего записей: 1715 | Зарегистр. 23-10-2004 | Отправлено: 16:26 12-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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-х битной версии компилятора)

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 13:24 16-12-2005
MZN

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
KChernov
 
 

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

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

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

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

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

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

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

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

Всего записей: 1715 | Зарегистр. 23-10-2004 | Отправлено: 18:41 16-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
MZN

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

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

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

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

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

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

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

Да.

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

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

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

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

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 17:47 22-12-2005
MZN

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
KChernov
 

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

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

Цитата:
Вы это про что?  

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

Всего записей: 1715 | Зарегистр. 23-10-2004 | Отправлено: 19:53 22-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
MZN

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

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

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


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

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

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 16:21 23-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 15:31 26-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ну вот, оказывается мое решение не работает с 64-битным компилятором
Так что проблема актуальна...

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 13:56 28-12-2005
KChernov



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Возвращаясь к вопросу 3. Можно ли настроить, чтобы для консольных приложений кодировка в окне консоли совпадала с кодировкой редактора vs?
 
Обнаружил следующее:
На одном из компов на CVF при использовании типа проекта QuickWin в окне нормально отображаются русские буквы!
В консоли все равно ненормально. И на других компах QuickWin тоже плохо себя ведет
Куда смотреть? С чем это мб связано?
Было бы очень приятно использовать эту возможность везде, а не только на одном компе до перестановки винды.
 
Вопрос по IVF 8:
Столкнулся со следующим неприятным поведением - одинаковые числа при сравнении давали false Переключился в hex - получил, что числа отличались на 16-ричную единицу в младшем знаке (которая округлялась при 10-тичном представлении до нуля, но однако никуда не исчезала). Появилось это судя по всему из-за накопления ошибки округления. Проблема решилась использованием real8 вместо real4, но сам факт означает, что подобные ошибки могут быть повсюду
Можно ли добиться того, чтобы проблема решилась кардинально?
 
Вопрос про оптимизацию:
Например, при каждой итерации цикла может использоваться пересчет коэффициентов (например, для отображения одного массива в другой).
Если одно и то же выражение используется в нескольких местах, оптимизирует ли это компилятор/процессор так, чтобы считалось только один раз?
Или нужно самому вводить временную переменную и сначала вычислять, а потом везде использовать результат вычисления?

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 16:38 27-02-2006
XPEHOMETP

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Нету у меня Intel Fortran, тем не менее попытаюсь кое-какие ответы дать.
 
1. Кодировка в окне консоли - ДОСовская, а в редакторе M$ VS, понятное дело, ANSI. В принципе, в винде есть такая функция: перевода выводящегося текста в ОЕМ-кодировку (ДОСовскую), я нашел инфу про нее в MSDN, но на практике не применял. Я лично использую редактор KoEdit, у него есть подсветка синтаксиса: Fortran и куча других языков, работа с несколькими русскими кодировками... Просто набрать там что нужно, кодировку поставить ДОСовскую, и все. А потом файл можно загрузить в VS.
 
2. QuickWin дает не консольное окно, а ущербное виндовое, притворяющееся консольным. С него можно копировать текст в буфер обмена и делать другие операции, невозможные для консоли. Поэтому кодировка для него ANSI, со всеми последствиями. Почему эти последствия не на всех компах, мне не понятно. Возможно, по умолчанию в окне не тот шрифт ставится, без поддержки русского языка.
 
3. Кардинальное решение проблемы со сравнением чисел с плавающей точкой НЕ ВОЗМОЖНО в принципе: они представляются в памяти компьютера ПРИБЛИЖЕННО, отсюда все фокусы. Вот если бы ЦЕЛЫЕ числа при сравнении оказались не равными, тогда можно было бы закатывать скандалы и требовать с Intel напрасно потраченных денежек. Да, подобные ошибки действительно могут быть повсюду. Именно поэтому из стандарта Фортрана исключено использование дробного числа в качестве счетчика цикла - потому что результат при его изменении, с точки зрения компьютера, может оказаться совсем не тот, что ожидался программистом.  
 
4. Про оптимизацию - лучше не надеяться на компилятор и прописать все самому. Мне кажется, что когда компилятор дойдет до повтора, он вряд ли вспомнит, что такое выражение уже встречалось раньше.

Всего записей: 2485 | Зарегистр. 21-06-2005 | Отправлено: 17:29 27-02-2006
dima333a



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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. Помоему я уже писал об этом.
 
 
 
 
 
 

Всего записей: 798 | Зарегистр. 27-02-2004 | Отправлено: 20:02 27-02-2006
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Работа с Intel Fortran через Visual Studio 2003 и не только


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru