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

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

Модерирует : 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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329

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

akaGM

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

прежде чем просить помощи в задании
платное решение задач

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


если вам вдруг не отвечают или ответ вас не устраивает
и вообще полезно прочитать всем спрашивающим
 
просьба к пишущим и отвечающим все большие листинги оформлять тегом more
и отключать графические смайлики при размещении фортран-кода

Всего записей: 24056 | Зарегистр. 06-12-2002 | Отправлено: 18:11 14-01-2007 | Исправлено: akaGM, 09:47 01-03-2020
KChernov



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

Цитата:
Потому-что я себе тяжело представляю, что от смены архитектуры скорость вычислений возрастает в два раза

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

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 22:29 04-12-2009
terminat0r



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
KChernov
о целых числах и операциях с ними я в принципе в курсе. На x86_64 архитектуре уже более 8 лет. Вот только радикального роста производительности программ еще не замечал. Наверно стоит пройтись профайлером и проверить .

Всего записей: 2084 | Зарегистр. 31-03-2002 | Отправлено: 22:52 04-12-2009
olpi

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

Цитата:
а ты уверен, что поставил 64-битную версию IF?  
директории  
bin\ia32_intel64  
bin\intel64  
есть?  
такие же диры должнв быть в lib и include  
и ставит их сам IF, а не студия...

Да, все эти директории есть. Я кажется понял, в чем дело. У меня для 64-битного target не происходит линковка, пишет, что link не найден. Посмотрел переменную среды PATH, так там стоят только пути %IFORT_COMPILER11%lib\ia32;C:\Program Files (x86)\Intel\Compiler\11.0\066\fortran\mkl\ia32\bin; а для intel64 не стоят. В понедельник на работе попробую поставить их вместо ia32 (64-битная винда у меня только там).

Цитата:
Потому-что я себе тяжело представляю, что от смены архитектуры скорость вычислений возрастает в два раза

Но это на самом деле так, программа отранслированная как 32-битная считает вдвое медленнее, чем 64-битная (на 64-битном процессоре). Я имею в виду чисто вычислительное консольное приложение безо всяких там windows-наворотов.  

Всего записей: 116 | Зарегистр. 17-05-2008 | Отправлено: 22:11 05-12-2009 | Исправлено: olpi, 22:16 05-12-2009
FuzzyLogic



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

Цитата:
Но это на самом деле так, программа отранслированная как 32-битная считает вдвое медленнее, чем 64-битная (на 64-битном процессоре). Я имею в виду чисто вычислительное консольное приложение безо всяких там windows-наворотов.  

 
ia32

Код:
 
time ../ch3d/ch3d.Linux.32
54.625u 0.133s 0:55.18 99.2%    0+0k 0+0io 10pf+0w
 

 
intel64

Код:
 
time ../ch3d/ch3d.Linux.64
51.003u 0.143s 0:51.47 99.3%    0+0k 0+0io 13pf+0w
 

И откуда вы такое придумали? :\
 
Добавлено:
KChernov

Цитата:
На умножении 64-битных целых 64-битная версия ускоряется реально в 2 раза.

Именно что целых, сколько счётных приложений реально оперирует 64-битными целыми числами? Реально не знаю ни одного приложения где производительность бы столь значительно выиграла от перехода с 32 на 64.

Всего записей: 1920 | Зарегистр. 27-07-2002 | Отправлено: 05:33 06-12-2009
olpi

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
А какую вещественную арифметику вы используете? То есть, с какой точностью считаете? Я сравнивал быстродействие при счете с расширенной 34-разрядной десятичной точностью, которую я обычно использую. Для этого программа транслируется с опцией /real-size:128 (для командно-строчного компилятора). А если работать в оболочке Visual Studio то в свойствах проекта ставится default real size 16 байт. При расчетах с такой точностью быстродействие увеличивается примерно в два раза. А для обычной двойной точности (real*8) может и правда нет никакого выигрыша, еще не сравнивал.

Всего записей: 116 | Зарегистр. 17-05-2008 | Отправлено: 19:06 06-12-2009
akaGM

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

Цитата:
А какую вещественную арифметику вы используете? То есть, с какой точностью читаете?

всё от задачи зависит...
если нормально отнормировать, то и даблов вполне хвататет

