Здравствуйте, Andrew S, Вы писали:

AS>Куда убежать??? Вероятно, про багу с рассинхронизаций rdtsc на разных ядрах ты не слышал?
Кстати интел утверждает что "ссинхронизировать" tsc разных ядер можно путем вызова QueryPerormanceCounter.
Правда как именно они это делают я так и не понял. А трасить QueryPerormanceCounter уж очень неохота...
Хотя результаты моих тестов как на HT (P630) так и на дуалах (P915) расхождения в чистых rdtsc не выявили.
Впрочем лучше уж будем и дальше перестраховываться...

Здравствуйте, remark, Вы писали:

R>Зачем привязывать к единственному ядру?
Затем, что ОС по своей прихоти может перебросить поток на другое ядро. С учетом таких забавных современных заморочек как динамическое управление частотой проца у разных ядер может оказаться разная частота — соответственно разное значение tsc. Дошло?

R>Зачем поднимать приоритеты?
Затем, чтоб на данном ядре нашему потоку отдавалось как можно больше процессорного времени. Чтоб в замеры не вмешивалось время исполнения не нашего кода...

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

Здравствуйте, minorlogic, Вы писали:

M> ...

M>6. Очень интересен анал хотя бы под одну embeded платформу.

Для ARM-платформ все далеко не так радужно. Если привязываться к коду использующему исключения генерируемому gcc для ARM, то там имеют место быть так называемые stack unwind tables — для каждой функции генерируется такое безобразие. Размер кода увеличивается довольно серъезно. По своему опыту помню, как после перекомпиляции с ключом -fexceptions 300 килобайтная программа стала весить 450. Довольно серъезный недостаток для embedded devices.
Как обыкновение под embedded платформы используют два ключа компиляции: -fno-exceptions и -fno-rtti(правда поддержка rtti обходится сравнительно небольшим довеском к коду).
Причина по которой gcc генерирует столь медленный код для win32 думается связана с тем, что gcc использует общую схему обработки исключений, который в общих чертах независим от платформы. Win32 SEH не используется gcc.

Здравствуйте, remark

Вам не стыдно?
Вы не упоямянули какую модель обработки исключений использовали, синхронную или асинхронную. Вы же не будете утверждать что между ними нет никакой существенной разницы?
Не указана потоковоя модель ST\MT и способ линковки рантайма lib\dll
Какой класс исключения вы использовали? (Я надеюсь он был производным от std::runtime_error? или вы bool кидали? )
Как насчет полиморфного поведения?
Как насчет ловли ссылок на один из базовых классов в иерархии?
Как насчет ловли ссылок на один из производных классов в иерархии?

Двойка вам за научный подход.

R>

Здравствуйте, rm822, Вы писали:

R>Здравствуйте, remark

R>Вам не стыдно?
R>Вы не упоямянули какую модель обработки исключений использовали, синхронную или асинхронную. Вы же не будете утверждать что между ними нет никакой существенной разницы?

Возможно стыд мне и позор, но первый раз про такое слышу. Или слышал под другим названием.
Что за синхроннная/асинхронная модель?

R>Не указана потоковоя модель ST\MT и способ линковки рантайма lib\dll

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

R>Какой класс исключения вы использовали? (Я надеюсь он был производным от std::runtime_error? или вы bool кидали? )

int
Я думаю это тоже неважно, за исключением небольшого оверхеда при кидании.

R>Как насчет полиморфного поведения?

А что насчёт него?

R>Как насчет ловли ссылок на один из базовых классов в иерархии?

А что насчёт него?

R>Как насчет ловли ссылок на один из производных классов в иерархии?

А что насчёт него?


R>Двойка вам за научный подход.

R>>

Здравствуйте, Аноним, Вы писали:

А>То, что исключения позволяют сократить один if при вызове функции, по-моему, с лихвой компенсируется тем, что исключения вынуждают пользоваться обертками в виде умных указателей.

Умные указатели подпадают под категорию того, что я называл "ресурсами", т.е. объектами с нетривиальным деструктором. Никак это не компенсируется.

