Быстродействие double, decimal в x64

Работаю с финансовыми данными, максимальное количество знаков после запятой - 4.
Получаю данные по DDE в формате object[][]. Тип объекта может быть string или double.

Возникли следующие вопросы:
1. Арифметика double крутиться в регистрах процессора на x64, коли double 8 бит?
2. Раз уж приложение работает с финансами, и, вроде как, желательно использовать decimal,
могу ли я без значительных издержек (погрешность допускается) обойтись double в угоду быстродействия?
3. Если все-таки, захочу работать с double, применение Math.Round не отнимет полученного выигрыша в производительности?
4. Как правильно задать конфигурацию решения x64?
5. Как из object, тип которого заранее известен (double), быстрее получить значение? Распаковка (double)obj?
6. Допустим, имеется класс, с полем double и в DGV отображается BindingList<SomeClass>,
как заставить отображаться этот double с определенным количеством цифр после зпт? (вопрос не особо важен).
7. Какие есть способы быстро работать с decimal и конвертировать из double в decimal?
8. Ну, а так же интересуют комментарии в целом, по поводу быстродействия в данных условиях.

Добавлено через 16 часов 54 минуты
Сокращаю перечень вопросов до 1, 4, 8
С миру по нитке хоть собрать бы. Есть мнения хотя бы?

0

Сообщение от Psilon Или почему нужно сначала класть результат вычислений в локальную переменную, а только потом её возвращать

а можно поподробнее или ссылку на объяснение?

0

Сообщение от Woldemar89 И вообще, в голову пришла мысля, если уж оптимизировать, - то писать в Native.

В общем случае (потенциально) нативный код работает медленнее (из-за отсутствия оптимизации под конкретный процессор).

0

Сообщение от Shamil1 Нет.

В моем случае, скорее, да, как запилю - узнаю.

Сообщение от Shamil1 В общем случае (потенциально) нативный код работает медленнее (из-за отсутствия оптимизации под конкретный процессор).

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

0

Сообщение от Shamil1 В общем случае (потенциально) нативный код работает медленнее (из-за отсутствия оптимизации под конкретный процессор).

В очень сферической теории в вакууме. На самом деле все наоборот, ибо если С++ компилятор может час компилить приложение, и использовать кучу нюансов, которые он смог проанализировать за это время, то у JIT-у дается 50мс на компиляцию метода, после чего он должен его отдать. Ему не до оптимизаций, ему бы успеть хотя бы просто транслировать код.

Сообщение от aquaMakc а можно поподробнее или ссылку на объяснение?

Опять же - нюансы компилятора Тыц

1

Psilon, читал этот блог, пару недель назад, решил оставить на потом,
тк автор жжет ваще не по-детски, тут без бутылки вообще никак

0

0

Сообщение от Psilon На самом деле все наоборот, ибо если С++ компилятор может час компилить приложение, и использовать кучу нюансов, которые он смог проанализировать за это время

Большинство приложений распространяются не в виде исходного кода, который нужно компилировать, а в виде готовых исполняемых файлов (exe, dll и т.п.).

Добавлено через 5 минут

Сообщение от Woldemar89 В моем случае, скорее, да, как запилю - узнаю.

Если финансовое приложение допускает, что сумма зависит от порядка суммирования, то ИМХО это уже не финансовое приложение...

0

Сообщение от Shamil1 Если финансовое приложение допускает, что сумма зависит от порядка суммирования, то ИМХО это уже не финансовое приложение...

Не бухгалтерское, но тем не менее, деньги там замешаны, и даже 10 копеек там роли не сыграют.

Сообщение от Shamil1 Большинство приложений распространяются не в виде исходного кода, который нужно компилировать, а в виде готовых исполняемых файлов (exe, dll и т.п.).

Вы разницу знаете между компилятором, интерпретатором и виртуальной машиной?

0

Сообщение от Woldemar89 Вы разницу знаете между компилятором, интерпретатором и виртуальной машиной?

Да.

0

Сообщение от Shamil1 Большинство приложений распространяются не в виде исходного кода, который нужно компилировать, а в виде готовых исполняемых файлов (exe, dll и т.п.).

Правильно. Компилятор С++ потратил час на оптимизацию кода, рассчитанного на неизвестную машину. exe же который выходит из под csc.exe по факту является обычными исходниками шарпа, то которые компилируются на целевой машине. И у JIT'а нету ЧАСОВ на компиляцию, когда он ограничен временными рамками в десятки миллисекунд.

Добавлено через 1 минуту
csc.exe не занимается оптимизациями вообще, эта работа возложена на JIT на целевой машине. И никакая априорная информация о поддерживаемых инструкциях SSE или там числе ядер не даст выигрыш, который дает тупой перебор всех возможных оптимизаций без оглядки на затрачиваемое время.

0

Сообщение от Shamil1 Да.

Ну тогда наверно знаете о CLRRuntime, JIT, ngen, MSIL,
Так как думаете, нормально, и как подчеркивает Psilon, не спеша откомпилированный
в машинные команды код, медленней MSIL, прошедшего за десятки мсек через всю эту мясорубку?

