Скорость.NET в числовых вычислениях
Вот представление Вашего псевдокода в минимальном коде Java;
boolean isEven = a % 2 == 0;
я теперь разломаю его на его компоненты. Оператор модуля в Java является символом процента (%). Поэтому взятие международного интервала % возвращает другой интервал, которому двойное равняется (==), оператор используется для сравнения значений, таких как пара ints и возвращает булевскую переменную. Это тогда присвоено логической переменной 'isEven'. На основе приоритета оператора модуль будет оценен перед сравнением.
5 ответов
Дело в C ++ / CLI верное. Чтобы завершить картину, всего два дополнительных интересных момента:
Управление памятью .NET (сборщик мусора), очевидно, здесь не проблема, поскольку от него все еще зависит NMath
Преимущество в производительности фактически обеспечивается Intel MKL, который предлагает реализации чрезвычайно оптимизированы для многих процессоров. С моей точки зрения, это ключевой момент. Использование простого, наивного кода C / C ++ не обязательно даст вам более высокую производительность по сравнению с C # /. NET, иногда это даже хуже. Однако C ++ / CLI позволяет использовать все «грязные» варианты оптимизации.
Поскольку (собственный) Intel MKL выполняет математические вычисления, вы на самом деле не выполняете математические вычисления в управляемом коде. Вы просто используете диспетчер памяти из .Net, поэтому результаты легко используются кодом .Net.
Ключ - C ++ / CLI . Он позволяет компилировать код C ++ в управляемую сборку .NET.
Я опубликовал в блоге статью , посвященную этому вопрос.
Как они могут это сделать?
Как и большинство числовых библиотек для .NET, NMath - это немного больше, чем оболочка над Intel MKL, встроенная в сборку .NET, возможно, путем связывания с C ++ / CLI для создания смешанной сборки . Вероятно, вы только что протестировали те биты, которые на самом деле не написаны на .NET.
Статьи журнала F # .NET Числовые библиотеки: специальные функции, интерполяция и случайные числа (16 марта 2008 г.) и Числовые библиотеки: линейная алгебра и спектральные методы (16 апреля 2008 г.) протестировал довольно много функциональности, и NMath оказался самой медленной из всех коммерческих библиотек. Их ГПСЧ был медленнее, чем все другие, и на 50% медленнее, чем бесплатная библиотека Math.NET, отсутствовали некоторые базовые функции (например, возможность вычисления Гамма (-0,5) ) и другие базовые функции (Гамма- связанные функции, которые они предоставляли) был нарушен. И Extreme Optimization, и Bluebit превзошли NMath в тесте eigensolver. NMath в то время даже не предоставлял преобразование Фурье.
Что еще более удивительно, расхождения в производительности иногда были огромными. Самая дорогая коммерческая числовая библиотека, которую мы тестировали (IMSL), была более чем в 500 раз медленнее, чем бесплатная библиотека FFTW в тесте FFT, и ни одна из библиотек не использовала несколько ядер в то время.
Фактически, именно низкое качество этих библиотек побудило нас коммерциализировать нашу собственную библиотеку F # for Numerics (которая на 100% представляет собой чистый код F #).