Здравствуйте, rm822, Вы писали:

R>Здравствуйте, remark

R>Вам не стыдно?
R>Вы не упоямянули какую модель обработки исключений использовали, синхронную или асинхронную. Вы же не будете утверждать что между ними нет никакой существенной разницы?

R>Не указана потоковоя модель ST\MT и способ линковки рантайма lib\dll

при чем здесь это?

R>Какой класс исключения вы использовали? (Я надеюсь он был производным от std::runtime_error? или вы bool кидали? )
R>Как насчет полиморфного поведения?
R>Как насчет ловли ссылок на один из базовых классов в иерархии?
R>Как насчет ловли ссылок на один из производных классов в иерархии?

R>Двойка вам за научный подход.

R>>

Здравствуйте, StevenIvanov, Вы писали:

SI>Здравствуйте, minorlogic, Вы писали:

M>> ...

M>>6. Очень интересен анал хотя бы под одну embeded платформу.

SI>Для ARM-платформ все далеко не так радужно. Если привязываться к коду использующему исключения генерируемому gcc для ARM, то там имеют место быть так называемые stack unwind tables — для каждой функции генерируется такое безобразие. Размер кода увеличивается довольно серъезно. По своему опыту помню, как после перекомпиляции с ключом -fexceptions 300 килобайтная программа стала весить 450. Довольно серъезный недостаток для embedded devices.

Это сравнение теплого и мягкого. Надо не просто перекомпилировать программу с исключениями или без. Т.к. сообщение об ошибках с помощью возвращаемых значений могут раздуть код до 3 раз. Сравни:

call f

и:

call f
test eax, eax
je ...

Вопрос: какая программа будет меньше, использующая исключения и скомпилированная с исключениями или неиспользующая исключения и скомпилированная без исключений.
А то, что программа написанная без исключений, но скомпилированная с исключениями будет больше программы написанной без исключений, и скомпилированной без исключениями — это понятно.

В дополнение к сказанному.
Этот сэкономленный if играет роль только когда тело функции пустое. Если функция хоть что-то делает, тем более в цикле, то такая экономия не играет никакой роли. Так что эксперимент поставлен абсолютно некорректно.

Олег Алексеев.

Здравствуйте, remark, Вы писали:

R>Здравствуйте, rm822, Вы писали:

R>>Здравствуйте, remark

R>>Вам не стыдно?
R>>Вы не упоямянули какую модель обработки исключений использовали, синхронную или асинхронную. Вы же не будете утверждать что между ними нет никакой существенной разницы?

R>Возможно стыд мне и позор, но первый раз про такое слышу. Или слышал под другим названием.
R>Что за синхроннная/асинхронная модель?

это vc specific:

/EHa
/EHsc

[]

Здравствуйте, Andrew S, Вы писали:

AS>>>>А вообще, и замерять то особо ничего не надо — достаточно анализа ассемблерного листинга. Установка фрейма исключений в цикле — довольно дорогая операция, значительно дороже, чем проверка ошибки (особенно с учетом работающего механизма предсказания переходов).

СМ>>>на вскидку — установка фрейма пара команд, ну мб три. снятие еще пара. и БЕЗ переходов. а вот проверка та же пара, но с переходом да и установка еще одна (в самой ф-ии). (это на I86). Итого 4(5) против 3.

AS>>Установка фрейма. Вот типичный вариант (часть команд создания стек фрейма я включил сознательно, об этом ниже):

AS>>

AS>>    mov    ebp, esp
AS>>    push    -1
AS>>    push    $callback
AS>>    mov    eax, DWORD PTR fs:__except_list
AS>>    push    eax
AS>>    mov    DWORD PTR fs:__except_list, esp
AS>>

AS>Да, совсем забыл — еще ж надо снять фрейм

AS>

AS>    mov    ecx, DWORD PTR __$EHRec$[ebp+4]
AS>    mov    DWORD PTR fs:__except_list, ecx
AS>    mov    esp, ebp
AS>