Всего записей: 24056 | Зарегистр. 06-12-2002 | Отправлено: 19:38 06-12-2009
FuzzyLogic



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

Цитата:
А какую вещественную арифметику вы используете?

процентов 10 - real*8, остальное real*4. Потому как  

Цитата:
если нормально отнормировать...


Всего записей: 1920 | Зарегистр. 27-07-2002 | Отправлено: 21:53 06-12-2009
olpi

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Даа.. Просто вы не представляете, что бывают задачи, где никакое нормирование не поможет. Это задачи на численное интегрирование дифференциальных уравнений движения многих притягивающихся тел на большой промежуток времени. Тогда ошибка округления постепенно забивает все  16 разрядов и даже больше. Поэтому приходится использовать расширенную точность.

Всего записей: 116 | Зарегистр. 17-05-2008 | Отправлено: 22:10 06-12-2009
terminat0r



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

Цитата:
Я сравнивал быстродействие при счете с расширенной 34-разрядной десятичной точностью, которую я обычно использую.

Подозреваю что вы сравнивали в таком случае скорость программной и "железной" реализации работы с числами большой точности.

Всего записей: 2084 | Зарегистр. 31-03-2002 | Отправлено: 22:13 06-12-2009
olpi

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Чтобы не быть голословным провел тестовые расчеты, интегрируя задачу 12 тел (тестовое тело плюс 9 возмущающих планет и Луна), движущихся вокруг Солнца.
Транслировал  и считал на одном компе, но двумя разными компиляторами (для IA32 и Intel64), входящими в состав Intel Fortran 11.0.
Результаты по времени счета такие:
 
Для 16-разрядной точности (real*8) интегрирование методом Эверхарта 15 порядка с переменным шагом на 1000000 суток:
IA32 - 144.07 сек
Intel64 - 146.07 сек
Получается, что при расчетах с обычной точностью real*8 (double precision) никакого выигрыша в скорости действительно нет.
 
Для 34-разрядной точности (real*16) интегрирование методом Эверхарта 31 порядка с переменным шагом на 10000 суток:
IA32 - 389.75 сек
Intel64 - 223.06 сек
Отношение 389.75/223.06=1.75   Т.е., на расширенной разрядной сетке 64-битовая архитектура позволяет считать на 75% быстрее, или примерно вдвое, как я и говорил.

Всего записей: 116 | Зарегистр. 17-05-2008 | Отправлено: 08:38 07-12-2009 | Исправлено: olpi, 08:42 07-12-2009
akaGM

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

Цитата:
(real*16)
IA32
- 389.75 сек
Intel64 - 223.06 сек

это, извиняюсь, херня, т.к. quad-точность для ia32 совсем неродной формат...
или более мягко:

Цитата:
terminat0r
Подозреваю что вы сравнивали в таком случае скорость программной и "железной" реализации работы с числами большой точности

во-во, на каком железе это запускалось?

Всего записей: 24056 | Зарегистр. 06-12-2002 | Отправлено: 12:54 07-12-2009
terminat0r



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
olpi
Вообще-то вы задали хороший вопрос. Мне вот интересно, подключаются ли доп. регистры процессора, если 32 розрядная программа с quad точностью запускается на 64 процессоре? Вы делали все результаты на 64 разрядном процессоре? Покажите какие опции оптимизации передавались компилятору в каждом случае. И попробуйте сделать тест для программ без оптимизации (т е  -O0) и с макс оптимизацией .  
 
Я вот поискал на интеле

Цитата:
Our implementation of REAL(16) is the same on all platforms we support.  It is all done in software using integer arithmetic, so has no relationship to floating point hardware support.

Тоесть- разница в том, что в одном случае программа использует доп регистры (после компиляции для 64) процессора, а во втором- нет.  

Всего записей: 2084 | Зарегистр. 31-03-2002 | Отправлено: 16:55 07-12-2009 | Исправлено: terminat0r, 20:47 07-12-2009
olpi

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

Цитата:
Цитатаreal*16)  
IA32 - 389.75 сек  
Intel64 - 223.06 сек  
 
