Быстродействие 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 · 22.01.2016, 16:54

Shamil1, отсюда, если мне память не изменяет

@pycture · 22.01.2016, 16:56

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

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

вроде ктото утверждал что csc не оптимизирует, а fsc оптимизирует. откуда тогда оптимизация в мсиле для c# появится? или он все таки есть?

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

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

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

все тап правильное. методы разные. я ж не return Get5 делаю

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

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

f# и c# это практически аналоги

фигасе заява на победу

@maxillion · 22.01.2016, 17:09

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

фигасе заява на победу

Я имел ввиду то что все компилируются в одно и тоже MSIL. А значит и возможности схожи, за исключением того что у f# компилятор круче в плане статического анализа и кодо-генерации. Хотя Psilon, говорит что у них разный MSIL, во что как то с трудом верится, хотя бы потому что у меня ILspy спокойно открывает f#. Ладно смысла спорить на кофейной гуще не вижу, всю правду знает только MS.

@pycture · 22.01.2016, 17:28

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

может просто фшарпёры работают отдельно от сишарпёров, и не чего друг о друге не знают

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

@Shamil1 · 22.01.2016, 17:59

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

компилируются в одно и тоже MSIL

MSIL один и тот же. Но не все его конструкции используются во всех языках, которые в него компилируются.

@maxillion · 22.01.2016, 18:45

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

Но не все его конструкции используются во всех языках

Может примерчик покажите что можно в с# но нельзя на f# (или на оборот) на MSIL ради интереса.

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

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

решения обкатываются в фшарп

Дак получается что фшарп помойка для теста новых идей что ли

Psilon · 22.01.2016, 19:21

maxillion, не скажу конкретно за F#, но например в MSIL можно написать generic

C#
1
2
3
4
T Sum<T>(T a, T b)
{
   return a + b;
}

а на шарпе он скажет, что оператор + не определен для типа T.

Добавлено через 45 секунд
из примерчиков могу назвать фильтры исключений: они есть в Visual Basic.Net, но в шарпе их добавили только в последней версии (6.0 или 7.0). Очевидно, что в IL они поддерживались всегда

@maxillion · 22.01.2016, 19:42

Ну если верить pycture, то IL f# самый богатый. А значить если в нем существует оптимизатор байт кода (что было бы логично), то оптимизировать более бедный IL с# ему не составит труда, это как с++ может строить и оптимизировать си но не на оборот. Может эта оптимизация просто проходит опкатку, как говорил pycture, а может уже прошла и на неё просто забили.

@pycture · 22.01.2016, 20:43

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

Может примерчик покажите что можно в с# но нельзя на f#

с# уже научился tailcall вставлять?

Дак получается что фшарп помойка для теста новых идей что ли

не. помойка для идей у ms была.... хаскель. из него обкатанные идеи уходили в f#. а из него уже что могли, по требованию миллионов ~~мух~~ кодеров, засовывали уж (как получалось) в с#,

Добавлено через 28 минут
оптимизация в f# вообще вещь занятная и непредсказуемая

Кликните здесь для просмотра всего текста

Не по теме:

F#
1
2
3
4
5
6
7
8
9
type O = { x : int }
    with static member inline (+) (a : O, b : O) = { x = a.x + b.x }
 
let inline add a b c = a + b + c
 
do
    System.Console.Write (add 3 9 10)
    System.Console.Write (add "sss" "aaa" "1")
    System.Console.Write (add {x=3} {x=9} {x=10})