Что ты хочешь этим сказать? А ты погляди код, который генерируется при вызове функций, возвращающих значения. Там тоже есть код, там не по велению волшебной палочки всё происходит.
Ситуация такая: при использовании исключений у функции есть пролог/эпилог, зато само тело меньше, т.к. нет постоянных проверок.
при использовании возвращаемых значнеий — нет пролога/эпилога, зато каждый вызов функции/выделение ресурса обходится дороже.
Вот именно это я исследовал. Что же в итоге лучше. Что перевешивает. То, что есть пролог/эпилог — это понятно, понятно, что это всё не за бесплатно.

з.ы. кстати, если в функции нет объектов с нетривиальными деструкторами, то исключения выглядят значительно привлекательнее, т.к. и эпилога/пролога нет и вызовы функции дешевле.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Andrew S, Вы писали:

AS>>И еще не забывай про привязку к одному ядру. А вот что автор тестов ответил на все это — можешь прочитать сам
CC>Да, совсем забыл:
CC>

CC>    SetProcessAffinityMask (GetCurrentProcess (),1);
CC>    // и для гарантии контрольный в голову!!!
CC>    SetThreadAffinityMask (GetCurrentThread (),1);
CC>

О чём вы вообще говорите?! Ну не может код выполняться на разных процессорах/ядрах, если всего один процессор и одно ядро!
И не может так быть, что бы кусок кода, выполняемый 24 такта 1000 раз подряд, каждый из этих 1000 раз прерывался таймером.
Я не понимаю, о чём вы говорите.

Здравствуйте, Andrew S, Вы писали:

AS>Ну и где тут реальный код? С трансляцией исключений в собственнные и т.п.? Я не вижу поинта для сравенения, уж извини. Ведь проверка ошибок для этого и используется — чтобы на основе возвращаемого значения сформировать свое. В реальной ситуации с исключениями часто ровно та же задача — у нас есть набор наших исключений и нам надо "чужие" исключения привести к нашим.

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


AS>>>Понятно. Ну, что ж, могу лишь сказать, что это по меньшей мере неверно. Надо привязывать поток к одному ядру и устанавливать приоритеты на реалтайм — тогда хоть как то можно говорить о нормальном измерении при помощи этой методики.

R>>Зачем привязывать к единственному ядру? Или ты боишься, что у меня часть вычислений убежало на соседний комп?

AS>Куда убежать??? Вероятно, про багу с рассинхронизаций rdtsc на разных ядрах ты не слышал?

Нет, чтобы на одном ядре таймер сам с собой рассинхронизировался, я не слышал. А что такое бывает?


R>>Зачем поднимать приоритеты? Или ты думаешь, что поток с более высоким приоритетом будет выполняться быстрее?

AS> Круто.

Вот я тоже так подумал.

AS>>>>>Выложи исходники — я тебя уверяю, народ раскритикует по самые

R>>>>Код чего интересует?
R>>>>Сами тестируемые функции? Или что?

AS>>>Все — полный тест юнит.

R>>Я не понимаю твой поинт имхо уже наполовину переходящий в наезды. Ты хочешь сказать, что либо я выдумал цифры, либо неправильно мерял?
AS>Это не наезд, а критический анализ. То, что тебе он не нравится — уже означает его претензии на валидность Так чего тебе бояться — я не понимаю причин для того, чтобы не выложить полный проект. Если жалко трудов — так и скажи. Но только по результатам судить о тесте — уж извини. Это действительно инженерный подход, который для исследований не годится.

Мне не жалко трудов, просто проект получился достаточно наколеночный, т.к. когда я начинал, то не собирался делать что-то особо основательное. Но если ты так настаиваешь, сейчас всё это запакую и выложу.

Здравствуйте, remark, Вы писали:

R>Здравствуйте, rm822, Вы писали:

R>>Здравствуйте, remark

R>>Вам не стыдно?
R>>Вы не упоямянули какую модель обработки исключений использовали, синхронную или асинхронную. Вы же не будете утверждать что между ними нет никакой существенной разницы?