Добавлено через 10 минут
Надеюсь довольно скоро это нововведение будет универсальным и позволит обычные приложения компилить в native.
http://habrahabr.ru/company/microsoft/blog/265889/

0

Woldemar89, это старая тема, и мне она не сильно нравится, хотя это конечно лучше чем то, что у нас сейчас. Я бы предпочел то, как в андройде начиная с 5 версии делается: приложение скачивается на устройство и на нем компилируется при установке. Было бы отлично точно также делать и тут, то есть примерно то же, но не на машине разработчика, а на целевой машине пользователя. Что-то подобное происходит при установке Paint.net, но я честно говоря не лазил по их исходникам и не знаю, что и как они делают

0

Сообщение от Woldemar89 Ну тогда наверно знаете о CLRRuntime, JIT, ngen, MSIL, Так как думаете, нормально, и как подчеркивает Psilon, не спеша откомпилированный в машинные команды код, медленней MSIL, прошедшего за десятки мсек через всю эту мясорубку?

Я думаю, что у Вас каша в голове, если Вы объединяете "CLRRuntime, JIT, ngen, MSIL" в "мясорубку".
CLRRuntime не существует. Есть CLR, в которой последняя буква и означает Runtime.
JIT - это технология, ngen - это утилита, MSIL - это язык.

1

Сообщение от Psilon и не знаю, что и как они делают

Сообщение от Woldemar89 ngen

По видимому.

0

Сообщение от Psilon Компилятор С++ потратил час на оптимизацию кода, рассчитанного на неизвестную машину.

Потратил час, выясняя как лучше распределить вычисления между регистрами, и производительность выросла на 30%.... А простым использованием SSE этот код можно было ускорить в 4 раза...

0

Shamil1, только вот JIT не использует SSE. Можно долго рассуждать о Рихтере и о том, что потенциально JIT много чего позволяет, но на практике они даже новый рюджит не смогли написать нормально, так что он оптимизирует лучше "старого" х64. И да, автоматически SSE компилятор не использует (разве что иногда, для извлечения квадратного корня и т.п, но разница там просто мизерная), а настоящий SIMD работает только в ручном режиме с соответствующим классом, только в новом фреймворке и прочее и прочее.

В мире радуг и розовых пони возможно шарп быстрее плюсов, но на практике имеем 20-50% меньшую производительность в общем случае.

Сообщение от Shamil1 Потратил час, выясняя как лучше распределить вычисления между регистрами, и производительность выросла на 30%.... А простым использованием SSE этот код можно было ускорить в 4 раза...

Ну и нужно понимать, что всё это словесная эквилибристика, 30% мы имеем на выполнении всего кода, а в 4 раза - только участка, который можно оптимизировать, при условии, что его оптимизировали. В результате 1*0.7 < 0.9*1 + 0.1*0.25.

Я был бы очень рад, если бы шарп был такой производительный, но на практике это не так. Это не повод всем валить на плюсы, но и говорить, в стиле Рихтера, что у CLR замечательные возможности для оптимизации - возможностей практически нет. Знания о целевой архитектуре есть, а вот времени использовать эту информацию - нет.

0

Сообщение от Psilon Ну и нужно понимать, что всё это словесная эквилибристика, 30% мы имеем на выполнении всего кода, а в 4 раза - только участка, который можно оптимизировать, при условии, что его оптимизировали.

Золотые слова

0

Сообщение от Psilon Ну и нужно понимать, что всё это словесная эквилибристика, 30% мы имеем на выполнении всего кода, а в 4 раза - только участка, который можно оптимизировать, при условии, что его оптимизировали. В результате 1*0.7 < 0.9*1 + 0.1*0.25.

Перепишите свой расчёт с учётом того, что выполнение этого маленького участка занимает 90% времени.

Добавлено через 7 минут

Сообщение от Psilon JIT не использует SSE

JIT - это технология,

Сообщение от Psilon В мире радуг и розовых пони возможно шарп быстрее плюсов

Обратите внимание, что это Вы сравниваете шарп с плюсами. Я же писал про нативный и промежуточный код в общем случае, причём в перспективе:
"В общем случае (потенциально) нативный код работает медленнее (из-за отсутствия оптимизации под конкретный процессор)."

0

Сообщение от Shamil1 JIT - это технология,

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

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

Сообщение от Shamil1 Перепишите свой расчёт с учётом того, что выполнение этого маленького участка занимает 90% времени.

Может еще предметную область поменять, где всё попроще?

0

Сообщение от Psilon я имею ввиду любой существующий джит

джит - это НЕ компилятор, джит - это конкретный алгоритм выбора момента компиляции

Сообщение от Psilon Может еще предметную область поменять, где всё попроще?

Меняйте, если хотите. Какое это имеет отношение к тому факту, что в программах, требующих оптимизации, обычно 10% кода выполняется 90% времени.
А если Вы до сих пор верите в корректность своего подсчёта ("В результате 1*0.7 < 0.9*1 + 0.1*0.25."), то возьмите какую-нибудь (нормально написанную) программу, требующую оптимизации и скомпилируйте её два раза:
1. С использованием IPO и PGO, но так, чтобы она работала под любым (из актуальных) процессором.
2. Без использования IPO и PGO, но под свой процессор.
И сравните скорость работы.

0