olpi
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Это у меня на самом деле AMD64. А время счета при переходе от real*8 к real*16 увеличивается не в полтора раза (это было-бы великое счастье!), а примерно в 25 раз. Вы не внимательно читали тот мой пост, я там специально привел небольшое описание решаемой задачи. Для real*8 прогнозирование движения делалось на 1000000 суток, а для real*16 - всего на 10000 суток. И потом, метод численного интегрирования для real*8 был 15 порядка, а для real*16 - 31 порядка, который сам по себе работает дольше, т.е. решались разные задачи, и по быстродействию их сравнивать нельзя. Я так подобрал просто для того, чтобы не ждать сильно долго пока посчитает. Что же мне запускать пучок из 10000 вероятностных траекторий и ждать несколько суток? Это я к тому, что у меня тоже есть задачи, требующие долгого счета (а не на коленке).
Сравнивать можно только ia32 real*8 c intel64 real*8 и ia32 real*16 c intel64 real*16, так как в обоих случаях решались одинаковые задачи.
Добавлено:
Цитата:| Но, если Вы планируете программу отпустить от себя, или не надеетесь на память, то надо все делать так, чтобы результат вычислений был на всех машинах и при любых разумных опциях компилятору один и тот же. Вот тут и пригодится буква D. Так как в норме при присвоении восьмибайтовому числу 1. и 1.D0 получается разный результат. |
Да ради бога, пишите "D", кому она мешает. А причем здесь память, по промежуточным выдачам сразу будет видно, с какой точностью ведется счет.
Цитата:| У меня есть одно правило- никогда не доверять компилятору. Поэтому я тестирую программу минимум на трех из них. |
Я тоже транслирую двумя компиляторами, еще использую Salford Fortran ftn95. Кстати это, похоже единственный компилятор, позволяющий работать с 19-разрядной машинной точностью (как Паскаль), т.е. с типом real*10 |
