How to become an author
Search
Write a publication
Pull to refresh

Comments 38

> То есть: просто включение поддержки исключений привело и к увеличению объёма конечного бинарного файла

Существенная деталь: в вашем трансляторе (суть которого — костыль для процессоров, разработчики которых не любят своих пользователей). В большинстве современных трансляторов используются zero-cost exceptions.

Проблема с исключениями для embedded и real-time в том, что очень сложно реализовать throw так, чтобы для вызова соответствующего catch была оценка времени сверху.
Total votes 11: ↑11 and ↓0+11
>zero-cost exceptions.
А можно показать это на псевдо-коде? Очень же интересно.

>костыль для процессоров, разработчики которых не любят своих пользователей
Я бы не стал заносить Intel и TI в эту категорию.
Total votes 5: ↑4 and ↓1+3
> А можно показать это на псевдо-коде? Очень же интересно.
На основе таблиц. Погуглите, до меня хорошо расписано в сотнях источников.

> Я бы не стал заносить Intel и TI в эту категорию.
Qualcomm для Hexagon пилят backend (open source!) для llvm. Автоматически получают все самые свежие возможности C++. Они любят своих пользователей.
Total votes 3: ↑3 and ↓0+3
>>На основе таблиц. Погуглите, до меня хорошо расписано в сотнях источников.
Гуглится, к примеру это: llvm.org/docs/ExceptionHandling.html. Но все же лучше пример псевдокода
This comment wasn’t rated yet0
Вот это ещё хорошо: llvm.org/demo/index.cgi
Можно скармливать куски кода и смотреть во что он их компилирует.
Total votes 1: ↑1 and ↓0+1
Прикол в том, что некоторые вещи сложно показать на псевдокоде. Вообще, это странная постановка вопроса: компилятор преобразует код С++ в байты, грубо говоря ассемблер. При этом непонятно, при чем тут С? Не каждый код может быть легко и непринужденно лечь на код С. Это иллюзия, что С++ со своими конструкциями сводится к С.

Я ожидал в статье увидеть разбор того, как генерируются исключения на современенных компляторах и платформах, когда происходит zero overhead, генерируются таблицы и по ним и колстеку происходит раскрутка. Например, компилятор msvc x64 добавляет nop операции и использует это при генерации исключений. Ничего подобного, что описано в этой статье, к данному случаю не имеет. Таким образом статья получилась как сферический конь в вакууме. Автору стоит внимательней изучить матчасть современных компиляторов.
Total votes 6: ↑6 and ↓0+6
Жаль, что статья показалась общей. Она больше относится к ситуации в своей узкой сфере.
This comment wasn’t rated yet0
Ну я бы не сказал, что она была общей. Она была вообще про другое: как старый преобразователь поганит код C++ при переходе к C. Ничего общего к проблеме исключений это не имеет. И взяв этот преобразователь говорить о нечто общем — это несколько странно. Тут скорее взят некий очень частный случай, не имеющий с реальной жизнью ничего общего.
Total votes 2: ↑2 and ↓0+2
«При этом непонятно, при чем тут С? Не каждый код может быть легко и непринужденно лечь на код С. Это иллюзия, что С++ со своими конструкциями сводится к С.»

Это распространенная практика — использовать Си в качестве portable-асемблера в разного рода трансляторах. В Си можно транслировать даже Scheme, со всеми приколами вроде обязательной оптимизации хвостовой рекурсии и call-cc.
Total votes 1: ↑0 and ↓1-1
Речь не про то, что можно или нельзя. Конечно можно. Вопрос в том, стоит ли на основании этой трансляции делать выводы о производительности. На мой взгляд ответ — нет. Более того, это даже неправильно, т.к. на производительность могут влиять многие достаточно тонкие эффекты и вещи.
Total votes 1: ↑1 and ↓0+1
То, как садится производительность (примерно на порядок иногда) заметно на тестах. А вот почему именно — и описывалось в статье.
Total votes 1: ↑0 and ↓1-1
Была статья по Java:
habrahabr.ru/blogs/java/133452/
в которой выявлен «порог»: если исключения выбрасываются реже 1:1000, то оверхеда по производительности нет.

Вопрос — что лучше: компенсировать оверхед исключений апгрейдом железа, или усложнить разработку неиспользованием исключений.
Total votes 2: ↑1 and ↓10
> если исключения выбрасываются реже 1:1000, то оверхеда по производительности нет.