R>Возможно стыд мне и позор, но первый раз про такое слышу. Или слышал под другим названием.
R>Что за синхроннная/асинхронная модель?
http://msdn2.microsoft.com/en-us/library/1deeycx5.aspx

R>>Не указана потоковоя модель ST\MT и способ линковки рантайма lib\dll

R>Это никак не повлияет, поэтому и не указывал. Там нет вызовов из рантайма. Возможно за исключением кидания исключения, но там небольшой оверхед на синхронизацию никак не скажется.
Вы проверяли? Если нет то вы не знаете, это только догадки, а разработчики как известно не могут с достаточной достоверностью предсказывать узкие места.

R>>Какой класс исключения вы использовали? (Я надеюсь он был производным от std::runtime_error? или вы bool кидали? )

R>int

R>Я думаю это тоже неважно, за исключением небольшого оверхеда при кидании.
Вы думаете, но вы не знаете. Это важно. Дополнительный new\delete + вступают в силу заморочки с полиморфным поведением.
То что кто-то будет кидать Int крайне маловероятно, а здравый смысл требует гомоморфную иерархию классов исключений. std использует в качестве базы std::exception. Даже если вы хотите использовать какой-то свой класс как пращура, то все равно он должен быть наследником std::exception

R>>Как насчет полиморфного поведения?
R>А что насчёт него?
сколько займет вызов виртуального деструктора?

R>>Как насчет ловли ссылок на один из базовых классов в иерархии?
R>А что насчёт него?
try{
throw std::runtime_error("")
} catch(std::exception&) //сколько займет проверка того что std::runtime_error наследник std::exception?
{}

R>>Как насчет ловли ссылок на один из производных классов в иерархии?
R>А что насчёт него?
try{
throw std::exception("")
} catch(std::runtime_error&) //сколько займет проверка того что здесь catch не сработает?
{}


вполне реальная ситуация
try{
...
}
catch(SqlException& e) {....}
catch(IOException& e) {....}
catch(std::exception& e) { что-то не срослось }


R>>Двойка вам за научный подход.

R>>>

Здравствуйте, Аноним, Вы писали:

А>В дополнение к сказанному.
А>Этот сэкономленный if играет роль только когда тело функции пустое. Если функция хоть что-то делает, тем более в цикле, то такая экономия не играет никакой роли. Так что эксперимент поставлен абсолютно некорректно.

Ты сам себе противоречишь — вначале говоришь, что надо, что б функция что-то делала, а потом, говоришь, что тогда все результаты будут не видны.
Имхо я как раз всё сделал как надо — меряю вклад тогда, когда он виден. А не наоборот.

А>Олег Алексеев.

Здравствуйте, rm822, Вы писали:

[]

R>>>Какой класс исключения вы использовали? (Я надеюсь он был производным от std::runtime_error? или вы bool кидали? )

R>>int
R>
R>>Я думаю это тоже неважно, за исключением небольшого оверхеда при кидании.
R>Вы думаете, но вы не знаете. Это важно. Дополнительный new\delete + вступают в силу заморочки с полиморфным поведением.
R>То что кто-то будет кидать Int крайне маловероятно, а здравый смысл требует гомоморфную иерархию классов исключений. std использует в качестве базы std::exception. Даже если вы хотите использовать какой-то свой класс как пращура, то все равно он должен быть наследником std::exception

ничего он не должен. Это рекомендация

R>>>Как насчет полиморфного поведения?
R>>А что насчёт него?
R>сколько займет вызов виртуального деструктора?

кто кидает указатели? Нафиг это надо?

R>>>Как насчет ловли ссылок на один из базовых классов в иерархии?
R>>А что насчёт него?
R>try{
R> throw std::runtime_error("")
R>} catch(std::exception&) //сколько займет проверка того что std::runtime_error наследник std::exception?
R>{}

хз, думаю, недолго

R>>>Как насчет ловли ссылок на один из производных классов в иерархии?
R>>А что насчёт него?
R>try{
R> throw std::exception("")
R>} catch(std::runtime_error&) //сколько займет проверка того что здесь catch не сработает?
R>{}

the same

