Цифровой код, портирующий powerpc к Intel, дает различные результаты с помощью плавания
Моя существенная проблема состоит в том, как заставить арифметику с плаваниями на x86 вести себя как PowerPC, идущий из Классической MacOS (CodeWarrior) к Windows (VS 2008).
Рассматриваемый код, которого существует много, имеет груду алгоритмов, которые очень итеративны и численно очень чувствительны.
Типичная сложная строка:
Ims_sd = sqrt((4.0*Ams*sqr(nz)-8.0*(Ams+Dms)*nz+12.0*sqr(Ams)) /
(4.0*sqr(Ams)*(sqr(nz)-1)) -
sqr(Ims_av))*sqrt(nz-1);
Это записано с помощью typedef'd float как базовый тип.
Изменение на double получает очень похожие результаты на обеих платформах, но к сожалению числа не приемлемы, таким образом, мы не можем вынуть тот простой способ.
Код Mac компилируется с помощью CodeWarrior, и просто выключение поколения инструкций FMADD & FMSUB имело решительный эффект на созданные числа. Так, моя начальная точка должна была искать опции Visual Studio (2008), которые казались самыми подобными - сплавленная проверка добавляет, использовался. Мы подозреваем, что ключ находится в поведении компилятора в выделении промежуточного устройства хранения данных в вычислениях
В настоящее время лучшие результаты получаются с комбинацией включения SSE2 и /fp:fast. Включение встроенных функций заставляет значения дрейфовать далее от значений Mac.
В документации переключателя/fp говорится это только /fp:strict выключает сплавленный, добавляет поведение.
MSDN говорит о соединении FP10. Объект "перед LIBC.LIB, LIBCMT.LIB или MSVCRT.LIB". гарантировать точность на 64 бита. Я, по-видимому, достиг этого путем определения FP10. Объект на поле ввода компоновщика (подробный компоновщик произвел, показывает его до MSVCRTD.lib).
Я также установил точность на 64 бита путем вызова
_controlfp_s(&control_word, _PC_64, MCW_PC);
в DllMain.
Обратите внимание, что проблема не происходит из-за различий в обработке исключения в операции с плавающей запятой между платформами, ни происходит из-за (восхитительного) способа, которым PowerPC позволяет целые числа деления на нуль (просто возвращающий нуль), поскольку эти области уже контролировались и обращены, спасибо чрезвычайно к Линту ПК. Прогоны программы и производят несколько вероятный вывод, просто не совсем достаточно хороший.
ОБНОВЛЕНИЕ:
Интересный комментарий от друга: Одна возможность состоит в том, что PPC имеет большое количество временных регистров, которые могут сохранить промежуточные значения на 64 бита, тогда как x86-коду, вероятно, придется разгрузить и перезагрузить FPU (усекающий к 4 байтам и теряющий точность).
Это может быть то, почему SSE2 работает лучше (IIRC), он имеет больше регистров и больше объема для сохранения промежуточных значений.
Одна возможность - Ваш код может быть скомпилирован как 64 бита? x64 режим также имеет больше регистров для промежуточных звеньев и лучших инструкций FP, таким образом, это может быть ближе к PPC в дизайне и выполнении.
Начальное тестирование с 64-разрядной сборкой на самом деле стало ближе, поскольку он предположил, что оно могло бы (я сначала думал, что оно промахнулось, но это происходило из-за неправильной установки моделирования).
Заключительное разрешение
Я уверен, что любой заинтересовал этой темой, является достаточно маниакальным, они хотели бы знать, как все это удалось в конце. Программное обеспечение закончено и поставка последовательных числовых результатов. Мы так и не смогли заставить все алгоритмы обеспечивать идентичные результаты Mac, но они были достаточно близки, чтобы быть статистически приемлемыми. Учитывая, что обработка ведется опытным пользователем, выбирающим сферы интересов, и тот ввод данных пользователем является частично реактивным к тому, как модель прогрессирует, руководитель исследовательских работ считал это приемлемым (это не было ночным решением!). Остающиеся числовые различия хорошо в границах того, что определяет различные клинические результаты, таким образом, никакие различные диагнозы не были замечены с тестированием.
2 ответа
Весь вопрос о детерминировании чисел с плавающей запятой на нескольких платформах кажется очень сложным, и чем больше вы вникаете в него, тем хуже становится.
Я нашел эту интересную статью , в которой проблема обсуждается очень глубоко - возможно, в ней появятся некоторые идеи.
Вам нужен профилировщик. Я знаю, что NetBeans включает в себя достойный .
Вы также можете посмотреть на этот вопрос: Java Profilers с открытым исходным кодом .
Похоже, что JDK 1,6 поставляется с базовым профилировщиком. Так что, возможно, вы хотите попробовать сначала. Он должен быть включен в StartVM, поставляемый с вашим jdk6: визуальным профилировщиком
-121--3894441-No. Alt Text отображается как альтернатива для изображения, если его невозможно отобразить.
Вот выписка из спецификации, которая является довольно прямой:
- Не указывайте неактуальный альтернативный текст при включении изображений, предназначенных
для форматирования страницы, например,
alt = «красный мяч» будет неуместным для изображения, которое добавляет красный шар для оформление заголовка или абзаца. В такие случаи, альтернативный текст должен быть пустой последовательностью («»). Авторами являются в любом случае рекомендуется избегать использования
изображения для форматирования страниц; таблицы стилей
вместо этого следует использовать.- Не указывайте бессмысленный альтернативный текст (например, "фиктивный текст "). Это не только будет расстраивать пользователей, это замедлится агенты пользователей, которые должны преобразовать текст на вывод речи или шрифта Брайля. игра терминалы, пользователи, браузеры которых не поддерживать формы, визуально пользователи с ограниченными возможностями, те, кто использует синтезаторы речи, те, кто настроил своего графического пользователя
агенты не отображать изображения и т.д.
Так что это говорит довольно ясно не повторять. «Красный мяч» в первом случае может быть заменен на «Джордж Вашингтон».
Вот хорошая статья, как правильно использовать alt-атрибут: Alt attributes
EDIT : Хорошо, я думаю, меня неправильно поняли. Я не говорил, что он не должен использовать альт-атрибут здесь.
Мы говорим о программах чтения с экрана и доступности, верно? Я согласен, что изображение важно для нас . Но это слепым людям? Или это просто украшение для текста?
Помните, что вопрос был в том, следует ли повторить имя в атрибуте alt. И я говорю «Нет.» Если изображения не отображаются, отображается alt-текст. Я бы выгодно сделать это так путь:
<p><img src="george.jpg" alt="Image of " />George Washington</p>
alt-Attribute является альтернативой, если изображение не показано , а не описание (у нас есть описание для этого).
Не ответ как таковой, а больше текста (и форматирования), чем я мог бы вписать в комментарий. Читая ваш вопрос, мне кажется, что вы, вероятно, рассмотрели все это, но не сказали нам, так что все это может быть неуместной болтовней. Если да, то прошу прощения.
Можете ли вы (вы?) обеспечить соблюдение IEEE754 правил арифметики с плавающей запятой в исходной или портированной версиях программы? Мое первое предположение состоит в том, что две платформы (сочетание аппаратного обеспечения, o/s, библиотек) реализуют различные подходы к fp арифметике.
Какие предположения (если таковые имеются) вы сделали относительно размеров по умолчанию на двух платформах,некоторых фундаментальных типов, таких как ints и floats. Стандарт C (и я считаю, что стандарт C++) допускает платформенную зависимость для некоторых таких (не могу с верхней части головы вспомнить, какой, я действительно программист Fortran).
Последнее предположение - Я стал использовать (в моем мире Фортранни) для указания плавающих констант, таких как ваш 4.0 с достаточным количеством цифр, чтобы указать все (десятичные) цифры в предпочтительном представлении, то есть что-то вроде 4.000000000000000000000000. Я знаю, что в Фортране 4-байтовая плавающая константа, такая как 3,14159625, при автоматическом приведении к 8-байтам не заполняет дополнительные байты дополнительными цифрами в десятичном выражении pi. Это может повлиять на тебя.
Ничто из этого не помогает вам гарантировать, что портированная версия вашего кода приведет к тому же, до бита, результатам, что и исходная версия, только определить источники различий.
Наконец, является ли ваше требование о том, чтобы новая версия давала те же результаты, что и старая, или чтобы вы гарантировали своим клиентам, что новая версия дает точные ответы? Ваш вопрос оставляет открытой возможность того, что старая версия программы была «неправильнее», чем новая, с учетом всех источников ошибок в численных вычислениях.