При условии правильной реализации исключений в трансляторе.
Total votes 3: ↑3 and ↓0+3
Если выбор есть, то конечно лучше железо апгрейдить. Проблема в том, что не всегда этот выбор существует.
Total votes 1: ↑1 and ↓0+1
Для не embedded систем всё намного лучше. В случае, когда исключение не выбрасывается, код на исключениях оказался быстрее кода на return values (правда совсем чуть-чуть быстрее). Выбрасывание исключения, само собой, вещь жутко медленная, но мы же их выбрасываем только в исключительных случаях, правда?
Total votes 2: ↑2 and ↓0+2
Полезные данные, плохая статья. Нет ответа на самый главный вопрос — почему?! Я вообще был бы очень рад узнать, почему выходит быстрее.
This comment wasn’t rated yet0
Нет оверхеда на проверку возвращаемого результата.
Total votes 2: ↑2 and ↓0+2
Я правильно понимаю, что в таком случае исключение — банально longjump?
This comment wasn’t rated yet0
setjump/longjump (SJLJ) — это медленный способ реализации исключений.

В zero-cost способе в случае исключения у нас будет поиск нужного обработчика по таблицам и это может быть не быстро. Но для установки обработчика не нужно производить сложных действий. Поэтому если исключения нет — то мы за обработчики не платим.
Total votes 2: ↑2 and ↓0+2
UFO just landed and posted this here
Возвращаем коды успеха.
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
Хочется заметить о неиспользовании исключений в Google и LLVM:
http://llvm.org/docs/CodingStandards.html#ci_rtti_exceptions


Мотивы первого — совместимость с существующим кодом без исключений. Мотивы второго — размер кода и философия.
This comment wasn’t rated yet0
Хотелось бы понять, как переход от C++ к C связан с быстродействием генерируемого кода с использованием современных компиляторов? Большинство компиляторов просто заменяют виртуальный вызов на невиртуальный, т.к. инстанс известен во время компиляции.
Total votes 1: ↑1 and ↓0+1
Интересно, какие это компиляторы так делают. Я бы не хотел, чтобы вызов был невиртуальным, т.к. весь смысл виртуальных функций пропадает. И если тип переменной struct AAAAA*, то это не значит, что надо вызывать AAAAA::process(). Переменная может указывать на struct BBBBB*.
Total votes 3: ↑0 and ↓3-3
Возьмем, например, кусок кода:

BBBBB b1;
b1.process();

В момент вызова метода process компилятор однозначно понимает, какую функцию нужно позвать. Почему бы не использовать это знание? Более того, компилятор msvc так и делает. Я тут не вижу проблем.
Total votes 2: ↑2 and ↓0+2
Это все отлично в теории, но меня всегда радовали люди, которые о производительности рассуждают на уровне «ну вот здесь будет замедление». Во сколько раз? В каких ситуациях? В каком соотношении нормальное исполнение — брошенное исключение?

Я не говорю, что Вы неправы. Просто то, что написано в статье должно идти последней главой под названием «Разберемся, почему так» в большом 5-ти главном исследовании.

Поймите, что производительность — это чистая наука. Сделал — померил, еще сделал — еще померил, сравнил, выбрал.
Total votes 1: ↑1 and ↓0+1
Автор же написал — речь идёт о встраиваемых системах. Т.е. всякого рода контроллеров. Там узкие места нужно заранее в уме держать, чтобы через месяц разработки не оказалось, что система просто не успевает. И измерить производительность там тоже нетривиальное дело. Работа идёт больше частью с железом и система получается недетерминированной. Измерять, как привило, приходится косвенными методами.
Total votes 2: ↑1 and ↓10
Речь идёт не о встраиваемой с системе, а о костыльном трансляторе и этим всё сказано.
Total votes 2: ↑2 and ↓0+2
Речь идёт именно встраиваемых системах. Для десктопа это всё вообще слабо-акутально и сплошная переоптимизация. И нужно быть специфичным человеком, чтобы применять на десктопе подобные инструменты.
А для встраиваемых систем вполне нормально. Архитектор много и писать полноценный набор компиляторов долго и сложно. Часто производители пишут/заказывают компилятор C и к нему вот такие костыли.
Total votes 2: ↑1 and ↓10
Как-то погрустнело от кода с исключениями. И это код, не делающий ничего полезного. Если бы я писал под МК на С++, то мой проект, переделанный на С с исключениями, занял бы 2 MБайта и влезал бы наверное в притирку.
P.S. Напишите исходный размер, а то непонятно во сколько раз увеличение происходит.
Total votes 2: ↑0 and ↓2-2
Прошу выделить итоговые выводы подзаголовком «Вывод»
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Your account

Sections

Information

Services

Support
© 2006–2024, Habr