превращается в MSIL(C#)

C#
1
2
3
4
5
6
public static void main@()
{
    Console.Write(22);
    Console.Write("sss" + "aaa" + "1");
    Console.Write(new Program.O(22));
}

пользовательские структуры значит оптимизить умеем, а вот встроеный стринг ну никак

@Woldemar89 · 22.01.2016, 20:57 **[ТС]**

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

Добавлено через 5 минут
Даже тот же ассемблер напрямую зависит от аппаратной части например.

@Woldemar89 · 22.01.2016, 21:04 **[ТС]**

Все ваши холивары по этому поводу, содержатся, как мне кажется, в условных обозначениях

Особенно, интересно последнее...

@Woldemar89 · 22.01.2016, 21:13 **[ТС]**

Также могу сказать, что многие имеют понятия лишь о 1-5 языках,
а их на самом деле туева куча, что опять же подтверждает, что

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

ну не может язык иметь абсолютного превосходства над всеми

иначе бы все кодили на русском языке

Вот на нем-то выражений, оборотов, метафор, способов выражения мыслей и прочего - столько, что на всех хватит

@maxillion · 22.01.2016, 21:20

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

пользовательские структуры значит оптимизить умеем, а вот встроеный стринг ну никак

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

F#
1
2
3
4
5
6
[<EntryPoint>]
let main argv =  
    "1"+"1"+"1" |> printfn "%s"
    "1"+"1"     |> printfn "%s"
    "1"         |> printfn "%s"
    0

@Shamil1 · 23.01.2016, 01:39

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

Может примерчик покажите что можно в с# но нельзя на f# (или на оборот) на MSIL ради интереса.

Навскидку (но точно не помню): в MSIL есть уровень доступа protected internal, а в c# такого нет. Есть и другие примеры, но это нужно смотреть спецификацию.

@pycture · 23.01.2016, 09:53

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

как мне кажется, в условных обозначениях

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

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

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

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

и в чем он заключается? я не уловил.

@maxillion · 23.01.2016, 09:58

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

и в чем он заключается? я не уловил.

подсказочка

F#
1
2
3
4
5
6
[<EntryPoint>]
let main argv =    
    let a:obj = upcast "1" 
    let b:obj = upcast "1" 
    printfn "%b" ( obj.ReferenceEquals(a,b) )
    0

@pycture · 23.01.2016, 10:17

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

подсказочка

и что с того что они одинаковые? плюс неосиления сложения строк на этапе компиляции то в чем?

@maxillion · 23.01.2016, 10:34

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

и что с того что они одинаковые?

Интернирование строк. экономия места на диске и в оперативе, копейки но всё же.

Кстати зная эту штуку, можно написать интересный код

C#
1
2
3
4
5
6
7
8
unsafe static void Main()
{
    fixed(char *c = "x")
    {
        *c = 'y';
    }
    Console.WriteLine("x");
}

@pycture · 23.01.2016, 10:40

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

экономия места на диске и в оперативе

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

@maxillion · 23.01.2016, 10:45

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

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

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

Новые блоги и статьи Все статьи Все блоги /
Запустил конкурс "тем и промптов для текстовых квестов созданных почти чисто ИИ" Adler 06.10.2026 Всем привет! За последние три-четыре дня я создал более 16 текстовых квестовых игр используя преимущественно по одному запросу к ИИ на игру. Мне так понравилось смотреть все ветки/ сцены во всех. . .	ИИ не может найти нужный язык в списке 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 и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .

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

	Быстродействие double, decimal в x64 19.01.2016, 11:48. Показов 9809. Ответов 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
	22.01.2016, 16:54
	Shamil1, отсюда, если мне память не изменяет 0

@maxillion 286 / 192 / 56 Регистрация: 25.12.2012 Сообщений: 640
	22.01.2016, 19:42
	Ну если верить pycture, то IL f# самый богатый. А значить если в нем существует оптимизатор байт кода (что было бы логично), то оптимизировать более бедный IL с# ему не составит труда, это как с++ может строить и оптимизировать си но не на оборот. Может эта оптимизация просто проходит опкатку, как говорил pycture, а может уже прошла и на неё просто забили. 0

@Woldemar89 TheGreatCornholio 1255 / 733 / 285 Регистрация: 30.07.2015 Сообщений: 2,408
	22.01.2016, 20:57 [ТС]
	По моему, сравнивать языки в целом - не совсем правильно. Сравнение нужно проводить в в отдельных областях, ну не может язык иметь абсолютного превосходства (смотрим таблицы возможностей) над всеми, каждый хорош в какой то области, и у каждого свои особенности и фичи. Добавлено через 5 минут Даже тот же ассемблер напрямую зависит от аппаратной части например. 0

@Woldemar89 TheGreatCornholio 1255 / 733 / 285 Регистрация: 30.07.2015 Сообщений: 2,408
	22.01.2016, 21:04 [ТС]
	Все ваши холивары по этому поводу, содержатся, как мне кажется, в условных обозначениях Особенно, интересно последнее... Миниатюры 0