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

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

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

Либо я чего-то не понимаю...
То, что ты можешь нарыть 2 процессорную тачку никак не сказывается на том, будет ли у меня погрешность измерений, если я на одноядерной тачке не привяжу потоки к ядрам.
На одноядерной тачке не надо ничего привязывать. Я учёл все ньюансы, адекватные в конкретной ситуации. Если бы я запускал на многоядерной такчке, тогда бы я парился по поводу привязки и т.д.
Я не понимаю о чём речь. Почему Andrew S говорит, что я забыл сделать какую-то привязку, поднять приоритеты и т.д. Слов просто нет.
Не знаю даже, что вам ещё сказать. Или если вы тут о чём-то своём говорите, типа "как мы будем мерить производительность на многоядерной тачке", то то не говорите, что я что-то забыл.


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

Именно поэтому потом я делал замеры в "асимптотическом" случае.

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

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

[]

R>Я не понимаю о чём речь. Почему Andrew S говорит, что я забыл сделать какую-то привязку, поднять приоритеты и т.д. Слов просто нет.
R>Не знаю даже, что вам ещё сказать. Или если вы тут о чём-то своём говорите, типа "как мы будем мерить производительность на многоядерной тачке", то то не говорите, что я что-то забыл.

ну это он для надежности. Вдруг какой-либо другой поток вклинится в подсчитанные такты.

[]

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

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

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

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

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

конечно, поэтому давайте писать простые совсем не exception-safe программы .

Его поинт в том, что сама по себе поддержка исключений вносит практически нулевой оверхэд.

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

А>

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

Я хочу сказать, что там не 2-3 команды, а десяток довольно толстых как сточки зрения кода, так и данных, команд.

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

R>Вот именно это я исследовал. Что же в итоге лучше. Что перевешивает. То, что есть пролог/эпилог — это понятно, понятно, что это всё не за бесплатно.

Чушь. Твоя запись if (!fun()) return val как раз не общий случай. Его я могу оптимизировать до одной проверки на все функции. val1 = fun1() ... valn = funn(); return val1 | val2 | ... | valn. В принципе, это может сделать и сам компилятор (более того, он это хоть и коряво, на пытается при помощи setne сделать). И что это покажет? Я говорю — нужны реальные паттерны.

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

Не вышлядят. Блин, ну сколько можно — я ж уже показал, что в этом случае используется ebp стек фрейм. Попробуй лучше исследовать, как это влияет на перфоманс вычислительной функции, а?

Я к чему — пустые функции должны идти в dev\null. Использование исключений значительно влияет на кодогенерацию. Точка.

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

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

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

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

Реальность такова что для обработки исключений используется иерахия классов а не int.(Обычно) Для обработки ошибок error-кодами используется int а не классы. (Обычно) И сравнивать нужно именно теплое с мягким, потому что такова реальность.

R>

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

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

КЛ>[]

R>>Я не понимаю о чём речь. Почему Andrew S говорит, что я забыл сделать какую-то привязку, поднять приоритеты и т.д. Слов просто нет.
R>>Не знаю даже, что вам ещё сказать. Или если вы тут о чём-то своём говорите, типа "как мы будем мерить производительность на многоядерной тачке", то то не говорите, что я что-то забыл.

КЛ>ну это он для надежности. Вдруг какой-либо другой поток вклинится в подсчитанные такты.

Во-первых, thread affinity тут всё равно ни при чём
Во-вторых, от "вклинивания" на win32/linux всё равно никак не защититься

КЛ>[]

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

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

А я тебя уверяю в обратном. Сравни std и com исключения. Обычно в проекте своя иерархия исключений, и они транслируются на разных уровнях вызова. Как в этом случае добиться преймущества от исключений на уровне вызова библиотечных методов\функций — вопрос интересный.

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

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

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

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

А при чем тут один. Ты тестировал на одной конфигурации?

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

AS>> Круто.

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

Да. Сильно. А ты не подумал, что выбор минимального из результатов — это в корне неправильный подход к статистике?

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

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

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

КЛ>Его поинт в том, что сама по себе поддержка исключений вносит практически нулевой оверхэд.

Если бы более точным, то я хочу померить оверхед обработки ошибок отдельно Допустим получается 100нс/1000 строк кода при использовании кодов возврата и 95нс/1000 строк кода.
Дальше каждый сам волен решать — важно ему это или нет. Важно ли ему эти 5 нс.
Но утвержать, что это просто не важно, имхо, некорректно.

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

А>>

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

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

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

AS>А я тебя уверяю в обратном. Сравни std и com исключения. Обычно в проекте своя иерархия исключений, и они транслируются на разных уровнях вызова. Как в этом случае добиться преймущества от исключений на уровне вызова библиотечных методов\функций — вопрос интересный.

com исключения? это что?

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

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

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

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

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

R>Реальность такова что для обработки исключений используется иерахия классов а не int.(Обычно) Для обработки ошибок error-кодами используется int а не классы. (Обычно) И сравнивать нужно именно теплое с мягким, потому что такова реальность.

Обычно и не думают о наносекундах, и что?

R>>

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

