Быстродействие 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

Сообщение от Woldemar89 Работаю с финансовыми данными, максимальное количество знаков после запятой - 4

Да, кстати, при форматировании строки для вывода на печать есть формат "C" - денежная единица, вот только в нашей стране по умолчанию там 2 знака после запятой и ставится символ официальной валюты. Меняется (на всякий случай), в настройках ОС.

1

Psilon, небольшой вопрос в догонку, правильно ли я понимаю, что

будет явно быстрее

в совокупности, с тем, что обсуждалось выше?

0

Сообщение от Psilon С другой стороны если уж уже приходи в double и предполагается, что на точность можно подзабить, то и decimal можно не использовать.

Я вполне допускаю вариант, что библиотеку писали люди, не знающие о правиле decimal для денег, и считающие, что самый точный тип - это Double (я когда учился в далёком 2002 нам так и говорили). Я, если честно, не доверял бы людям возвращающим неопределённый тип данных. Кто их знает что ещё они могут в object засунуть в какой-нибудь нестандартной ситуации.

1

Сообщение от aquaMakc возвращающим неопределённый тип данных

Сообщение от aquaMakc не доверял бы людям возвращающим неопределённый тип данных

Что придет, - решаю я, и это будет число или строка, object[][] нужен для того, чтобы смешать разные типы данных в одну таблицу.
Второй раз себя процитирую

Сообщение от Woldemar89 я заранее знаю, что лежит в object - string или double, просто они вперемешку идут в object[][].

А по поводу double или decimal, с незначительной допустимой погрешностью, хорошо выразился

Сообщение от Psilon С другой стороны если уж уже приходи в double и предполагается, что на точность можно подзабить, то и decimal можно не использовать.

подтвердив мои мысли.

0

) немного поигравшись с культурами родился такой минимонстр:
C3 - денежный формат, 3 знака после запятой, потом из списка всех доступных культур линком выбираю en - английский формат. Странно только то, что знак доллар, возможно where возвращает несколько форматов, но разбираться как-то уже лениво.

1

aquaMakc, спасибо, я с этим чуть позже поразбираюсь, пока актуален вопрос о struct и class.
Быстродействие double, decimal в x64

0

aquaMakc, взял английскую культуру - получил доллар, что нелогичного-то?

Woldemar89, откуда ты получаешь-то? Если из управляемого кода, то нужно дженерики писать, если нет - то можно смотреть в сторону byte[].

Сообщение от Woldemar89 небольшой вопрос в догонку, правильно ли я понимаю, что

Быстрее, но вряд ли ты заметишь С тем же успехом 1.0 + 1.0 считается быстрее, чем double.Epsilon + double.Epsilon (см. денормализованные числа). Но ты ведь этого не учитываешь

1

Сообщение от Psilon откуда ты получаешь-то?

Сообщение от Woldemar89 Получаю данные по DDE

Библиотека NDDE, FTFHelper с помощью XLTable.Cells парсит полученный byte[] Data в object[][].

Сообщение от Psilon Быстрее, но вряд ли ты заметишь

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

0

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

Сообщение от Woldemar89 спасибо, я с этим чуть позже поразбираюсь, пока актуален вопрос о struct и class.

теоретически работа со структурами быстрее, практически - хз, попробуй поэкспериментировать с замером времени исполнения на паре тысяч объектов-болванок.

0

Сообщение от aquaMakc ну как-бы в англии денежная единица - фунт )

Ну так ты ж не для англии написал:

Миниатюры

 

0

Woldemar89, структуры всегда должны быть неизменяемыми. Алсо свойства стоит делать вместо полей, ибо бывают разные приколы. Из старого наболевшего: в WPF не будет работать биндинг, если указано поле, а не свойство. Ну и в принципе с точки зрения производительности get; private set; лучше. Во-вторых ты занимаешься оптимизациями до непосредственных замеров, это плохо. Нужно писать грамотно, как правильно по архитектуре, а затем оптимизировать проблемные места, ибо известно, что оптимизация и красота кода как правило противопоставлены.

С точки зрения же архитектуры в таком случае нужно понять, что тебе нужно - семантика перемещения или копирования. Если перемещения, то нужно делать класс, если копирования - то структуру. Класс и структура в первую очередь должны выбираться именно на основании необходимой семантики взаимодействия с ними.

