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

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

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

ОБНОВЛЕНИЕ 1

Командная строка реального просмотра:

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

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


arm embedded realview
person binW    schedule 22.04.2011    source источник
comment
Какова цель? Какие версии RealView и Code Sourcery задействованы? Есть ли у вас какая-либо информация о профилировании конкретной области, которая, по-видимому, имеет большую разницу в производительности ›   -  person Michael Burr    schedule 22.04.2011
comment
@Micaheel-Burr: целью является процессор iMX31, то есть 1136JF-S. Realview Tools версии 4.1 и GCC версии 4.4.1. Информация о профилировании конкретной области отсутствует.   -  person binW    schedule 25.04.2011
comment
Вы используете плавающую точку? И если да, то правильно ли вы настроили параметры компилятора для использования оборудования с плавающей запятой. Также, если вы используете sqrt(), возможно, что библиотека использует программную конвергенцию, а не аппаратную инструкцию SQRT. Вам нужно правильно настроить параметры компилятора/компоновщика, чтобы избежать этого. Например, см. это: keil.com/support/docs/3293.htm . Вам нужно как минимум опубликовать параметры, которые вы используете для каждого компилятора, и, если возможно, какой-нибудь пример кода, демонстрирующий различную производительность.   -  person Clifford    schedule 25.04.2011
comment
@Clifford: я не использую аппаратное обеспечение FPU, поэтому все операции с плавающей запятой являются программными, основанными на обеих сборках, то есть GNU и Realview.   -  person binW    schedule 25.04.2011
comment
@binW: Интересный выбор для цели с FPU! VFP может обеспечить 5-кратное ускорение операций FP без векторизации и 10-кратное, если ваш компилятор выполняет векторизацию или использует библиотеку, оптимизированную для векторизации.   -  person Clifford    schedule 25.04.2011
comment
Вы уверены, что компилятор действительно использовал s/w FP в обоих случаях? то есть вы проверили сгенерированный код на ассемблере? Если выбрана эмуляция VFP, а не вызовы библиотеки FP; столкнувшись с реальным VFP, он будет использовать его, а не программное обеспечение, потому что исключение недопустимого кода операции, которое запускает эмуляцию, не произойдет. Как я уже сказал, нам нужно знать параметры компилятора/компоновщика, которые вы применяете в каждом случае. Добавьте эту информацию к своему вопросу, и вы можете начать получать ответы, а не комментарии.   -  person Clifford    schedule 25.04.2011
comment
@Clifford: я добавил командные строки для обоих компиляторов.   -  person binW    schedule 25.04.2011
comment
@Micheal Burr запросил версии компилятора, чтобы помочь вам, а не из праздного любопытства. Вы могли бы помочь себе, не игнорируя такие просьбы.   -  person Clifford    schedule 25.04.2011
comment
@Clifford: я упомянул версии компилятора в своем комментарии после комментария Микаэля-Берра.   -  person binW    schedule 25.04.2011
comment
@binw: Да, моя ошибка. Но такая важная диагностическая информация заслуживает того, чтобы быть в вопросе, а не в комментарии.   -  person Clifford    schedule 26.04.2011

Ответы (5)


arrow_upward
4
arrow_downward

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

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

person Clifford    schedule 22.04.2011

arrow_upward
3
arrow_downward

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

person scott douglass    schedule 30.10.2012

arrow_upward
2
arrow_downward

В текущей версии 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.

person Clifford    schedule 25.04.2011
comment
Как я уже упоминал выше, я использую RVDS версии 4.1, которая, как мне кажется, является последней. - person binW; 25.04.2011
comment
Хорошо, тогда это, вероятно, ошибка в спецификации процессора, которая вызывает проблему, поскольку вы сказали компилятору RV, что у вас нет оборудования с плавающей запятой, но разрешили GCC использовать h/w fp. - person Clifford; 26.04.2011

arrow_upward
1
arrow_downward

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

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

person old_timer    schedule 24.04.2011
comment
Я не предполагаю, что у меня будет такая же производительность. Предполагается, что я должен получить лучшую производительность с компилятором Realview, чем с GNU, потому что этот компилятор производится самой ARM. - person binW; 25.04.2011
comment
У меня больше нет доступа к инструментам руки, когда я это сделал, инструменты руки производили гораздо более компактный и быстрый код, чем gcc. Значительно лучше. С тех пор gcc стал лучше, но ненамного, и gcc 4 не обязательно лучше gcc 3 по производительности. Поэтому с осторожностью я бы сказал, что да, вы должны ожидать лучшего кода от инструментов руки. Вы должны убедиться, что вы экспериментируете с параметрами компилятора. Используя отладчик с отлаживаемым кодом, вы, вероятно, не используете все преимущества оптимизатора. Использование отладчика только для загрузки и запуска — это совсем другая история. - person old_timer; 25.04.2011

arrow_upward
0
arrow_downward

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

person Judge Maygarden    schedule 22.04.2011