это, извиняюсь, херня, т.к. quad-точность для ia32 совсем неродной формат...  

 
У вас где глаза, или вы считаете, что если факты вам не нравятся, то тем хуже для фактов? Хотите я вам пришлю (или выложу куда-нибудь) исходник программы, и вы ее оттранслируете и запустите у себя?
А на каком железе запускалось, нетрудно догадаться, раз запускалось и 64-битное приложение,  и 32-битное. Написано же, транслировал и считал на одном и том же компе, т.е. на 64-разрядном.
 

Цитата:
Вы делали все результаты на 64 разрядном процессоре? Покажите какие опции оптимизации передавались компилятору в каждом случае. И попробуйте сделать тест для программ без оптимизации (т е  -O0) и с макс оптимизацией .

На первый вопрос я уже ответил, а опции в обоих случаях использовались совершенно одинаковые (всего две) /Ox - оптимизация по скорости и вторая опция /real-size:64 или /real-size:128 - размер вещественных чисел.
Я считаю под Windows, а под Linux, если не ошибаюсь, им соответствуют опции -O и -r8 или -r16
 
Да, еще по поводу "программной" и "железной" реализации типа real*16. Реализация этого типа всегда программная, "железной" не существует, во всяком случае для ПК. Это же чисто фортрановская особенность, ни в одном другом языке прграммирования такого типа нет (даже на Си).

Всего записей: 116 | Зарегистр. 17-05-2008 | Отправлено: 17:58 07-12-2009 | Исправлено: olpi, 18:11 07-12-2009
terminat0r



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

Цитата:
Это же чисто фортрановская особенность, ни в одном другом языке прграммирования такого типа нет (даже на Си).  

ну почему же, icc  кушает вот такие опции -Qoption,cpp,--extended_float_type
и используя _Quad тип интеловского компилятора можно получить кажется те же самие значащие цифры. (Но я не проверял )
Для других языков существуют давно уже библиотеки с коль угодно большой точностью. Вот для C/Cpp
http://gmplib.org
http://www.mpfr.org
http://www.moshier.net/#Cephes
Для  fortran они тоже есть уже очень давно
http://crd.lbl.gov/~dhbailey/mpdist
Другое дело в том, что интеловцы это реализовали сразу в компиляторах.  
Хотя вот смотрю в g95 тоже real(kind=16) уже есть (экспериментально). Со временем подтянутся и другие.
Добавлено:

Цитата:
Реализация этого типа всегда программная, "железной" не существует, во всяком случае для ПК.

Конечно, но это не означает что это новомодная тенденция. IBM System/370 поддерживали "почти железные" 128 bit floating point numbers еще в какие-то там лохматые семидесятые.

Всего записей: 2084 | Зарегистр. 31-03-2002 | Отправлено: 20:09 07-12-2009 | Исправлено: terminat0r, 21:04 07-12-2009
olpi

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Про подобные библиотеки я прекрасно знаю, когда-то интересовался. Например у Бейли число четверной точости хранится в виде двух чисел обычной двойной точности и сделана вся арифметика. Но это все не то - чтобы их использовать, надо менять код программы, числа задавать в виде строк и т.д. и т.п. А как вы сами сказали, прямо в компиляторах это реализовано только на фортране, причем не только интеловском. Есть еще Lahey/Fujitsu, может еще появились какие-нибудь.  
Это ведь совсем другое дело, когда все делается компилятором - можно старые программы оттранслировать с опцией /real-size:128 или /double-size:128 (это если в числах понапихана горячо любимая и столь же ненужная буква "D") и считать с расширенной точностью.
 
Добавлено:
Кстати, разобрался, почему Visual Studio 2008 у меня не позволяет создавать 64-битный код. Оказывается она какая-то недоделанная, или это у меня попалась какя-то паленая версия. После ее установки в папке C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\  отутствуют директории amd64, x64, ia64 и т.д., т.е. все директории с числом 64 в названии. А на них есть ссылки в файле vcvarsall.bat.
Установил Visual Studio 2005 и там эти директории есть и трансляция для 64-битового режима проходит.  

Всего записей: 116 | Зарегистр. 17-05-2008 | Отправлено: 22:03 07-12-2009
terminat0r



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

Цитата:
это если в числах понапихана горячо любимая и столь же ненужная буква "D"

Вы действительно так считаете? Обьясните