Такие дела.

Но стоит начать с другой статьи (он в первом предложении на неё ссылается).

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

I find this characterization of a value type based on its implementation details rather than its observable characteristics to be both confusing and unfortunate. Surely the most relevant fact about value types is not the implementation detail of how they are allocated, but rather the by-design semantic meaning of “value type”, namely that they are always copied “by value”. If the relevant thing was their allocation details then we’d have called them “heap types” and “stack types”. But that’s not relevant most of the time. Most of the time the relevant thing is their copying and identity semantics.

1

Psilon, спасибо, буду переваривать

Добавлено через 2 минуты
И вообще, в голову пришла мысля, если уж оптимизировать, - то писать в Native.
Может, и правда, дурью маюсь, но, в любом случае, знание не повредит.

0

Woldemar89, есть хороший парень - Андрей Акиньшин (он кстати замутил тему с тестами на форуме, но я с ним в реале встречался на конфах, он MVP). Так вот, он меня полностью пролечил от "напиши на С++ - сделай код быстрым"

1

Сообщение от Psilon он кстати замутил тему с тестами на форуме

Ага, к курсе.

Сообщение от Psilon полностью пролечил

Пролечил, в смысле вылечил? То есть, если руки из нужного места растут, C# тащит?

0

Woldemar89, грубо говоря да. Есть нюансы офк, но я вот например когда писал свою библиотечку (я её уже сломал, нужно будет переписывать ), писал её на шарпе, при этом предусматривал оптимизацию выполнения в разных хардварных потоках (это когда процессор видит две независимых инструкции и выполняет их одновременно). В результате добавив еще и многопоточность получил прирост в ~10 раз относительно LINQ с тем же результатом

0

Сообщение от Psilon писал её на шарпе, при этом предусматривал оптимизацию выполнения в разных хардварных потоках (это когда процессор видит две независимых инструкции и выполняет их одновременно).

Интересно, как это в шарпе выглядит, да и вообще.

Сообщение от Psilon относительно LINQ

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

0

Woldemar89, ну в данном случае я про Min, Max и все прочее без параметров. Производительность всяких других методов ограничена тем, что мы делаем. Когда вызов лямбды это половина затраченного времени, ибо там выражение x*x, то это не вина LINQ

Добавлено через 53 секунды

Сообщение от Woldemar89 Интересно, как это в шарпе выглядит, да и вообще.

Просто я подстраиваю код под паттерны компиляторных оптимизаций Выглядит немного страшно, зато работает быстро. Когда перепишу - покажу, пожалуй

0

Сообщение от Psilon то это не вина LINQ

Кстати да, интуиция мне это подсказывала, но я чет не прислушался.

Сообщение от Psilon Просто я подстраиваю код под паттерны компиляторных оптимизаций Выглядит немного страшно

Кто бы сомневался Особенно для моего уровня и ниже.

Я кстати чуть попереварил насчет классов и структур, спасибо за инфу, хранить в
Для меня вполне приемлемо, поэтому - почему бы нет, буду пилить.

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

0

Woldemar89, да ничего сложного на самом деле. Например нужно понимать, почему если мы итерируемся в цикле от 0 до 10000 элементов массива он посчитает быстрее, чем от 0 до 9999 Причем зачастую только на х64-компиляторе. Или почему нужно сначала класть результат вычислений в локальную переменную, а только потом её возвращать (даже если красивее просто вернуть результат). И т.п. Тут чисто эвристика и знание нюансов компилятора, ни больше ни меньше. Никакого rocket science тут нет и в помине, скорее даже наоборот

Но мое мнение в том, что пишешь один раз - пользуешься везде и знаешь, что оно быстрое и хорошее А какие там goto под капотом, не суть важно. Если код write-once, которому не нужна поддержка - то это самое оно. Мб потом еще добавлю поддержку SIMD Тогда будет вообще красота. Если будет возможность в рантайме проверить, есть ли SIMD.

1

Сообщение от Woldemar89 2. Раз уж приложение работает с финансами, и, вроде как, желательно использовать decimal, могу ли я без значительных издержек (погрешность допускается) обойтись double в угоду быстродействия?

Нет.

0