В чем разница между Слэй против Карлика против Сеха?

147

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

Я делаю свой собственный тест с компиляторами MSVC и GCC. Позже получается несколько более быстрых двоичных файлов (для каждой субархитектуры). Хотя время компиляции намного больше, чем MSVC.

Поэтому я решил использовать MinGW. Но не могу найти объяснения методам обработки исключений и их реализации в MinGW. Я могу использовать разные дистрибутивы для разных операционных систем и архитектур.

Соображения:

Время компиляции и память не важны для моего использования. Единственная важная вещь - оптимизация времени выполнения. Мне нужно, чтобы мои программы были достаточно быстрыми. Медленный компилятор приемлем.
ОС: Microsoft Windows XP / 7/8 / Linux
Архитектура: Intel Core i7 / Core2 / и очень старый i686 под управлением XP: P

— Sorūsh-р
источник

Я удивлен, что gcc создает более быстрый код, чем MSVC; Должно быть, все изменилось за последние несколько лет ...

— trojanfoe

@trojanfoe Мне много раз говорили использовать MSVC вместо MinGW. Все думают, что msvc быстрее! Я протестировал MinGW 7.2 и MSVC 2010. с помощью простой программы cpu-burst. На Corei7 с -O3 -mtune=corei7GCC на 45% быстрее, чем MSVC

— sorush-r

По моему собственному опыту, с генератором шахматных ходов (который использовал битборды) MSVC и Intel C ++ были на 10% быстрее, чем gcc, но это было 2 года назад ...

— trojanfoe

@Wolf В то время 45% быстрее означало 45% меньше времени для выполнения для меня. Если я правильно помню, время выполнения нашего программного обеспечения для моделирования молекулярной геометрии составляло 134 с (гкц) и 194 с (мсвк) для конкретного теста. Тем не менее, теперь я считаю мой метод измерения неправильным и недостаточным (:

— sorush-r

@ sorush-r Я вижу, вы рассчитали (194-134) / 134, что составляет около 45%, спасибо.

— Вольф

Ответы:

109

Краткий обзор на вики MinGW-w64 :

Почему mingw-w64 gcc не поддерживает обработку исключений Dwarf-2?

Реализация Dwarf-2 EH для Windows вообще не предназначена для работы под 64-битными приложениями Windows. В режиме win32 обработчик отмены исключения не может распространяться через код, не поддерживающий dw2, это означает, что любое исключение, проходящее через любой код «чужих кадров», не поддерживающий dw2, завершится сбоем, включая системные DLL-библиотеки Windows и библиотеки DLL, созданные с помощью Visual Studio. Код раскрутки Dwarf-2 в gcc проверяет сборку раскрутки x86 и не может продолжить работу без другой информации раскрутки dwarf-2.

SetJump LongJump метод обработки исключений работ в большинстве случаев на обоих win32 и Win64, для общих сбоев защиты , за исключением. Поддержка структурированной обработки исключений в gcc разрабатывается для преодоления недостатков dw2 и sjlj. На win64 информация о раскрутке помещается в секцию xdata, и вместо стека есть .pdata (таблица дескрипторов функций). Для win32 цепочка обработчиков находится в стеке и должна быть сохранена / восстановлена с помощью реального выполненного кода.

GCC GNU об обработке исключений :

GCC поддерживает два метода обработки исключений (EH):

DWARF-2 (DW2) EH , который требует использования отладочной информации DWARF-2 (или DWARF-3). DW-2 EH может привести к тому, что исполняемые файлы будут слегка раздутыми, потому что большие таблицы раскрутки стека вызовов должны быть включены в th исполняемых файлов.

Метод, основанный на setjmp / longjmp (SJLJ) . Основанный на SJLJ EH намного медленнее, чем DW2 EH (штрафует даже на нормальное выполнение, когда не выдается никаких исключений), но может работать с кодом, который не был скомпилирован с GCC или у которого нет информации о разворачивании стека вызовов.

[...]

Структурированная обработка исключений (SEH)

В Windows используется собственный механизм обработки исключений, известный как структурированная обработка исключений (SEH). [...] К сожалению, GCC пока не поддерживает SEH. [...]

Смотрите также:

— Ollo
источник

Спасибо за ссылки. Я собираюсь использовать DW2 для 32 бит и SEH для 64. SEH доступен в mingwbuilds (4.8). Стоит ли ждать стабильного релиза 4.8 или все нормально? Это компилируется здесь. В настоящее время я делаю зависимости моего проекта, используя 4.8 с SEH. Проблем пока нет ...

— соруш-р

Все зависимости (включая библиотеку Boost, OpenSSL, ICU, freeGLUT) скомпилированы, но Qt заканчивается множеством внутренних ошибок компилятора. Думаю дождусь стабильного релиза 4.8

— sorush-r

Вы использовали бинарные файлы qt или собирали самостоятельно?

@woreos Я использую свою собственную сборку Qt. Я обнаружил, что не было никаких проблем ни с Qt, ни с GCC 4.8. Это была моя полусгоревшая оперативная память! +1 Теперь все отлично работает

— соруш-р

SJLJ (setjmp / longjmp): - доступно для 32-битных и 64-битных - не «без затрат»: даже если исключение не генерируется, оно подвергается незначительному снижению производительности (~ 15% в коде с большим количеством исключений) - допускает исключения пройти через, например, обратные вызовы Windows

DWARF (DW2, dwarf-2) - доступен только для 32-разрядных систем - без постоянных накладных расходов во время выполнения - требуется, чтобы весь стек вызовов был включен с поддержкой dwarf, что означает, что исключения не могут быть выброшены, например, системные библиотеки Windows.

SEH (исключение нулевых издержек) - будет доступно для 64-битного GCC 4.8.

источник: http://qt-project.org/wiki/MinGW-64-bit

Извините, ссылка на источник добавлена.

Спасибо за ваш ответ;)

— sorush-r

Так что теперь, в 2016 году, мы можем поставить этот вопрос на отдых и просто всегда использовать SEH.

— rustyx

@RustyX Только если ваша цель x86_64

— sohnryang

Так гном для х86?

— Бангуру