почему мой код работает плохо при сборке с помощью инструментов Realview, но лучше с Codesourcery?

Question

У меня есть проект C, который ранее создавался с помощью цепочки инструментов Codesourcery gnu. Недавно он был преобразован для использования компилятора Realview armcc, но производительность, которую мы получаем с помощью инструментов Realview, очень низкая по сравнению с тем, когда он компилируется с помощью инструментов GNU. Разве это не должен быть противоположный случай, т.е. он должен давать лучшую производительность при компиляции с инструментами Realview? Что мне здесь не хватает. Как я могу улучшить производительность с помощью инструментов Realview?

Также я заметил, что если я запускаю двоичный файл, созданный Realview Tools, с помощью Lauterbach, он падает, но если я запускаю его с помощью Realview ICE, он работает нормально.

ОБНОВЛЕНИЕ 1

Realview Командная строка:

armcc -c --diag_style = ide --depend_format = unix_escaped --no_depend_system_headers --no_unaligned_access --c99 --arm_only --debug --gnu --cpu = ARM1136J-S --fpu = SoftVFP --apcs = / nointerwork -O3 -Время

Командная строка GNU GCC:

arm-none-eabi-gcc -mcpu = arm1136jf-s -mlittle-endian -msoft-float -O3 -Wall

Я использую Realview Tools версии 4.1 и GCC версии 4.4.1

ОБНОВЛЕНИЕ 2

Проблема Лаутербаха решена. Это было вызвано из-за Semihosting, так как SWI-полухостинг не обрабатывался в среде Lauterbach. Перенацелив библиотеку C, чтобы избежать Semihosting, добился цели, и теперь моя программа успешно работает с Lauterbach и Realview ICE. Но проблема производительности в том, как она есть.

Answer 1

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

Я предлагаю вам попробовать обе цепочки инструментов без оптимизации, убедиться, что уровень предупреждения установлен на высоком уровне, и исправить их все. GCC намного лучше, чем armcc при проверке ошибок, поэтому это разумная проверка статического анализа. Если код строится чисто, он с большей вероятностью сработает, и оптимизатору будет легче его обрабатывать.

Answer 2

Вы пытались удалить '--no_unaligned_access'? ARM11, как правило, могут осуществлять доступ без выравнивания (если он включен в коде запуска), и принуждение компилятора / библиотеки не выполнять их может замедлять ваш код.

Answer 3

Текущая версия RVCT говорит о '--fpu = SoftVFP':

В предыдущих выпусках RVCT, если вы указали --fpu = softvfp и процессорс неявным оборудованием VFP, компоновщик выбрал библиотеку, которая реализовывала программные вызовы с плавающей точкой, используя инструкции VFP.Это больше не так.Если вам требуется это устаревшее поведение, используйте --fpu = softvfp + vfp.

Это наводит меня на мысль, что, если у вас, возможно, установлена ​​старая версия RVCT, поведение будет заключаться в использовании программной плавающей запятой независимо отналичие аппаратной плавающей запятой.В то время как в версии GNU -msoft-float будет использовать аппаратные инструкции с плавающей точкой, когда доступен FPU.

Итак, какую версию RVCT вы используете?

В любом случае я предлагаю вам удалить--fpu, поскольку компилятор сделает неявный соответствующий выбор на основе выбранной опции --cpu.Вам также необходимо исправить выбор процессора, ваш вариант RVCT говорит --cpu=ARM1136J-S, а не ARM1136FJ-S, как вы сказали GCC.Это, несомненно, помешает компилятору генерировать инструкции VFP, поскольку вы сказали, что у него нет VFP.

Answer 4

Один и тот же исходный код может создавать совершенно разные двоичные файлы из-за таких факторов, как. Различные компиляторы (llvm против gcc, gcc 4 против gcc3 и т. Д.). Разные версии одного и того же компилятора. Различные параметры компилятора, если один и тот же компилятор. Оптимизация (на любом компиляторе). Скомпилировано для выпуска или отладки (или каковы бы ни были термины, которые вы хотите использовать, двоичные файлы совершенно разные). При встраивании вы добавляете усложнение загрузчика или rom монитора (отладчика) и тому подобное. Затем добавьте к этому инструменты на стороне хоста, которые общаются с монитором или скомпилированы в отладчике. Несмотря на то, что компиляторы arm были намного лучше, чем gcc, они были заражены предположением, что двоичные файлы всегда будут запускаться поверх их монитора. Я хочу помнить, что к тому времени, когда rvct стал их основным компилятором, это предположение было на исходе, но с тех пор я действительно не использовал их инструменты.

Суть в том, что есть несколько основных факторов, которые могут повлиять на различия между двоичными файлами, которые могут и будут приводить к другому опыту. Предполагая, что вы получите ту же производительность или результаты, это плохое предположение, ожидаемо, что результаты будут отличаться. Аналогично, в одной и той же среде вы должны иметь возможность создавать двоичные файлы, которые дают резко отличающиеся результаты производительности. Все из того же исходного кода.

Answer 5

У вас включены оптимизации компилятора в вашей сборке CodeSourcery, но не в сборке Realview?