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

@Woldemar89 · Регистрация: 30.07.2015

Студворк — интернет-сервис помощи студентам

Работаю с финансовыми данными, максимальное количество знаков после запятой - 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

С миру по нитке хоть собрать бы. Есть мнения хотя бы?

Psilon · 21.01.2016, 15:33

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

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

Я знаю пару людей, которые вместо общепринятой терминологии используют свою собственную

Так что меня этим не проймешь: я говорю на языке, который понимает > 1 человека.

Когда говорят про .Net, различают 2 компилятора: csc.exe, который фактически ничего не делает, тупо транслируя 1:1 C# в IL, не выполняя никаких оптимизаций, а и JIT-компилятор (в простонародье просто джит), который уже занимается оптимизациями (насколько позволяют временные рамки), превращает уже в инструкции целевой машины код и т.п.

Так вот, еще не существует JIT-компилятора IL-кода, который по оптимизациям сделает gcc/icc/msvscc/llvm/... Да и невозможно физически за такой ограниченный промежуток времени сделать правильные выводы из окружения.

@maxillion · 21.01.2016, 17:08

Сообщение от Psilon

Когда говорят про .Net, различают 2 компилятора: csc.exe, который фактически ничего не делает, тупо транслируя 1:1 C# в IL, не выполняя никаких оптимизаций

странно у меня почему то это код

C#
1
2
3
4
public static int Main(string[] args)
{
    return 5 * 5;
}

транслируется в

C#
1
2
3
4
public static int Main(string[] args)
{
    return 25;
}

Интересно а зачем вообще есть опция оптимизировать ?
Интересно то что к .net относится еще несколько языков, например F# который транслирует

C#
1
2
3
4
5
6
static int foo() => 5;
 
public static int Main(string[] args) 
{
    return 5 * foo();
}

в

C#
1
2
3
4
public static int Main(string[] args) 
{
    return 25;
}

Чего почему то не может сделать csc.exe.

Psilon · 21.01.2016, 19:21

maxillion, давно уже исследовал оптимизации процессорные.
Вот, можно всю тему почитать в принципе, даю прямую ссылку на то, как С оптимизирует (плюсы в этом плане мощнее намного, вспомнить только cosntexpr)
Оптимизации, производимые компилятором

@pycture · 21.01.2016, 19:26

Сообщение от maxillion

например F# который транслирует

чего чего он делает ?

Psilon · 22.01.2016, 12:15

maxillion, ну и нужно понимать, что как раз JIT всё это дело оптимизирует, т.к. это элементарная оптимизация
19h = 25

Это практически единственное, что JIT еще может оптимизировать. И это не показатель.

@maxillion · 22.01.2016, 12:35

Сообщение от Psilon

ну и нужно понимать, что как раз JIT всё это дело оптимизирует

Оптимизирует самое простое, тратя при этом время для запуска программы. В принципе оно и понятно почему. Вопрос в том, почему эту оптимизацию не переложат на транслятор языка, как например это сделано в F#.

Psilon · 22.01.2016, 12:43

maxillion, так кто ж утверждал, что JIT-компилятор всё знает на целевой машине и может все круто оптимизировать?

Вот поэтому на него и возложили оптимизации. А почему не стали дублировать оптимизации в csc, да потому что это упрощало его разработку и работу. Больше кода - больше багов, больше стоимость, дольше разработка... И да, я не уверен, что F# делает это на этапе компиляции. Т.к. это тот же .Net-язык и подчиняется он общим правилам, компилируется одним и тем же джитом, соответственно и поступать должен примерно также, как и другие нет-компиляторы.

@maxillion · 22.01.2016, 13:01

Сообщение от Psilon

так кто ж утверждал, что JIT-компилятор всё знает на целевой машине и может все круто оптимизировать?

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

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
static int a()
{
    int x = 0;
    for (int i = 0; i < 10; i++)
    {
        x++;
    }
    return x;
}
public static void Main(string[] args) 
{
    Console.WriteLine(a()*a());
}

Сообщение от Psilon

И да, я не уверен, что F# делает это на этапе компиляции

Проверял на этом, делает

F#
1
2
3
4
5
6
let foo() = 5
 
[<EntryPoint>]
let main argv =  
    System.Console.WriteLine( foo()*foo() )
    0

Konctantin · 22.01.2016, 13:46

Не по теме:

Пока вы тут спорите, в репо corecrl идут пуши с оптимизациями simd инструкций

