компиляторы
Найдено: 2 записи
Программирование →
Ошибки вычислений в окрестностях машинного нуля
Периодически на хабре возникают замечательные статьи о тонкостях арифметики с плавающей точкой. Собственно, упомянутая публикация стала одним из первых источников, прочитанных при попытках разобраться с проблемой. Яснее от этого сразу не стало, но тем не менее, организация нейронных связей как-то упорядочилась. Ближе к делу.
Проблема образовалась при выполнении расчётов в рамках одного проекта и будущей магистерской диссертации по гидродинамике пористой среды. Не скрою, что корни скрыты отчасти в личной криворукости автора и пренебрежении банальными общеизвестными советами касательно обработки малых чисел, но тем не менее, это привело к достаточно интересным наблюдениям и размышлениям.
Если отбросить физическую суть, то задача состоит в необходимости решения системы семи уравнений в частных производных. Сказано-сделано, сложности в этом особой нет — пишем явную конечно-разностную схему, распараллеливаем на OpenMP и после окончательной синтаксической отладки и оптимизации скорости «машинка начинает шуршать».
Вычислительная конфигурация: видавший виды HP 550 с Core 2 Duo 1.8 ГГц на борту, под управлением Ubuntu 11.04.
Компиляторы: gfortran 4.5.2 и Intel Fortran Compiler 12.1.0.
В начальных условиях предполагается, что внутри расчётной области совсем нет воды в жидком состоянии — она появляется в процессе фазовых превращений. И именно это отсутствие сыграло главную роль в нашем спектакле.
Итак, воды в области нет. Что же хочется написать в начальном условии? Естественно, сразу же было написано 0.0D+00 (программа написана с двойной точностью вещественных чисел). Счёт на первоначальных этапах идёт в непосредственной окрестности машинного нуля. Каковы результаты? Посмотрим на график:
Здесь изображено распределение насыщенности пор водой вдоль координаты в наиболее интересной части расчётной области по прошествии чуть более суток физического времени модели.
Нужное отступление о подписях в легенде графика: всего было опробовано 18 различных комбинаций ключей (6 для gfortran и 12 для ifort), однако многие из них давали абсолютно одинаковые результаты, и потому объединены. Квадратные скобки в легенде означают, что могла быть написана любая из заключённых в них опций. Например, «шифровка» -O[1,2,3] [-fp-model [strict] [precise]] говорит о том, что компилятор использовался с оптимизацией всех возможных уровней, и дополнительно могла быть включена одна моделей вычислений с плавающей точкой (а могла быть и не включена). Три варианта (два от -fp-model и один без неё) умножить на три уровня оптимизации — итого девять комбинаций. Все они оказались эквивалентны.
А теперь результат. Нечто реалистичное и физически возможное удалось получить только на gfortran без включения соответствия стандарту IEEE 754 (ключ -ffloat-store). Весь остальной хаос линий не содержит ни капельки физического смысла, потому что даже математически уравнения этого не допускают. Изначально подозревавшаяся неустойчивость разностной схемы была оправдана, поскольку никакие методы борьбы с ней к успеху не привели.
Было замечено, что при наличии воды в начальный момент счёт остаётся устойчивым и различия между опциями и компиляторами скрываются в окрестности шестой значащей цифры. И т.к. характерные порядки величины, судя по полученным графикам, должны быть в районе 1.0e-2, то в начальное условие было вписано некоторое ненулевое значение, но очень маленькое. Подбором удалось установить, что для 8-байтового real оно должно быть не менее 1.0e-21. И тогда:
Да, здесь, как и написано в легенде, на самом деле пять графиков. Просто мы получаем то самое различие в пределах шестой значащей цифры.
Причины? Вполне очевидны. Они лежат в тонкостях одновременной обработки больших и малых чисел. И тот факт, что явление настолько существенно по своим масштабам, был, в общем-то, ожидаемым. Но, прежде всего, интерес вызывает нестабильность работы действительно отличного инструмента от Intel на фоне относительного успеха gfortran 4.5.2. Стоит отметить, что подобные проблемы были также найдены при расчётах на старой версии gfortran 4.1.2 с включённой оптимизацией и без других опций, установленной на доступном кластере (под управлением Slamd64), однако им тогда не было уделено должного внимания.
Соответствие IEEE 754, как ни странно, сыграло критическую роль для gfortran. Без него счёт достаточно стабильный и точный. Для детища Intel это оказалось не столь существенно, ибо оно и так не работало корректно.
Итак, выводы и мысли о причинах увиденного.
Тестирование компиляторов на соответствие IEEE 754 проводилось с помощью FORTRAN-версии «Floating point paranoia» Уильяма Кэхэна.
Проблема образовалась при выполнении расчётов в рамках одного проекта и будущей магистерской диссертации по гидродинамике пористой среды. Не скрою, что корни скрыты отчасти в личной криворукости автора и пренебрежении банальными общеизвестными советами касательно обработки малых чисел, но тем не менее, это привело к достаточно интересным наблюдениям и размышлениям.
Если отбросить физическую суть, то задача состоит в необходимости решения системы семи уравнений в частных производных. Сказано-сделано, сложности в этом особой нет — пишем явную конечно-разностную схему, распараллеливаем на OpenMP и после окончательной синтаксической отладки и оптимизации скорости «машинка начинает шуршать».
Вычислительная конфигурация: видавший виды HP 550 с Core 2 Duo 1.8 ГГц на борту, под управлением Ubuntu 11.04.
Компиляторы: gfortran 4.5.2 и Intel Fortran Compiler 12.1.0.
В начальных условиях предполагается, что внутри расчётной области совсем нет воды в жидком состоянии — она появляется в процессе фазовых превращений. И именно это отсутствие сыграло главную роль в нашем спектакле.
Итак, воды в области нет. Что же хочется написать в начальном условии? Естественно, сразу же было написано 0.0D+00 (программа написана с двойной точностью вещественных чисел). Счёт на первоначальных этапах идёт в непосредственной окрестности машинного нуля. Каковы результаты? Посмотрим на график:
Здесь изображено распределение насыщенности пор водой вдоль координаты в наиболее интересной части расчётной области по прошествии чуть более суток физического времени модели.
Нужное отступление о подписях в легенде графика: всего было опробовано 18 различных комбинаций ключей (6 для gfortran и 12 для ifort), однако многие из них давали абсолютно одинаковые результаты, и потому объединены. Квадратные скобки в легенде означают, что могла быть написана любая из заключённых в них опций. Например, «шифровка» -O[1,2,3] [-fp-model [strict] [precise]] говорит о том, что компилятор использовался с оптимизацией всех возможных уровней, и дополнительно могла быть включена одна моделей вычислений с плавающей точкой (а могла быть и не включена). Три варианта (два от -fp-model и один без неё) умножить на три уровня оптимизации — итого девять комбинаций. Все они оказались эквивалентны.
А теперь результат. Нечто реалистичное и физически возможное удалось получить только на gfortran без включения соответствия стандарту IEEE 754 (ключ -ffloat-store). Весь остальной хаос линий не содержит ни капельки физического смысла, потому что даже математически уравнения этого не допускают. Изначально подозревавшаяся неустойчивость разностной схемы была оправдана, поскольку никакие методы борьбы с ней к успеху не привели.
Было замечено, что при наличии воды в начальный момент счёт остаётся устойчивым и различия между опциями и компиляторами скрываются в окрестности шестой значащей цифры. И т.к. характерные порядки величины, судя по полученным графикам, должны быть в районе 1.0e-2, то в начальное условие было вписано некоторое ненулевое значение, но очень маленькое. Подбором удалось установить, что для 8-байтового real оно должно быть не менее 1.0e-21. И тогда:
Да, здесь, как и написано в легенде, на самом деле пять графиков. Просто мы получаем то самое различие в пределах шестой значащей цифры.
Причины? Вполне очевидны. Они лежат в тонкостях одновременной обработки больших и малых чисел. И тот факт, что явление настолько существенно по своим масштабам, был, в общем-то, ожидаемым. Но, прежде всего, интерес вызывает нестабильность работы действительно отличного инструмента от Intel на фоне относительного успеха gfortran 4.5.2. Стоит отметить, что подобные проблемы были также найдены при расчётах на старой версии gfortran 4.1.2 с включённой оптимизацией и без других опций, установленной на доступном кластере (под управлением Slamd64), однако им тогда не было уделено должного внимания.
Соответствие IEEE 754, как ни странно, сыграло критическую роль для gfortran. Без него счёт достаточно стабильный и точный. Для детища Intel это оказалось не столь существенно, ибо оно и так не работало корректно.
Итак, выводы и мысли о причинах увиденного.
- Наиболее вероятным кандидатом на роль причины наблюдаемого поведения расчётов представляются тонкости округления чисел. Т.к. в начальном распределении величины задано нулевое значение, то на первых шагах счёт производится практически на границе машинной точности. Соответственно, это приводит к накоплению заметных погрешностей, которые и проявляются в конечном результате.
- Потери точности в алгоритме вызываются, очевидно, и тем фактом, что решается размерная система семи дифференциальных уравнений в частных производных, переменные в каждом из которых имеют собственные характерные значения, существенно отличающиеся от остальных. При правильном выборе масштабных множителей, в безразмерной системе уравнений получить близкие хотя бы по порядку величины значения всех переменных, хотя при первоначальных попытках провести обезразмеривание в системе возникали малые коэффициенты перед производными, что и стало поводом для отказа от данной процедуры.
- Вопрос же о том, почему gfortran, не соответствующий стандарту вычислений с плавающей точкой, способен выдавать приемлемый результат, остаётся открытым. Разумно предполагать наличие каких-то собственных, отличных от стандарта, правил округления, которые и обеспечивают сохранение стабильного счёта, а также их корректировку и уточнение в процессе развития компилятора. «Хрупкий баланс ошибок» либо продуманное исправление подхода? Увы, на моём уровне знаний об инструментарии, нацеленном в первую очередь именно на применение компиляторов, а не их тестирование и изучение свойств, это неизвестно. Но заставляет задуматься и вспомнить предостережения о возможных потерях точности в тех или иных местах программ, данные ещё на первых этапах обучения численным методам в вузе.
Тестирование компиляторов на соответствие IEEE 754 проводилось с помощью FORTRAN-версии «Floating point paranoia» Уильяма Кэхэна.
25.01.2012 21:03+0400
Ни о чём →
Тест Си компиляторов под Windows
После многочисленных споров на тему «Какой компилятор лучше генерирует код», появилась идея провести самому испытания. Основной целью испытания была проверка скорости работы программы с оптимизацией по скорости. Результат тестирования: среднее арифметическое время выполнения тестовой функции в миллисекундах (1/1000 сек). т.е. чем меньше тем лучше.
В тестировании участвовали:
MS Windows XP SP3 Eng x32 на ноутбуке и на компьютере (с одного диска устанавливались и один и тот же SP3 ставился).
Варианты компиляции:
Intel C++ Compiler Pro 11.1.054
График скорости выполнения кода относительно лидера теста (лидер теста — 100%)
Итоги:
По результатам тестирования на оптимизацию по скорости, компиляторы занимают следующие места:
В тоже время С++ Builder показал себя не с лучшей стороны (отставание в 2 раза), что свидетельствует о чуть другой специфики его применения.
Ну а про Tiny C Compiler 0.9.25 и речи не может быть, потому что он вообще не поддерживает оптимизацию переходов, вот и выходит, что скорость выполнения программы находится на уровне с другими компиляторами без оптимизации при компиляции.
Конечно С++ Builder оказался чуть староват потому что не нашел я у себя более свежей версии. Хотя мне кажется, там мало что изменилось в этом плане.
Заключение
По результатам тестирования нельзя судить о компиляторе, что он хорош или плох, потому что каждому своё применение, а можно лишь говорить о том, какой их них подойдет для создания программных продуктов связанных с вычислительными операциями.
В тестировании участвовали:
- Intel C++ Compiler Pro 11.1.054;
- GCC 4.5.0 (MinGW);
- MS C/C++ Compiler 15.00.21022.08 (VS 2008);
- CodeGear C++ Builder 11.0 (C++Builder 2007);
- Tiny C Compiler 0.9.25.
- Компьютер: CPU Intel E5200 (2-ядерный) 2.5 Ггц + 2 Гб ОЗУ;
- Ноутбук: CPU AMD Athlon QL-62 (2-ядерный) 2 Ггц + 3 Гб ОЗУ.
MS Windows XP SP3 Eng x32 на ноутбуке и на компьютере (с одного диска устанавливались и один и тот же SP3 ставился).
Варианты компиляции:
- Отключена любая оптимизация;
- Включена вся возможная оптимизация.
- Исходный код тестовой программы не изменяется в зависимости от компилятора;
- Тестовая функция не использует функции системы, т.е. только вычислительные операции, все функции связанные с вызовом системных функций вызываются до и после замера времени;
- Не используются библиотеки распараллеливания типа OpenMP;
- Вычисления производятся только в одном потоке;
- Компьютер не загружен больше никакими другими программами, только запущенная Windows + Notepad + тестовая программа;
- Для тестов не использовалась VCL, MFC, CLR, ATL;
- Код программ компилировался именно как С код, а не С++;
- Для Tiny C Compiler использовался только 1 вариант компиляции, потому что он не поддерживает оптимизацию на уровне кода. Из документации:
Оптимизация кода ограничена вычислением константных выражений на этапе компиляции, заменой операций умножения и деления операциями сдвига где это возможно, а также некоторыми другими действиями. Оптимизация переходов не производится, так как это потребовало бы организацию промежуточного кода в более абстрактном виде.
- Выделение памяти для буферов;
- Получение UserTime текущего потока через GetThreadTimes;
- Выполнение тестовой функции;
- Получение UserTime текущего потока через GetThreadTimes;
- Получение разницы во времени с точностью до миллисекунд (1/1000 сек);
- Повторение последних 4-х действий 10 раз;
- Вычисление среднего арифметического значения времени.
- Инициализация ключевой последовательности для алгоритма шифрования RC4;
- Инициализация ключевой последовательности для алгоритма шифрования AES-128;
- Заполнение первого тестового буфера данными полученными из генератора RC4;
- Вычисление CRC32 для первого тестового буфера;
- Шифрование первого тестового буфера алгоритмом AES-128, блоками по 128 бит, с помещением результата во второй тестовый буфер;
- Заполнение первого тестового буфера данными полученными из генератора RC4, т.е. первоначальные данные затираются полностью;
- Расшифровка второго тестового буфера с помещением результата в первый тестовый буфер;
- Подсчет CRC32 для расшифрованного первого тестового буфера;
- Сравнение CRC до шифрование и после.
- Кол-во данных для шифрования — 1600 килобайт (102400 блоков);
- Кол-во тестовых итераций для вычисления среднего арифметического значения времени — 10.
Intel C++ Compiler Pro 11.1.054
- Ноутбук без оптимизации: 6301 мс;
- Ноутбук с оптимизацией: 971 мс;
- Компьютер без оптимизации: 4541 мс;
- Компьютер с оптимизацией: 867 мс.
- Ноутбук без оптимизации: 6568 мс;
- Ноутбук с оптимизацией: 1691 мс;
- Компьютер без оптимизации: 4979 мс;
- Компьютер с оптимизацией: 1521 мс.
- Ноутбук без оптимизации: 5149 мс;
- Ноутбук с оптимизацией: 1574 мс;
- Компьютер без оптимизации: 3740 мс;
- Компьютер с оптимизацией: 1290 мс.
- Ноутбук без оптимизации: 4982 мс;
- Ноутбук с оптимизацией: 3854 мс;
- Компьютер без оптимизации: 4006 мс;
- Компьютер с оптимизацией: 3185 мс.
- Ноутбук: 6275 мс;
- Компьютер: 4606 мс.
График скорости выполнения кода относительно лидера теста (лидер теста — 100%)Итоги:
По результатам тестирования на оптимизацию по скорости, компиляторы занимают следующие места:
- Intel C++ Compiler Pro 11.1.054;
- MS C/C++ Compiler 15.00.21022.08 (VS 2008);
- GCC 4.5.0 (MinGW);
- CodeGear C++ Builder 11.0 (C++Builder 2007);
- Tiny C Compiler 0.9.25.
В тоже время С++ Builder показал себя не с лучшей стороны (отставание в 2 раза), что свидетельствует о чуть другой специфики его применения.
Ну а про Tiny C Compiler 0.9.25 и речи не может быть, потому что он вообще не поддерживает оптимизацию переходов, вот и выходит, что скорость выполнения программы находится на уровне с другими компиляторами без оптимизации при компиляции.
Конечно С++ Builder оказался чуть староват потому что не нашел я у себя более свежей версии. Хотя мне кажется, там мало что изменилось в этом плане.
Заключение
По результатам тестирования нельзя судить о компиляторе, что он хорош или плох, потому что каждому своё применение, а можно лишь говорить о том, какой их них подойдет для создания программных продуктов связанных с вычислительными операциями.
07.11.2010 14:18+0300