КЛ>Его поинт в том, что сама по себе поддержка исключений вносит практически нулевой оверхэд.

В чём его поинт, автор уже написал:

>> Цель можно охарактеризовать примерно так: исследовать скорость работы некоторых ключевых паттернов кода, реализованных с применением исключений для сообщения об ошибках, или с помощью возвращаемых значений.

Написание пустых функций не есть "ключевой паттерн кода" (по-моему).

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

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

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

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

AS>Я хочу сказать, что там не 2-3 команды, а десяток довольно толстых как сточки зрения кода, так и данных, команд.

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

R>>Вот именно это я исследовал. Что же в итоге лучше. Что перевешивает. То, что есть пролог/эпилог — это понятно, понятно, что это всё не за бесплатно.

AS>Чушь. Твоя запись if (!fun()) return val как раз не общий случай. Его я могу оптимизировать до одной проверки на все функции. val1 = fun1() ... valn = funn(); return val1 | val2 | ... | valn. В принципе, это может сделать и сам компилятор (более того, он это хоть и коряво, на пытается при помощи setne сделать). И что это покажет? Я говорю — нужны реальные паттерны.

Это не оптимизация общего случая — пример — вложенные ресурсы.

Ну допустим, я бы потратил пол-года и переписал некий проект bla-bla с одной стратегии на другую и выдал бы в итоге, что с исключениями bla-bla стал работать на 1% быстрее и размер уменьшился на 2%. Ну и что? По-твоему это бы дало больше информации?
Мы же не штампуем целиком проекты, мы пишем отдельные функции — вот тут функци, которая форвардит вызов другой, а вот тут функция, которая вызывает ещё 3 функции, а вот тут функция, которая выделяет ресурс и т.д.


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

AS>Не вышлядят. Блин, ну сколько можно — я ж уже показал, что в этом случае используется ebp стек фрейм. Попробуй лучше исследовать, как это влияет на перфоманс вычислительной функции, а?

А я сколько раз показывал, что код работает на 50% быстрее и занимает на 200% меньше.

AS>Я к чему — пустые функции должны идти в dev\null. Использование исключений значительно влияет на кодогенерацию. Точка.

Так же как и возвращаемые значения. Очевидно. Осталось только понять как.

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

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

Не совсем так. Асинхронная можель обработки исключений в VC (название неудачное, но так уж назвали) означает, что исключение может кинуть любая функция, в том числе сишная. Плюс SEH-исключения будут ловиться по catch(..). Т.е., компилятор просто будет втыкать код для размотки стека в большем количестве случаев. Соответственно, повлияет это и на нормальное исполнение программы, когда исключения не кидаются.

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

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

AS>>А я тебя уверяю в обратном. Сравни std и com исключения. Обычно в проекте своя иерархия исключений, и они транслируются на разных уровнях вызова. Как в этом случае добиться преймущества от исключений на уровне вызова библиотечных методов\функций — вопрос интересный.

КЛ>com исключения? это что?

Например, COleException. В этом случае мы имеем дело аж с 2-мя враппингами — перевод возвращаемого значения в ole иключение, перевод ole исключения в наше родное. И это все вполне common случай. Я ж говорю — различные библиотечные методы\функции.

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

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

R>Реальность такова что для обработки исключений используется иерахия классов а не int.(Обычно) Для обработки ошибок error-кодами используется int а не классы. (Обычно) И сравнивать нужно именно теплое с мягким, потому что такова реальность.

Осталось еще добавить, что при обработке ошибок error-кодами (обычно) как минимум в половине случаев забывают проверять код возврата или не знают что с ним делать, и поэтому программа с обработкой ошибок error-кодами все равно будет быстрее Зато с исключениями — правильнее

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

AS>Да. Сильно. А ты не подумал, что выбор минимального из результатов — это в корне неправильный подход к статистике?

Статистика тут ни при чем. В подобныъ замерах скорости — интерес представляет только минимальное время выполнения.

AS>Да нет, я не настаиваю. Просто если ты хочешь называть это исследованием и чтобы его результаты имели практическую ценность и обоснованность — должен быть виден код, который приводит к таким результатам. Скажи честно, ты смотрел для каждого варианта то, что генерит компилятор на уровне ассемблера? Ты разбирался как каждый из них работает с исключениями и с возвращающими значениями и влияние этого на кодогенерацию в целом? А ведь это все нужно, чтобы не просто статистику поиметь, а сделать из нее выводы — самое ценное, что есть в исследовании. Я выводов пока (как и самого исследования) пока тут не вижу, уж извини.

То есть у вас есть лучшее тестирование , и вы его зажимаете и не выкладываете ?

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

AS>>Я хочу сказать, что там не 2-3 команды, а десяток довольно толстых как сточки зрения кода, так и данных, команд.

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

R>>>Вот именно это я исследовал. Что же в итоге лучше. Что перевешивает. То, что есть пролог/эпилог — это понятно, понятно, что это всё не за бесплатно.

AS>>Чушь. Твоя запись if (!fun()) return val как раз не общий случай. Его я могу оптимизировать до одной проверки на все функции. val1 = fun1() ... valn = funn(); return val1 | val2 | ... | valn. В принципе, это может сделать и сам компилятор (более того, он это хоть и коряво, на пытается при помощи setne сделать). И что это покажет? Я говорю — нужны реальные паттерны.