R>вполне реальная ситуация
R>try{
R> ...
R>}
R>catch(SqlException& e) {....}
R>catch(IOException& e) {....}
R>catch(std::exception& e) { что-то не срослось }


R>>>Двойка вам за научный подход.

R>>>>

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, remark, Вы писали:

R>>Здравствуйте, rm822, Вы писали:

R>>>Здравствуйте, remark

R>>>Вам не стыдно?
R>>>Вы не упоямянули какую модель обработки исключений использовали, синхронную или асинхронную. Вы же не будете утверждать что между ними нет никакой существенной разницы?

R>>Возможно стыд мне и позор, но первый раз про такое слышу. Или слышал под другим названием.
R>>Что за синхроннная/асинхронная модель?

КЛ>это vc specific:

КЛ>/EHa
КЛ>/EHsc

КЛ>[]

Аааа. Понял о чём речь.
Ну вы же видите результаты, когда исключение кидается — всякие вариации, типа синхронной/асинхронной модели или кидать int или runtime_error, версия рантайма — это уже как мёртвому припарка — кидание исключений СУЩЕСТВЕННО НА МНОГО более медленные. Я не думаю, что из-за настроек время станет вдруг не 20мкс, а 10нс.

Здравствуйте, remark, Вы писали:

R>О чём вы вообще говорите?! Ну не может код выполняться на разных процессорах/ядрах, если всего один процессор и одно ядро!У
У меня например 1 проц — 2 ядра... При особом желании могу нарыть как 2 процессорную так и четырехядерную машины... На них еще как может.
Речь тут о правильной методике тестирования. Разумеется если у тебя однояйцевый проц, то тогда тебе не надо париться касательно ядер. Но для правильного результата надо учитывать нюансы исполнения кода как на 1 так и на 2+ ядерниках.

R>И не может так быть, что бы кусок кода, выполняемый 24 такта 1000 раз подряд, каждый из этих 1000 раз прерывался таймером.
Колво циклов надо увеличить по любому — слишком мало — будет сказываться погрешность измерений.

R>
разумеется

Здравствуйте, rm822, Вы писали:

R>>>Двойка вам за научный подход.

Тут основная проблема, что бы сделать тесты справедливые для обоих стратегий.
Т.е. что я делаю — беру некую предельно простую абстракцию — ресурс — приписываю ему семантику — его надо выделить, причём выделение может провалится, и его обязательно надо освободить при выходе из функции. Далее я моделирую эту абстракцию на С++ и на С предельно "честно" по отношению к обоим языкам и их возможностям — на С++ — объект с деструктором, на С — функции construct/destroy. И сравниваю именно эти реализации одной и той же задачи разными средствами. Какая реализация быстрее?
Сравнивать тёплое с мягким нет смысла.
Т.е. нет смысла мерить типа "а что если мы в с++ вставим дополнительный new/delete" — ты тогда и в С вставь тоже что-то, что будет решать ту задачу, для решения которой ты в С++ вставил дополнительный new/delete.
Т.е. ты придумай некую абстрактную задачу, которая бы на С++ требовала применения иерархий ошибок/динамического полиморфизма и т.д., потом максимально "честно" вырази её решение на С, причём там, что бы тебе потом не говорили — а я бы это сделал подругому и быстрее. И вот тогда будем мерить, где решение задачи "мега динамической полиморфной обработки ошибок" работает быстрее.

Здравствуйте, remark, Вы писали:

R>Ты сам себе противоречишь — вначале говоришь, что надо, что б функция что-то делала, а потом, говоришь, что тогда все результаты будут не видны.
R>Имхо я как раз всё сделал как надо — меряю вклад тогда, когда он виден. А не наоборот.

Я хочу сказать, что практическая ценность этого измерения незначительна. Мы же на практике не пишем пустых функций.

Ещё я боюсь, что сейчас появится куча людей, утверждающих, что преимущество исключений доказано экспериментально, но забывающих указать в каких условиях оно проявляется. Между тем, написать exception-safe программу ох как непросто.

Олег Алексеев.