Несколько вопросов по Fortran (НОВЫЙ ВОПРОС)
Ставил Intel Fortran 9.1 на Windows х64 (проц АМД64).
64-х битная версия работала только из командной строки, но 32-х битная версия работает в интеграции с VS.net 2003.
Использование 64-х битного компилятора способно ускорить программы, которые используют integer8 (64-х битный тип).
Ускорение при целочисленном умножении, например, порядка 10 раз.
Операции с real16 ускоряются не так сильно: умножение порядка 30%.
Другие компиляторы не пробовал.
Если нужен компилятор под intel - вряд ли мб что-то лучше, чем компилятор от производителя.
64-х битная версия работала только из командной строки, но 32-х битная версия работает в интеграции с VS.net 2003.
Использование 64-х битного компилятора способно ускорить программы, которые используют integer8 (64-х битный тип).
Ускорение при целочисленном умножении, например, порядка 10 раз.
Операции с real16 ускоряются не так сильно: умножение порядка 30%.
Другие компиляторы не пробовал.
Если нужен компилятор под intel - вряд ли мб что-то лучше, чем компилятор от производителя.
Ок спасибо. Цифры обнадеживают. Помоему нужен был действительно компилятор по Intel. Но на всякий случай, бывают ли подобные под атлоны?
Я немножко запутался в терминологии, что затип real16?
Часть компьютеров оснащены х32 процессорами Атлон, под них чем можно посоветовать откомпилировать прогу, чтобы постараться достичь максимальной производительности?
Я немножко запутался в терминологии, что затип real16?
Часть компьютеров оснащены х32 процессорами Атлон, под них чем можно посоветовать откомпилировать прогу, чтобы постараться достичь максимальной производительности?
А если в программе используется тип двойной точности, можно ожидать ускорения работы?
Я так понял Real16 это 16байтовый с плавающей точкой. В подобной точности, в конкретной задаче необходимости нет
Я так понял Real16 это 16байтовый с плавающей точкой. В подобной точности, в конкретной задаче необходимости нет
А если в программе используется тип двойной точности, можно ожидать ускорения работы?
Можно, из-за увеличения числа и размера регистров, но это зависит от того, воспользуется ли этим компилятор.
Например, на задачах, которыми занимаюсь я, т.е. real*8 расчеты, где ресурсы ест в основном линейная алгебра, прирост порядка 10%. Компиляторы - g77, g95, pgf90, библиотеки acml
бывают ли подобные под атлоны?
Слышал, что есть такой, но сам не пробовал.
Интеловский вроде бы нормально работает с Атлонами.
Еще на хоботе были сравнительные обзоры разных компиляторов фортрана.
что затип real16
Это же основы.
Что такое просто real знаешь?
Так вот, он может храниться как 4-х, 8-и и 16-и(не все компиляторы умеют с ним работать, но не, что не умеют, умеют работать с double precision - это вроде бы то же самое) битный тип - соответственно в программе это будет объявляться как real*4, real*8 или real*16, например (есть и другие варианты задания размера).
Я так понял Real16 это 16байтовый с плавающей точкой.
Правильно.
Часть компьютеров оснащены х32 процессорами Атлон
Я использую Intel Fortran. Один из его плюсов для меня - интеграция с VS.net 2003 (с 2005-м пока не умеет
).Еще я пробовал Compaq Fortran 6, но он почти по всем параметрам хуже (хотя если не хочется ставить .net и другие редакторы и работать из командной строки - тогда это вариант).
Слышал много хорошего про Lahey Fortran, но к новым версиям ломалку не нашел (кстати, может у кого есть? поэтому и не пробовал.
Так что мне почти не с чем сравнивать
А если в программе используется тип двойной точности, можно ожидать ускорения работы?
Это который double precision?
Если да, то я его не пробовал, так как не вижу смысла его использовать при наличии real*16.
Но не думаю, что его поведение чем-то отличается от real*16.
Слышал, что есть такой, но сам не пробовал.
АМД компиляторов не выпускает. Специфические оптимизации под атлоны могут делать g77 (gcc.gnu.org g95 (www.g95.org portland compiler (www.pgroup.com pathscale compiler (www.pathscale.com). Мой опыт говорит о том, что от этих оптимизаций толку немного (в пределах 10%). А вообще гугл в помощь, ибо компиляторво фортаран немало есть на свете (из малоизвестных приходят на ум NAG Fotran, тот же Lahey).
Интеловский вроде бы нормально работает с Атлонами.
Да, распознает их как пентиум2, что не мешает ему гененрить весьма и весьма быстрый код, что является лишним доказательством "всеядности" атлоновского FPU
Это же основы.
А мне показалось, что автор треда разбирается в основах
Если да, то я его не пробовал, так как не вижу смысла его использовать при наличии real*16.
Но не думаю, что его поведение чем-то отличается от real*16
Отличается, иначе какой смысл городить такое множество типов данных с плавающей точкой. Грубо говоря, у real*16 точность представления выше, диапазон значений шире, ошибки округления меньше. Но! x86 и x86_64 FPU имеет 80-битные внутренние регистры, SSE2 FPU - 64-x битные. В итоге, 128-битный real*16 туда не влезает и обрабатываться должен в разы медленнее на процессорах IA32 и x86_64. Кстати, из-за большей разрядности регистров x86 FPU там меньше ошибки округления, что иногда влияет на конечный результат, даже с использованием real*8.
за счет увеличения размера и числа регистров
Эх, мало-мало ошибку давал. Увеличилось только число регистров x86 FPU.
А при замере производительности 32-х битный и 64-х битный код использовали SSE2.
Короче, резюме: для обычного атлона годится любой хорошо оптимизирующий компилятор, например intel fortran.
Для атлона 64 нужен компилятор с поддержкой SSE2, не важно 32 или 64 битный. Intel не годится (поддержка SSE2 не активируется, конкуренция, блин, правда АМД сейчас судится с Интел по этому поводу, но результаты вряд ли скоро появятся). Большинство знакомых мне программ используют Portland Group Compiler, он распространен, его можно крякнуть, так что есть смысл ориентироваться на него.
ЗЫ Часто замена алгоритма или правильное использование оптимизированных библиотек дает эффект в разы больший, чем замена компилятора.
А мне показалось, что автор треда разбирается в основах
Ну раз он в них запутался (правда потом вроде бы сам и распутался значит не совсем.
Отличается, иначе какой смысл городить такое множество типов данных с плавающей точкой.
Так это вроде бы так исторически сложилось: когда процы в принципе не могли обрабатывать 128-битные числа - придумали двойную точность.
А потом возможность начала появляться и решили сделать это естественннее.
Хотя точную историю я не знаю.
Грубо говоря, у real*16 точность представления выше, диапазон значений шире, ошибки округления меньше.
В интеловском компиляторе есть просто риал, а есть двойная точность. И каждому можно указать размер независимо (по-умолчанию).
Так если обоим указать 16 - разница все равно будет?
Кстати, оптимизировать можно и используя АМД-шную библиотеку (написанную специально для работы под АМД64).
Но это может потребовать внесения изменений в код.
Но это может потребовать внесения изменений в код.
Похоже, мы сами немного запутались в основах 
Итак, типы данных INTEGER, LOGICAL, REAL and DOUBLE PRECISION были в стандарте Fortran 77, причем реальный размер их ЗАВИСЕЛ от аппаратного обеспечения, для которого компилировалась программа. Точно знаю, что на x86 INTEGER 4-х байтный (компиляторы g77, ifort а на IBM Power64 8-ми байтный (компиляторы g77, xlf). Возможно, есть платформы/компиляторы которые делают REAL по умолчанию 8-байтным, не знаю. Главное, что размер контролировался не в коде программы, а опциями компилятора.
Описание данных с помощью конструкции REAL*x INTEGER*x LOGICAL*x или REAL(KIND=*) и т.д. появилось, если не ошибаюсь, в фортране-90, по крайней мере, в фортране-95 и более поздних оно есть. Причины появления, думаю, понятны: дать возможность управлять размером переменных из программы + много других приятных моментов вроде контроля точности, экономии памяти и т.п..
А вот цитата из мануала к ifort 9.0:
То есть, эти опции управляют размером классических (из F77) типов данных: REAL, DOUBLE, COMPLEX (про производительность не сказано ни слова!). Естественно, компилируя программу с /real_size 128 /double_size 128 ты получешь все переменные REAL и DOUBLE одинакового 128-битного размера. НО! Если объявить переменную REAL*8, то эта переменная так и останется REAL*8.
ЗЫ В ОС с поддержкой x86_64/EM64T integer по умолчанию - 4-х байтный! Например, g77 вообще не поддерживает 8-ми байтный integer на x86_64, и gcc тоже. Т.е. все что поменялось - размер указателя (pointer и , соответственно, возможность адресовать больше памяти.
ЗЗЫ Оптимизированные библиотеки - это, как правило, ускоренные версии наиболее популярных подпрограмм из www.netlib.org, которыми пользуются большинство культурных программистов на Фортране. Так что в большинстве случаев дело ограничивается поиском кусков нетлибовсоко кода (BLAS/LAPACK/FFT/SCALAPACK и т.п.) и линковки вместо него оптимизированных бибилотек.
Итак, типы данных INTEGER, LOGICAL, REAL and DOUBLE PRECISION были в стандарте Fortran 77, причем реальный размер их ЗАВИСЕЛ от аппаратного обеспечения, для которого компилировалась программа. Точно знаю, что на x86 INTEGER 4-х байтный (компиляторы g77, ifort а на IBM Power64 8-ми байтный (компиляторы g77, xlf). Возможно, есть платформы/компиляторы которые делают REAL по умолчанию 8-байтным, не знаю. Главное, что размер контролировался не в коде программы, а опциями компилятора.
Описание данных с помощью конструкции REAL*x INTEGER*x LOGICAL*x или REAL(KIND=*) и т.д. появилось, если не ошибаюсь, в фортране-90, по крайней мере, в фортране-95 и более поздних оно есть. Причины появления, думаю, понятны: дать возможность управлять размером переменных из программы + много других приятных моментов вроде контроля точности, экономии памяти и т.п..
А вот цитата из мануала к ifort 9.0:
real_size 32 Makes default real and complex variables 4 bytes long. REAL declarations are treated as single precision REAL (REAL(KIND=4 and COMPLEX declarations are treated as COMPLEX (COMPLEX(KIND=4.
real_size 64 Makes default real and complex variables 8 bytes long. REAL declarations are treated as DOUBLE PRECISION (REAL(KIND=8 and COMPLEX declarations are treated as DOUBLE COMPLEX (COMPLEX(KIND=8.
real_size 128 Makes default real and complex variables 16 bytes long. REAL declarations are treated as extended precision REAL (REAL(KIND=16; COMPLEX and DOUBLE COMPLEX declarations are treated as extended precision COMPLEX (COMPLEX(KIND=16.
double_size 64 Defines DOUBLE PRECISION declarations, constants, functions, and intrinsics as REAL(KIND=8) (REAL*8) and defines DOUBLE COMPLEX declarations, functions, and intrinsics as COMPLEX(KIND=8) (COMPLEX*16).
double_size 128 Defines DOUBLE PRECISION declarations, constants, functions, and intrinsics as REAL(KIND=16) (REAL*16) and defines DOUBLE COMPLEX declarations, functions, and intrinsics as COMPLEX(KIND=16) (COMPLEX*32).
То есть, эти опции управляют размером классических (из F77) типов данных: REAL, DOUBLE, COMPLEX (про производительность не сказано ни слова!). Естественно, компилируя программу с /real_size 128 /double_size 128 ты получешь все переменные REAL и DOUBLE одинакового 128-битного размера. НО! Если объявить переменную REAL*8, то эта переменная так и останется REAL*8.
ЗЫ В ОС с поддержкой x86_64/EM64T integer по умолчанию - 4-х байтный! Например, g77 вообще не поддерживает 8-ми байтный integer на x86_64, и gcc тоже. Т.е. все что поменялось - размер указателя (pointer и , соответственно, возможность адресовать больше памяти.
ЗЗЫ Оптимизированные библиотеки - это, как правило, ускоренные версии наиболее популярных подпрограмм из www.netlib.org, которыми пользуются большинство культурных программистов на Фортране. Так что в большинстве случаев дело ограничивается поиском кусков нетлибовсоко кода (BLAS/LAPACK/FFT/SCALAPACK и т.п.) и линковки вместо него оптимизированных бибилотек.
Так это вроде бы так исторически сложилось: когда процы в принципе не могли обрабатывать 128-битные числа - придумали двойную точность\
Я не уверен, что даже сейчас существуют процы, FPU которых может аппаратно обрабатывать числа такого размера за разумное количество тактов (ну разве что итаниум?). Но сейчас все решается просто, с помощью multiple precision library можешь делать на любом fpu любую точность, вопрос только в скорости. Одно знаю точно - современные x86/AMD64/PowerPC64 архитектуры заточены под работу с 8-байтными числами с плавающей точкой.
Это все так, но это все не противоречит моим словам.
Просто я явно не указал, что говорю именно про компиляторы фортрана от Compaq и от Intel.
А то вот вчера появилось ie64 - глядишь завтра появится fe128
Просто я явно не указал, что говорю именно про компиляторы фортрана от Compaq и от Intel.
Я не уверен, что даже сейчас существуют процы, FPU которых может аппаратно обрабатывать числа такого размера за разумное количество тактовНу так тенденция же есть. Вот создатели компиляторов и подстраховываются.
А то вот вчера появилось ie64 - глядишь завтра появится fe128
заточены под работу с 8-байтными числами с плавающей точкой.Так регистры современных fpu 10-байтные - почему использовать можно только 8 из них?
Это все так, но это все не противоречит моим словам.
Ну да. А я и не спорил, наоборот, все это написал чтобы говорить как можно конкретнее и не спорить о терминах. (я серьезно)
Ну так тенденция же есть. Вот создатели компиляторов и подстраховываются.
Ну есть, но не такая сильная. Просто имхо мало пока задач сейчас где позарез нужны были бы апаратные 16-байтные плавающие числа, большинству хватает обычной double precision. Вот 8-байтные integer и pointer - это да, при современных объемах оперативной памяти и жестких дисков весьма актуальны. Не спорю, многие живут под freebsd 4 и не замечают ограничения на размер файла в 2 гига, а кому-то это ограничение поперек горла. Да и криптографии integer*8 сильно помогает, вроде как.
Так регистры современных fpu 10-байтные - почему использовать можно только 8 из них?
ЭЭ, не всех. Например, регистры SSE2 и Altivec (аналог SSE из мира Power PC) 64-х битные. А именно 8 байт, по-моему (могу ошибаться из-за размера строки кеша 8 байт, то есть такими блоками проц читает и пишет данные в память. 10-байтные регистры это фирменная фича x86 FPU, появилась в первых пнях и жива до сих пор, собственно введена для увеличения точности промежуточных вычислений и уменьшения ошибок округления, и, соответсвенно, численных нестабильностей кода. На счет наличия аппаратных команд сохранения всех 80 бит в память не уверен, ибо не оптимально это. Кроме того, ходят слухи, что современные х86 процы подсчитывают эти последние биты не так точно, как значащие, ибо нафик тратить ресурсы, если в итоге надо будет получить округленное значение. SSE2/Altivec работают хитрее, там большие регистры не нужны.
> Так регистры современных fpu 10-байтные - почему использовать можно
> только 8 из них?
Отлично можно использовать, разве есть проблемы какие-то?
> только 8 из них?
Отлично можно использовать, разве есть проблемы какие-то?
Отлично можно использовать, разве есть проблемы какие-то?
Ээх как бы проверить-то ни у кого нет под рукой справочника по ассемблеру?
Я не против.
все это написал чтобы говорить как можно конкретнее и не спорить о терминах
Только тогда мб вообще фак по фортрану сделать? (насколько я понимаю, такого пока нет, иначе была бы ссылка/цитата оттуда.
Так мы вроде бы пришли к тому, что real*8 двойной точности по крайней мере по размеру соответствует real*16 (если он соответствует только real*8, то смысла его использования вообще нет.
большинству хватает обычной double precision
Тогда твоя фраза несколько необычна, так как неважно, что используется - важно то, что в обоих вариантах аппаратной обработки не получается. Или что ты имел в виду?
Многие задачи численного моделирования выигрывают в точности (а зачастую иначе и не удается получить нужный результат) при использовании real*16 вместо real*8, но при этом они начинаю работать значительно медленнее
мало пока задач сейчас где позарез нужны были бы апаратные 16-байтные плавающие числа
Так что такие задачи есть.
Можно подробнее?
SSE2/Altivec работают хитрее, там большие регистры не нужны.
Как их можно использовать из фортрана?
Отлично можно использовать, разве есть проблемы какие-то?
Единственный вариант, который я знаю - вставка кода на С, а уже в нем ассемблерная вставка.
Это очень кривой вариант - почему бы тогда вообще не писать все на С?
Тем более, что есть и другие возможности, недоступные из фортрана: умножение, результатом которого является все произведение (переполнение сверх слова возвращается вторым словом результата например (я про это уже писал, кстати).
Только тогда мб вообще фак по фортрану сделать? (насколько я понимаю, такого пока нет, иначе была бы ссылка/цитата оттуда.
Да книжек много, сейчас времени нет, я приведу ссылки
Так мы вроде бы пришли к тому, что real*8 двойной точности по крайней мере по размеру соответствует real*16 (если он соответствует только real*8, то смысла его использования вообще нет.
Тогда твоя фраза несколько необычна, так как неважно, что используется - важно то, что в обоих вариантах аппаратной обработки не получается. Или что ты имел в виду?
Нет, ты не понял. REAL*8 по задумке F90 это всегда 64-х битное число с плавающей точкой. DOUBLE PRECISION может быть разным в зависимости от аппаратной части или ключей компилятора. Там же в мануале написано /double_sise 128 делает DOUBLE PRECISION эквивалентом REAL*16, по умолчанию DOUBLE PRECISION эквивалент REAL*8. Мои слова "обычный DOUBLE PRECISION" это неудачный жаргонизм, я имел в виду REAL*8.
Самый ужас состоит в том, что некоторые компиляторы рассматривают DOUBLE PRECISION и REAL*8 как одно и тоже, и ключи, влияющие на размер DOUBLE PRECISION меняют и размер REAL*8 но это по идее отклонения от стандарта.
Можно подробнее?
Пока нет - я уже все позабывал, надо заново поботать доки. В понедельник вернусь -там посмотрим.
Нет, ты не понял. ... DOUBLE PRECISION может быть разным в зависимости от аппаратной части или ключей компилятораЯ понял, но я вообще не вижу смысла рассматривать double precision, если он не дает новых возможностей.
Пока не было real*16, он имел смысл как удвоение real*8 (а если это было не так для конкретного компилятора, то зачем его тогда там вообще использовать?).
А с появлением real*16 он теряет смысл, так как вообще ничего нового не позволяет делать
Он имеет смысл, чтобы при правильном написании программ
повысить точность наименьшими усилиями.
DOUBLE PRECISION --- для промежуточных подсчётов,
SINGLE PRECISION --- для окончательных выводов.
---
...Я работаю антинаучным аферистом...
повысить точность наименьшими усилиями.
DOUBLE PRECISION --- для промежуточных подсчётов,
SINGLE PRECISION --- для окончательных выводов.
---
...Я работаю антинаучным аферистом...
Насчет g77 - он уже давно gfortran (Fortran 95). Не скажу, насколько лучше он поддерживает F95, чем g95, но в его пользу то, что он включен в FSF GCC, в отличие от. Btw, через пару недель ожидается gcc 4.1.0.
Внимание !
Есть ли в сетке Intel Fortran Compiler x32 for Windows ?
lorien на вопрос intel fortran, нашел только intel fortran for linux x64
!Есть ли в сетке Intel Fortran Compiler x32 for Windows ?
lorien на вопрос intel fortran, нашел только intel fortran for linux x64
UP!
А это не то, что нужно?
Я туда уже отправил запрос.
Но evaluation не есть предел мечтаний
Но evaluation не есть предел мечтаний
Короче, поиск по форуму рулит - посмотри здесь:
Можно попробовать сначала поискать в сети по имени файла - вдруг кто-то уже скачал с тех пор (еще можно обратиться к автору той темы).
Можно попробовать сначала поискать в сети по имени файла - вдруг кто-то уже скачал с тех пор (еще можно обратиться к автору той темы).
Ок спасибо, сча спрошу!
Оставить комментарий
vertyal17
Есть ли в сетке Intel Fortran Compiler x32 for Windows ?lorien на вопрос intel fortran, нашел только intel fortran for linux x64