R>Это не оптимизация общего случая — пример — вложенные ресурсы.

Это оптимизация приведенного тобой примера, в которой переход не требуется вообще...

R>Ну допустим, я бы потратил пол-года и переписал некий проект bla-bla с одной стратегии на другую и выдал бы в итоге, что с исключениями bla-bla стал работать на 1% быстрее и размер уменьшился на 2%. Ну и что? По-твоему это бы дало больше информации?

Не проект. Надо выделить несколько функций различных классов, и уже на их основе анализировать эффект.

R>Мы же не штампуем целиком проекты, мы пишем отдельные функции — вот тут функци, которая форвардит вызов другой, а вот тут функция, которая вызывает ещё 3 функции, а вот тут функция, которая выделяет ресурс и т.д.

Пустые функции — это не то. Ну сколько можно, право. Даже уже занятие ebp уменьшает вычислительный потенциал на несколько процентов.

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

AS>>Не вышлядят. Блин, ну сколько можно — я ж уже показал, что в этом случае используется ebp стек фрейм. Попробуй лучше исследовать, как это влияет на перфоманс вычислительной функции, а?

R>А я сколько раз показывал, что код работает на 50% быстрее и занимает на 200% меньше.

Только ты показывал это на фикции — на пустых функциях. Которые к тому же можно оптимизировать в случае возвращаемых значений.

AS>>Я к чему — пустые функции должны идти в dev\null. Использование исключений значительно влияет на кодогенерацию. Точка.

R>Так же как и возвращаемые значения. Очевидно. Осталось только понять как.

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

AS>>Да. Сильно. А ты не подумал, что выбор минимального из результатов — это в корне неправильный подход к статистике?

M>Статистика тут ни при чем. В подобныъ замерах скорости — интерес представляет только минимальное время выполнения.

Ух ты. Т.е. в реальной жизни пользователь запускает программу и всегда попадает на минимум? Везет...

AS>>Да нет, я не настаиваю. Просто если ты хочешь называть это исследованием и чтобы его результаты имели практическую ценность и обоснованность — должен быть виден код, который приводит к таким результатам. Скажи честно, ты смотрел для каждого варианта то, что генерит компилятор на уровне ассемблера? Ты разбирался как каждый из них работает с исключениями и с возвращающими значениями и влияние этого на кодогенерацию в целом? А ведь это все нужно, чтобы не просто статистику поиметь, а сделать из нее выводы — самое ценное, что есть в исследовании. Я выводов пока (как и самого исследования) пока тут не вижу, уж извини.

M>То есть у вас есть лучшее тестирование , и вы его зажимаете и не выкладываете ?

Я где-то такое говорил?

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

Пояснения:

// В этой точке мы имеем максимальный приоритет потока - 31
// Надо это для того, чтоб как можно меньше постороннего кода вщемилось в наш
// Оптимальные измерения будут на многоядерных машинах - там остальной код будет
// большей частью вытеснен на другие ядра. Для одноядерки это только несколько снизит 
// кол-во потоков.
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

// Гарантируем что ОС не перебросит поток на другое ядро - таким образом можно смело юзать
// rdtsc т.к. синхронизация TSC нас парить не будет
SetProcessAffinityMask (GetCurrentProcess (),1);

// Ну, это можно было и не делать - но пусть будет на всяк случай
SetThreadAffinityMask (GetCurrentThread (),1);

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

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

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

AS>А я тебя уверяю в обратном. Сравни std и com исключения. Обычно в проекте своя иерархия исключений, и они транслируются на разных уровнях вызова. Как в этом случае добиться преймущества от исключений на уровне вызова библиотечных методов\функций — вопрос интересный.

Я не говорю, что другого не бывает. Но бывает, что не транслируются. Но как мы поймём более сложный случай, если не поймём простой?


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

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

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

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

AS>А при чем тут один. Ты тестировал на одной конфигурации?

Я тестировал на двух машиных, на обоих одно ядро.



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

AS>>> Круто.

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

AS>Да. Сильно. А ты не подумал, что выбор минимального из результатов — это в корне неправильный подход к статистике?

Я сделал это вполне намеренно. Это вполне распространённый подход при замерах времени в условиях возникновения непредвиденных задержек.


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

AS>Да нет, я не настаиваю. Просто если ты хочешь называть это исследованием и чтобы его результаты имели практическую ценность и обоснованность — должен быть виден код, который приводит к таким результатам. Скажи честно, ты смотрел для каждого варианта то, что генерит компилятор на уровне ассемблера? Ты разбирался как каждый из них работает с исключениями и с возвращающими значениями и влияние этого на кодогенерацию в целом? А ведь это все нужно, чтобы не просто статистику поиметь, а сделать из нее выводы — самое ценное, что есть в исследовании. Я выводов пока (как и самого исследования) пока тут не вижу, уж извини.

Чего-чего, а ассемблера я нагляделся за эти дни. Нагляделся на создание фреймов исключений и проверки возвращаемых значений.