@pycture · 22.01.2016, 14:24

Сообщение от maxillion

Проверял на этом, делает

а проку то?
C#

Assembler
1
2
3
4
5
6
7
    Console.WriteLine(Program.a() * Program.a());
000007FE8F0C4280  sub         rsp,28h  
000007FE8F0C4284  mov         ecx,19h  
000007FE8F0C4289  call        000007FEED8BAC10  
000007FE8F0C428E  nop  
000007FE8F0C428F  add         rsp,28h  
000007FE8F0C4293  ret

F#

Assembler
1
2
3
4
5
6
    System.Console.WriteLine( foo() * foo()  )
00370450  mov         ecx,19h  
00370455  call        728B29DC  
    0
0037045A  xor         eax,eax  
0037045C  ret

Psilon · 22.01.2016, 14:32

pycture, какой-то неправильный листинг, похоже на дебаг-сборку

Я выше скриншот привел.

Konctantin, SIMD сейчас реализован только через библиотечку МС, насколько я помню, причем поддерживает его только RyuJit, причем если на целевой платформе SIMD'а не будет (хотя это конечно маловероятно, но все же) генерируется очень неэффективный код. Но в целом радует конечно это направление. Это не C++ AMP, но тоже ничо.

@maxillion · 22.01.2016, 15:11

Сообщение от pycture

а проку то?

А вы посмотрите через ILspy а потом скажите есть ли прок.

@pycture · 22.01.2016, 15:16

Сообщение от maxillion

А вы посмотрите через ILspy а потом скажите есть ли прок

а зачем смотреть на сферического коня? я реальный код исполняемый процессором привел

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

Сообщение от Psilon

какой-то неправильный листинг, похоже на дебаг-сборку

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

@maxillion · 22.01.2016, 15:21

Сообщение от pycture

чтоб в студии остановить и листинг вытащить

Дак можно и так остановить, главное правильно настроить.

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

Сообщение от pycture

а зачем смотреть на сферического коня? я реальный код исполняемый процессором привел

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

Psilon · 22.01.2016, 15:28

Сообщение от pycture

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

ну так если дебаг сборка, то результат неправильный (причем даже если стоит релиз, это не значит, что компилится релиз, ведь дебаггер подцепился). Правильный я уже выше дал, не думаю, что у тебя какой-то другой JITер

Сообщение от maxillion

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

Еще раз, оптимизации в csc.exe не запихнули, т.к. это было дорого и усложнило бы разработку.
Поэтому они есть в JIT'е, в котором эти самые оптимизации ограничены по времени, и предподсчитать цикл он не может. Какие еще вопросы? Почему они так сделали? Потому что не хотели тратить лишние деньги, вот и все. Не считая потенциальных подводных камней. Когда модуль оптимизации один, всё просто и понятно. Когда их несколько, то начинаются забавные взаимные эффекты. Стоит вспомнить например ObjC, в котором ТРИ разных сборщика мусора, которые могут подраться и удалить живой объект.

@maxillion · 22.01.2016, 15:39

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

Сообщение от Psilon

Потому что не хотели тратить лишние деньги, вот и все.

Дак если они лишнии, то почему бы не потратить, ведь на F# не пожалели. Ладно фиг с этими деньгами, не пойму ведь f# и c# это практически аналоги, почему бы не перенести оптимизацию f# на с# ?

Psilon · 22.01.2016, 15:45

Сообщение от maxillion

Дак если они лишнии, то почему бы не потратить, ведь на F# не пожалели. Ладно фиг с этими деньгами, не пойму ведь f# и c# это практически аналоги, почему бы не перенести оптимизацию f# на с# ?

Потому что разные компиляторы. Если посмотреть историю Rosylin, они хотели переписать на .Net csc.exe (это ведь нативный компилятор на С++), так вот нишмагли) Со всеми исходниками на руках, и т.п. все тормозило так, что они отказались от этой идеи и сделали Rosylin в том виде, что он есть: просто Compiler as a service. Еще раз напоминаю, что всё это - деньги. И если когда csc.exe создавался шарп был COOL-язык майкрософта, с непонятным будущим и перспективами, и на него выделили один объем средств, то когда создавался F#, .Net победоносно шел по планете, шарп набирал популярность, и бюджет команды был совсем другим

Это конечно всё мои фантазии, но в принципе это возможные причины.

@maxillion · 22.01.2016, 15:52

Сообщение от Psilon

Потому что разные компиляторы

Дак компилируют то , в одно и тоже MSIL. Значит наверно оптимизация начинается на этапе компиляции, и IL ей не подвергается, что как то глупо выходит. А может просто фшарпёры работают отдельно от сишарпёров, и не чего друг о друге не знают

Psilon · 22.01.2016, 16:23

maxillion, еще раз, если есть различия на уровне Il'а, то комплияторы csc.exe fsc.exe по разному компилируют. Что наверняка так, ибо языки принципиально различаются. После того, как Il скомпилился, он будет одним и тем же джитом обрабатыаться. В шарпе проблема в том, что есть 2 этапа компиляции: text -> IL, IL -> x86. Хотя вопрос привычки. С тем же успехом люди часто путаются в потоках, например (stream/thread), есть еще пара мелочей. Со временем путаница проходит.

@Shamil1 · 22.01.2016, 16:45

Оптимизацию можно условно поделить на "алгоритмическую" и "железную". Замена константной функции на константу, замена хвостовой рекурсии и т.п. - это "алгоритмическая" оптимизация. Подобной оптимизацией должен заниматься "компилятор в промежуточный код". А "железной" (т.е. под конкретное железо) оптимизацией должен заниматься "компилятор из промежуточного кода в машинный". "Железная" оптимизация по сути сводится к нахождению в коде неких шаблонов и замена их на соответствующий машинный код.

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

Сообщение от Psilon

Если посмотреть историю Rosylin, они хотели переписать на .Net csc.exe (это ведь нативный компилятор на С++), так вот нишмагли) Со всеми исходниками на руках, и т.п. все тормозило так, что они отказались от этой идеи и сделали Rosylin в том виде, что он есть: просто Compiler as a service.

Откуда такая информация?

Новые блоги и статьи Все статьи Все блоги /
ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .
Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .	Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .

@Woldemar89 TheGreatCornholio 1255 / 733 / 285 Регистрация: 30.07.2015 Сообщений: 2,408

	Быстродействие double, decimal в x64 19.01.2016, 11:48. Показов 9862. Ответов 106 Метки decimal, double, 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 Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	21.01.2016, 19:21
	maxillion, давно уже исследовал оптимизации процессорные. Вот, можно всю тему почитать в принципе, даю прямую ссылку на то, как С оптимизирует (плюсы в этом плане мощнее намного, вспомнить только cosntexpr) Оптимизации, производимые компилятором 1

Psilon Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	22.01.2016, 12:15
	maxillion, ну и нужно понимать, что как раз JIT всё это дело оптимизирует, т.к. это элементарная оптимизация 19h = 25 Это практически единственное, что JIT еще может оптимизировать. И это не показатель. Миниатюры 2

Psilon Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	22.01.2016, 12:43
	maxillion, так кто ж утверждал, что JIT-компилятор всё знает на целевой машине и может все круто оптимизировать? Вот поэтому на него и возложили оптимизации. А почему не стали дублировать оптимизации в csc, да потому что это упрощало его разработку и работу. Больше кода - больше багов, больше стоимость, дольше разработка... И да, я не уверен, что F# делает это на этапе компиляции. Т.к. это тот же .Net-язык и подчиняется он общим правилам, компилируется одним и тем же джитом, соответственно и поступать должен примерно также, как и другие нет-компиляторы. 1

Konctantin
	22.01.2016, 13:46
	Не по теме: Пока вы тут спорите, в репо corecrl идут пуши с оптимизациями simd инструкций 0

Psilon Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	22.01.2016, 14:32
	pycture, какой-то неправильный листинг, похоже на дебаг-сборку Я выше скриншот привел. Konctantin, SIMD сейчас реализован только через библиотечку МС, насколько я помню, причем поддерживает его только RyuJit, причем если на целевой платформе SIMD'а не будет (хотя это конечно маловероятно, но все же) генерируется очень неэффективный код. Но в целом радует конечно это направление. Это не C++ AMP, но тоже ничо. 1

Psilon Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	22.01.2016, 16:23
	maxillion, еще раз, если есть различия на уровне Il'а, то комплияторы csc.exe fsc.exe по разному компилируют. Что наверняка так, ибо языки принципиально различаются. После того, как Il скомпилился, он будет одним и тем же джитом обрабатыаться. В шарпе проблема в том, что есть 2 этапа компиляции: text -> IL, IL -> x86. Хотя вопрос привычки. С тем же успехом люди часто путаются в потоках, например (stream/thread), есть еще пара мелочей. Со временем путаница проходит. 1