Возвращаемое значение C ++ в сравнении с производительностью исключения

Question

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

Это правда??Являются ли исключения быстрее, чем переменные, до возвращения состояния / ответа на состояние?переполнение стека чтения по теме, кажется, противоречит этому.

Спасибо

Answer 1

Имейте в виду, что в термине «обработчик исключений» есть неоднозначность.Я полагаю, вы обнаружите, что аппаратные люди, когда говорят об исключениях, означают такие вещи, как:

1. Аппаратные прерывания, или сигналы, чьи обработчики иногда называют обработчиками исключений (см. http://pages.cs.wisc.edu/~smoler/x86text/lect.notes/interrupts.html)
2. Исключения машинной проверки, которые останавливают компьютер, если что-то не работает в оборудовании (см. http://en.wikipedia.org/wiki/Machine_Check_Exception)

. Ни один из них не имеет ничего общего со средством обработки исключений в C ++.

В качестве контрпримераУ меня есть, по крайней мере, одна случайная точка данных, где исключения были намного медленнее, чем коды возврата: это было на аппаратном обеспечении Intel, но с gcc 2.95 и очень большим набором кода с очень большой таблицей исключений, которая была создана в первый раз, когдабыло сгенерировано исключение. Последующие исключения были быстрыми, но к тому времени ущерб обычно был нанесен. По общему признанию, gcc 2.95 довольно древний, но этого должно быть достаточно, чтобы предостеречь вас от обобщений относительно скорости обработки исключений в C ++, даже на оборудовании Intel.

Answer 2

Я не знаю, где вы это читаете, но это, безусловно, неправильно. Ни один аппаратный разработчик не допустит исключительных обстоятельств, которые по определению являются необычными, и работают быстрее, чем обычные. Также имейте в виду, что C, который согласно TIOBE является самым популярным системным языком, даже не поддерживает исключения. Крайне маловероятно, что процессоры оптимизированы для обработки исключений ОДНОГО языка, реализация которых даже не стандартизирована среди компиляторов.

Даже если исключения почему-то были быстрее, вы все равно не должны использовать их вне их предназначения, чтобы не запутать любого другого программиста в мире.

Answer 3

Нет.Нет ничего быстрее, чем вставить переменную в регистр.Даже при явной аппаратной поддержке исключения все еще будут требовать таких вещей, как доступ к памяти.

Исключения C ++ по большей части не могут быть реализованы таким образом, потому что c ++ требует, чтобы стек был размотан и объекты были разрушены.

Answer 4

Технически правильный ответ, но очень вводит в заблуждение.

В основе проблемы лежит наблюдение о том, что исключения являются исключительными. Их обычно не бывает. Это не тот случай, когда вы возвращаете код ошибки. Это происходит всегда, даже если ошибок нет. В этом случае функция по-прежнему должна возвращать 0, или true, или -1, или ...

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

Как только мы это поймем, мы сможем посмотреть, как компилятор и ЦП оптимизируют такие случаи. Одним из распространенных методов является помещение кода исключения отдельно от обычного кода. В результате этот код обычно не попадает в кэш ЦП, который может содержать более полезный код. Фактически, код исключения может вообще не оказаться в ОЗУ и остаться на диске.

Другим вспомогательным механизмом является предсказатель ветвления ЦП. Он будет помнить, что ветви, которые приводят к коду исключения, обычно не берутся, и поэтому предсказывают, что в следующий раз они также не будут приняты. Компилятор может даже вставить это как подсказку. Тем не менее, эта функция подсказки была оставлена ​​после Intel Pentium 4; современные процессоры достаточно хорошо предсказывают переходы.

Answer 5

Ваш вопрос немного неясен, потому что то, что вы подразумеваете под реализацией исключений, охватывает три вещи:

• Ввод блока try.Эта может иметь стоимость , но имеет тенденцию делать throw более дорогой.Есть более конкретный вопрос по этому поводу на SO .
• Выполнение throw.Существует более конкретный вопрос по этому поводу в SO .
• . Раскручиваем стек, чтобы перейти от throw к catch, и загружаем код обработки ошибок (в * 1023).*) в кеш процессора.Вы должны игнорировать эту стоимость, потому что вы должны оплатить ее, используя коды состояния, а не исключения.

Answer 6

Даже если они были быстрее, вы не должны использовать их ни для чего, кроме исключительных условий.Если вы их неправильно используете, вы значительно затрудняете отладку вашей программы.В gdb вы можете выполнить 'catch throw' и легко выяснить, где ваша программа работает неправильно и генерирует исключение, но не в том случае, если вы генерируете исключения как часть обычной обработки.