AS>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга. Установка фрейма исключений в цикле — довольно дорогая операция, значительно дороже, чем проверка ошибки (особенно с учетом работающего механизма предсказания переходов).
на вскидку — установка фрейма пара команд, ну мб три. снятие еще пара. и БЕЗ переходов. а вот проверка та же пара, но с переходом да и установка еще одна (в самой ф-ии). (это на I86). Итого 4(5) против 3.
я уже написал "проделана большая работа". т.е. измерялось только как определяется какие деструкторы надо вызвать — какие нет.
Поэтому обычно и стараются вынести это за пределы цикла — тогда, если код _только_ вычислительный, или же "толстая" прослойка до финальной функции (где проверка и генерация исключения) получится выигрыш. В общем, нужно нечто вроде fctest — где есть реальные паттерны работы дисковой подсистемы, поэтому и результаты реальны. А так — все это сферический конь в вакууме.
AS>>>Если же, наоборот, задача исключительно вычислительная — тогда конечно, исключения могут и выигрывать. В общем, все зависит от типа задачи, а такие тесты — средняя температура по больнице, которая ни о чем не говорит, на мой взгляд.
ть и оценить результат.
AS>Не все так просто. Даже замеры времени по rdtsc — это неправильно (если уж придираться), поскольку учитывает не время потока, а все такты процессора. В случае многозадачной системы это как минимум неверно. Выложи исходники — я тебя уверяю, народ раскритикует по самые
согласен
---
С уважением,
Сергей Мухин
Re[3]: [Investigation] Exceptions vs. Return Values
R>>>Ну вот собственно всё, что хотелось сказать. Коменты и замечания преведствуются Особенно интересно было бы услышать, если я пропустил какие-то важные аспекты в исследовании, которые могут сущуственно сказаться на производительности/размере кода/или ещё чём-то в разрезе исключения/возвращаемые значения.
MS>>В gcc для оптимизации jmp можно использовать макросы likely/unlikely. MS>>А для msvc эти макросы можно сделать пустышками.
СМ>и какое это имеет отношение к subj?
Я выделил отношение.
Я не проверял количественное влияние этих макросов, но ядерщики linux советуют использовать их использовать.
Если используются rv, то ветку (условие) обрабатывающую ошибку можно считать unlikely.
Например ошибку выделения памяти можно считать маловероятной
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, remark, Вы писали:
R>>>>
Exceptions vs. Return Values
V>>>Интересно бы было ещё узнать статистику для retv в стиле Win32 SetLastError/GetLastError, имхо тоже было бы полезно.
R>>Это уже просто надстройка над возвращаемыми значениями. В успешном случае производительность будет равна производительности с возвращаемыми значениями, а когда происходят ошибки, то добавляется небольшое пенальти на вызов функций SetLastError/GetLastError, но оно, конечно, не сравнимо с киданием исключений. Т.ч. я думаю, тут ничего принципиально не изменится.
V>Я имею ввиду ещё и использование TLS
TLS очень быстро — одно косвенное обращение — несколько тактов. С исключениями ни в какое сравнение всё равно не идёт.
R>>
Здравствуйте, MShura, Вы писали:
R>>>>Ну вот собственно всё, что хотелось сказать. Коменты и замечания преведствуются Особенно интересно было бы услышать, если я пропустил какие-то важные аспекты в исследовании, которые могут сущуственно сказаться на производительности/размере кода/или ещё чём-то в разрезе исключения/возвращаемые значения.
MS>>>В gcc для оптимизации jmp можно использовать макросы likely/unlikely. MS>>>А для msvc эти макросы можно сделать пустышками.
СМ>>и какое это имеет отношение к subj?
MS>Я выделил отношение.
Естественно, я запускал код не один раз. Я запускал код минимум тысячу раз и брал _минимальное_. Т.е. это время с учётом прогрева всех кэшей и бранч-предиктора. Т.ч. я не думаю, что это как-то повлияет на результат.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>>SEH для С++ с ядром не имеет ничего общего. Это всего лишь цепочка блоков. Вряд ли исключения изменились, возможно оптимизировали деструктор или вызовы его уменьшили. или FPO оптимизацию подняли.
R>>Тут я возможно ступил, у меня почему-то подсознательно SEH ассоциировался с ядром — надо будет ещё продебажить... хотя вроде я там видел переход в ядро... ладно ещё уточню...
СМ>вот хорошая стаья про SEH здесь
Здравствуйте, Сергей Мухин, Вы писали:
СМ>на вскидку — установка фрейма пара команд, ну мб три. снятие еще пара. и БЕЗ переходов. а вот проверка та же пара, но с переходом да и установка еще одна (в самой ф-ии). (это на I86). Итого 4(5) против 3.
Насколько я лазил по коду, генерируемому ICC, почти везде где можно он использует cmov
так что с переходами тут тоже не все ясно...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: [Investigation] Exceptions vs. Return Values
Здравствуйте, Andrew S, Вы писали:
AS>Даже замеры времени по rdtsc — это неправильно (если уж придираться), поскольку учитывает не время потока, а все такты процессора.
Увы, но более точного метода измерения кроме как
AS>Вот тут надо осторожнее в смысле организации цикла. Оптимизирующий компилятор вполне способен вынести установку фрейма исключений в "пустых" функциях за пределы цикла
Непонятно — в "пустых" функциях не устанавливается фрейм исключений...
AS>(тогда как для "нормальных" функций и тем более функций апи он этого делать не имеет права) — соответственно, такие тесты покажут фикцию. Как я понимаю, ты называешь эту ситуацию "ресурсы" (вообще, надо бы использовать нормальную терминологию — например, стек фрейм локальных переменных), тогда как на самом деле это вполне обычные локальные переменные — т.е. требование наличия своего стек фрейма, что скорее правило, а не исключение.
Нет, под "ресурсами" я подразумеваю не просто локальные переменные, а локальные переменные с нетривиальным деструктором, если в терминах с++ или локальную переменную, для которой надо вызвать destructor() перед выходом из функции, если в терминах с.
Просто локальные переменные в данном контексте имхо не интересны, т.к. всё влияние будет заключаться в одной инструкции увеличении указателя стека, причём и в С и в С++.
AS>В общем, надо моделировать _реальный_ код, а не пустые функции. А для этого надо иметь статистику по виду и функциональности AS>функций. У тебя таковая есть?
Такая задача не ставилась, т.к. это будет очень серьёзное исследование. И имхо оно здесь не надо, т.к. я исследовал примитивы, вычислительную сложность можно просто сложить для получения результата.
AS>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга. AS> AS>Не был бы так однозначен. По крайней мере кол-во инструкций и время выполнения связаны не линейно.
Тем более я, как инженер, больше верю своим глазам
AS>Установка фрейма исключений в цикле — довольно дорогая операция, значительно дороже, чем проверка ошибки
Почему? Там не более 2-3 инструкций.
AS>(особенно с учетом работающего механизма предсказания переходов). Поэтому обычно и стараются вынести это за пределы цикла — тогда, если код _только_ вычислительный, или же "толстая" прослойка до финальной функции (где проверка и генерация исключения) получится выигрыш.
Может быть ты приведёшь какие-то замеры Мои замеры пока показывают обратную картину....
AS>В общем, нужно нечто вроде fctest — где есть реальные паттерны работы дисковой подсистемы, поэтому и результаты реальны. А так — все это сферический конь в вакууме.
Я всё же пока не вижу такой необходимости.
AS>>>Если же, наоборот, задача исключительно вычислительная — тогда конечно, исключения могут и выигрывать. В общем, все зависит от типа задачи, а такие тесты — средняя температура по больнице, которая ни о чем не говорит, на мой взгляд.
R>>Естественно всё зависит от задачи. Но я то исследовал не задачи, а примитивы. Вычислительную сложность которых можно просто складывать и оценить результат.
AS>Не все так просто. Даже замеры времени по rdtsc — это неправильно (если уж придираться), поскольку учитывает не время потока, а все такты процессора. В случае многозадачной системы это как минимум неверно.
Не было никакой "многозадачной системы" и время я брал минимальное за много выполнений.
Это время не менялось от запуска к запуску. Имхо ты говоришь что-то не то...
AS>Выложи исходники — я тебя уверяю, народ раскритикует по самые
Код чего интересует?
Сами тестируемые функции? Или что?
AS>В общем, для начала неплохо бы тебе разобраться в механизме функционирования всего этого на самом низком уровне
AS>(тем более, даже для разных компиляторов он отличается — например, 6, 7.1 и 8 имеют разные механизмы раскрутки фрейма исключений),
AS>а потом уже, вооружившись знаниями о том, что и как делает компилятор (а также и ОС), писать паттерны поведения.
AS>Тогда бы действительно получилось интересное исследование на тему.
AS>>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга. Установка фрейма исключений в цикле — довольно дорогая операция, значительно дороже, чем проверка ошибки (особенно с учетом работающего механизма предсказания переходов).
СМ>на вскидку — установка фрейма пара команд, ну мб три. снятие еще пара. и БЕЗ переходов. а вот проверка та же пара, но с переходом да и установка еще одна (в самой ф-ии). (это на I86). Итого 4(5) против 3.
Установка фрейма. Вот типичный вариант (часть команд создания стек фрейма я включил сознательно, об этом ниже):
1. Команды работы с памятью (за исключением одной)
2. Размеры команд
3. Префиксы (поскольку используется FS)
4. Ведет к ebp-based стек фрейму. Т.е. минус один регистр. Как это важно на х86 — думаю, объяснять не надо.
Это все тянет тактов на 20-30 минимум (а на деле будет прилично больше). Про раскрутку мы не говорим — там кода в разы больше (в случае вин32), начиная от отработки исключения с переходом в KM и обратно, до собственно функции раскрутки, сначала самой ОС и потом уже stdlib. В общем, все не так тривиально, как тут пытаются показать — вплоть до влияния на производительность _самой_ функции, а не только окружения, которое ее вызывает.
Собственно, сама реализация всего этого в том же VC вызывает кучу вопросов — например, зачем было вообще пользоваться средствами OS для реализации software-only исключений.
AS>>Вот тут надо осторожнее в смысле организации цикла. Оптимизирующий компилятор вполне способен вынести установку фрейма исключений в "пустых" функциях за пределы цикла
R>Непонятно — в "пустых" функциях не устанавливается фрейм исключений...
Ну и зачем это тогда тестировать?
AS>>(тогда как для "нормальных" функций и тем более функций апи он этого делать не имеет права) — соответственно, такие тесты покажут фикцию. Как я понимаю, ты называешь эту ситуацию "ресурсы" (вообще, надо бы использовать нормальную терминологию — например, стек фрейм локальных переменных), тогда как на самом деле это вполне обычные локальные переменные — т.е. требование наличия своего стек фрейма, что скорее правило, а не исключение.
AS>>В общем, надо моделировать _реальный_ код, а не пустые функции. А для этого надо иметь статистику по виду и функциональности AS>функций. У тебя таковая есть?
R>Такая задача не ставилась, т.к. это будет очень серьёзное исследование. И имхо оно здесь не надо, т.к. я исследовал примитивы, вычислительную сложность можно просто сложить для получения результата.
Понятно. Дальше можно не продолжать.
AS>>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга. AS>> AS>>Не был бы так однозначен. По крайней мере кол-во инструкций и время выполнения связаны не линейно. R>Тем более я, как инженер, больше верю своим глазам
Для предположения — достаточно. Чтобы зря не истекать слюной, например, по поводу пустых функций, а также понимать, почему как и где изменяется размер кода, а не делать эмпирические выводы.
AS>>Установка фрейма исключений в цикле — довольно дорогая операция, значительно дороже, чем проверка ошибки
R>Почему? Там не более 2-3 инструкций.
Наивно... Ты посмотри, _какие_ там инструкции.
AS>>(особенно с учетом работающего механизма предсказания переходов). Поэтому обычно и стараются вынести это за пределы цикла — тогда, если код _только_ вычислительный, или же "толстая" прослойка до финальной функции (где проверка и генерация исключения) получится выигрыш.
R>Может быть ты приведёшь какие-то замеры Мои замеры пока показывают обратную картину....
Зачем? Замеры зависят от конкретной задачи. Нужно приводить не "какие-то" замеры, как сделал ты, а замеры на конкретных паттернах, взятых _статистическ_ с реальных задач — например, вызов апи базы данных, вычислительная задача, работа с графикой etc.
AS>>Не все так просто. Даже замеры времени по rdtsc — это неправильно (если уж придираться), поскольку учитывает не время потока, а все такты процессора. В случае многозадачной системы это как минимум неверно.
R>Не было никакой "многозадачной системы" и время я брал минимальное за много выполнений. R>Это время не менялось от запуска к запуску. Имхо ты говоришь что-то не то...
Понятно. Ну, что ж, могу лишь сказать, что это по меньшей мере неверно. Надо привязывать поток к одному ядру и устанавливать приоритеты на реалтайм — тогда хоть как то можно говорить о нормальном измерении при помощи этой методики.
AS>>Выложи исходники — я тебя уверяю, народ раскритикует по самые
R>Код чего интересует? R>Сами тестируемые функции? Или что?
Здравствуйте, Andrew S, Вы писали:
AS>>>Вот тут надо осторожнее в смысле организации цикла. Оптимизирующий компилятор вполне способен вынести установку фрейма исключений в "пустых" функциях за пределы цикла
R>>Непонятно — в "пустых" функциях не устанавливается фрейм исключений...
AS>Ну и зачем это тогда тестировать?
Что бы определить скорость работы различных методов сообщения об ошибках. Фрейм исключений — это только часть.
Не понимаю, что тебе не понятно? Вот гляди пример, на коотором можно сравнивать, при этом фреймов исключений нет:
void f_ex(int i)
{
ex2(i+1);
ex3(i+2);
ex4(i+3);
}
int f_rv(int i)
{
if (!f_rv2(i+1)) return 0;
if (!f_rv3(i+2)) return 0;
if (!f_rv4(i+3)) return 0;
return 1;
}
AS>>>(тогда как для "нормальных" функций и тем более функций апи он этого делать не имеет права) — соответственно, такие тесты покажут фикцию. Как я понимаю, ты называешь эту ситуацию "ресурсы" (вообще, надо бы использовать нормальную терминологию — например, стек фрейм локальных переменных), тогда как на самом деле это вполне обычные локальные переменные — т.е. требование наличия своего стек фрейма, что скорее правило, а не исключение.
AS>>>В общем, надо моделировать _реальный_ код, а не пустые функции. А для этого надо иметь статистику по виду и функциональности AS>функций. У тебя таковая есть?
R>>Такая задача не ставилась, т.к. это будет очень серьёзное исследование. И имхо оно здесь не надо, т.к. я исследовал примитивы, вычислительную сложность можно просто сложить для получения результата.
AS> Понятно. Дальше можно не продолжать.
AS>>>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга. AS>>> AS>>>Не был бы так однозначен. По крайней мере кол-во инструкций и время выполнения связаны не линейно. R>>Тем более я, как инженер, больше верю своим глазам
AS>Для предположения — достаточно. Чтобы зря не истекать слюной, например, по поводу пустых функций, а также понимать, почему как и где изменяется размер кода, а не делать эмпирические выводы.
AS>>>Установка фрейма исключений в цикле — довольно дорогая операция, значительно дороже, чем проверка ошибки
R>>Почему? Там не более 2-3 инструкций.
AS>Наивно... Ты посмотри, _какие_ там инструкции.
AS>>>(особенно с учетом работающего механизма предсказания переходов). Поэтому обычно и стараются вынести это за пределы цикла — тогда, если код _только_ вычислительный, или же "толстая" прослойка до финальной функции (где проверка и генерация исключения) получится выигрыш.
R>>Может быть ты приведёшь какие-то замеры Мои замеры пока показывают обратную картину....
AS>Зачем? Замеры зависят от конкретной задачи. Нужно приводить не "какие-то" замеры, как сделал ты, а замеры на конкретных паттернах, взятых _статистическ_ с реальных задач — например, вызов апи базы данных, вычислительная задача, работа с графикой etc.
AS>>>Не все так просто. Даже замеры времени по rdtsc — это неправильно (если уж придираться), поскольку учитывает не время потока, а все такты процессора. В случае многозадачной системы это как минимум неверно.
R>>Не было никакой "многозадачной системы" и время я брал минимальное за много выполнений. R>>Это время не менялось от запуска к запуску. Имхо ты говоришь что-то не то...
AS>Понятно. Ну, что ж, могу лишь сказать, что это по меньшей мере неверно. Надо привязывать поток к одному ядру и устанавливать приоритеты на реалтайм — тогда хоть как то можно говорить о нормальном измерении при помощи этой методики.
Зачем привязывать к единственному ядру? Или ты боишься, что у меня часть вычислений убежало на соседний комп?
Зачем поднимать приоритеты? Или ты думаешь, что поток с более высоким приоритетом будет выполняться быстрее?
AS>>>Выложи исходники — я тебя уверяю, народ раскритикует по самые
R>>Код чего интересует? R>>Сами тестируемые функции? Или что?
AS>Все — полный тест юнит.
Я не понимаю твой поинт имхо уже наполовину переходящий в наезды. Ты хочешь сказать, что либо я выдумал цифры, либо неправильно мерял?
AS>>>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга. Установка фрейма исключений в цикле — довольно дорогая операция, значительно дороже, чем проверка ошибки (особенно с учетом работающего механизма предсказания переходов).
СМ>>на вскидку — установка фрейма пара команд, ну мб три. снятие еще пара. и БЕЗ переходов. а вот проверка та же пара, но с переходом да и установка еще одна (в самой ф-ии). (это на I86). Итого 4(5) против 3.
AS>Установка фрейма. Вот типичный вариант (часть команд создания стек фрейма я включил сознательно, об этом ниже):
AS>
Здравствуйте, Andrew S, Вы писали:
AS>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга.
ИМХО, совсем недостаточно. Ты точно знаешь какие команды могут процом паралельно выполнятся и как они влияют друг на друга?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[7]: [Investigation] Exceptions vs. Return Values
AS>>Ну и зачем это тогда тестировать?
R>Что бы определить скорость работы различных методов сообщения об ошибках. Фрейм исключений — это только часть. R>Не понимаю, что тебе не понятно? Вот гляди пример, на коотором можно сравнивать, при этом фреймов исключений нет:
R>
Ну и где тут реальный код? С трансляцией исключений в собственнные и т.п.? Я не вижу поинта для сравенения, уж извини. Ведь проверка ошибок для этого и используется — чтобы на основе возвращаемого значения сформировать свое. В реальной ситуации с исключениями часто ровно та же задача — у нас есть набор наших исключений и нам надо "чужие" исключения привести к нашим.
AS>>Понятно. Ну, что ж, могу лишь сказать, что это по меньшей мере неверно. Надо привязывать поток к одному ядру и устанавливать приоритеты на реалтайм — тогда хоть как то можно говорить о нормальном измерении при помощи этой методики.
R>Зачем привязывать к единственному ядру? Или ты боишься, что у меня часть вычислений убежало на соседний комп?
Куда убежать??? Вероятно, про багу с рассинхронизаций rdtsc на разных ядрах ты не слышал?
R>Зачем поднимать приоритеты? Или ты думаешь, что поток с более высоким приоритетом будет выполняться быстрее?
Круто.
AS>>>>Выложи исходники — я тебя уверяю, народ раскритикует по самые
R>>>Код чего интересует? R>>>Сами тестируемые функции? Или что?
AS>>Все — полный тест юнит.
R>Я не понимаю твой поинт имхо уже наполовину переходящий в наезды. Ты хочешь сказать, что либо я выдумал цифры, либо неправильно мерял?
Это не наезд, а критический анализ. То, что тебе он не нравится — уже означает его претензии на валидность Так чего тебе бояться — я не понимаю причин для того, чтобы не выложить полный проект. Если жалко трудов — так и скажи. Но только по результатам судить о тесте — уж извини. Это действительно инженерный подход, который для исследований не годится.
AS>>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга. AJD>ИМХО, совсем недостаточно. Ты точно знаешь какие команды могут процом паралельно выполнятся и как они влияют друг на друга?
Достаточно для оценки ситуации и выводов о необходимости замеров. Мерить все подряд не понимая, что собственно измеряешь — смысл?
AS>>Даже замеры времени по rdtsc — это неправильно (если уж придираться), поскольку учитывает не время потока, а все такты процессора. CC>Увы, но более точного метода измерения кроме как CC>
Здравствуйте, Andrew S, Вы писали:
AS>Достаточно для оценки ситуации и выводов о необходимости замеров.
Если код отличается на несколко инстукций, тяжело что-то сказать прое его скорость в общем случае.
AS>Мерить все подряд не понимая, что собственно измеряешь — смысл?
Это да.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re: [Investigation] Exceptions vs. Return Values
От:
Аноним
Дата:
02.04.07 09:05
Оценка:
То, что исключения позволяют сократить один if при вызове функции, по-моему, с лихвой компенсируется тем, что исключения вынуждают пользоваться обертками в виде умных указателей.
Re[7]: [Investigation] Exceptions vs. Return Values
AS>>Достаточно для оценки ситуации и выводов о необходимости замеров. AJD>Если код отличается на несколко инстукций, тяжело что-то сказать прое его скорость в общем случае.
В данном случае разница довольно существенна. К тому же я не призываю отказаться от измерений — а лишь понимать, что именно измеряется. А не просто анализировать статистику.
Здравствуйте, Andrew S, Вы писали:
AS>И еще не забывай про привязку к одному ядру. А вот что автор тестов ответил на все это — можешь прочитать сам
Да, совсем забыл:
SetProcessAffinityMask (GetCurrentProcess (),1);
// и для гарантии контрольный в голову!!!
SetThreadAffinityMask (GetCurrentThread (),1);
Понятно. Дальше можно не продолжать.
Круто.