Всего записей: 2084 | Зарегистр. 31-03-2002 | Отправлено: 23:08 07-12-2009
KChernov



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

Цитата:
Про подобные библиотеки я прекрасно знаю, когда-то интересовался. Например у Бейли число четверной точости хранится в виде двух чисел обычной двойной точности и сделана вся арифметика. Но это все не то - чтобы их использовать, надо менять код программы, числа задавать в виде строк и т.д. и т.п.

Вот и ещё один недостаток Фортрана по отношению к тому же С++.
 

Цитата:
это если в числах понапихана горячо любимая и столь же ненужная буква "D"
Вы действительно так считаете? Обьясните

А зачем она реально нужна?
Современные компиляторы умеют использовать функции сообразно типу объявленных данных.
А лучше вообще для определения длины основного типа использовать директиву компилятора, а вот для вспомогательных (типа тех же счётчиков) - задавать явно при описании (при необходимости конечно). Тогда точность всей программы можно будет менять не трогая код вообще.

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 10:38 08-12-2009
FuzzyLogic



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

Цитата:
 Вот и ещё один недостаток Фортрана по отношению к тому же С++.  

Подход Бейли к числам недостаток Фортрана? :\

Цитата:
Тогда точность всей программы можно будет менять не трогая код вообще.

Имхо, проблема в том что люди в данном топике занимаются разительно разными проблемами. Подобный подход в проблемах с интенсивными вычислениями это просто ужас. У нас сейчас партнёры такие, у них модель вся написана на сях с применением объектно ориетированного программирования, очень всё гибко, и точно прям как вы сказали регулируется "одним взмахом директивы компилятора", в общем лепота. А с нашей стороны ужас какой-то, Фортран галимый, кругом статические массивы, точность буковками проставлена, вот только один момент ... эксперимент на который у них уходит почти неделя, я обсчитываю за 4-6 часов. Потому что у меня даже массивы так лежат чтобы кэш максимально эффективно использовался. Именно потому я за этот год 8 статей написал, и ещё штук 20 в соавторстве, так как не жду пока у меня кластер неделю что-то там переваривает, вечером оставил - утром результат.
 
О чём это я, а да ... если что-то обсчитывается порядка 5 минут, то писать можно хоть карандашом на коленке, но имхо (если нет проблем с лицензированием итд) то на Матлабе. Не шибко быстро, зато куча всего реализованного и тут же не отходя от кассы имеется доступ к огромному инструментарию на любой случай жизни от FFT до графики. А вот если проблема действительно емкая в плане счёта, вот тогда я в большинстве случаев предпочту скорость гибкости.

Всего записей: 1920 | Зарегистр. 27-07-2002 | Отправлено: 11:14 08-12-2009
KChernov



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

Цитата:
вот только один момент ... эксперимент на который у них уходит почти неделя, я обсчитываю за 4-6 часов. Потому что у меня даже массивы так лежат чтобы кэш максимально эффективно использовался.

Не верю в разницу на порядок (даже от 20 до 40 раз).
Скорее всего проблема в чём-то ещё.

Всего записей: 2471 | Зарегистр. 20-04-2004 | Отправлено: 12:33 08-12-2009 | Исправлено: KChernov, 12:34 08-12-2009
terminat0r



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

Цитата:
А зачем она реально нужна?  

Она по-моему нужна там, где используются старые функции (только не говорите что у вас все уже как минимум на f90), в которых нет вначале  
implicit none
и все константы double precision заданы именно в таком формате.
Попробуйте в таких сорцах поменять D на E.
 
 
Добавлено:

Цитата:
Не верю в разницу на порядок (даже от 20 до 40 раз).
Скорее всего проблема в чём-то ещё.

Конечно, разница несомненно в
Цитата:
Потому что у меня даже массивы так лежат чтобы кэш максимально эффективно использовался. Именно потому я за этот год 8 статей написал, и ещё штук 20 в соавторстве,

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

Всего записей: 2084 | Зарегистр. 31-03-2002 | Отправлено: 16:05 08-12-2009 | Исправлено: terminat0r, 16:20 08-12-2009
Открыть новую тему     Написать ответ в эту тему

Страницы: 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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы программирования на FORTRAN (ФОРТРАН)


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru