Насколько я могу приблизить C # к производительности C ++ для небольших интенсивных задач? - PullRequest
Новая
       9

Насколько я могу приблизить C # к производительности C ++ для небольших интенсивных задач?

4 голосов
/ 20 апреля 2010

Я думал о разнице в скорости C ++ и C # в основном из-за компиляции C # в байт-код, который принимается JIT-компилятором (это правильно?) И всех проверок, выполняемых C #.

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

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

Я хотел бы проверить это, но я не знаю C ++ или не имею инструментов для его компиляции. Это моя версия на C #: 

static void Main(string[] args)
{
    unsafe
    {
        Random rnd = new Random();
        int heads = 0, tails = 0;
        while (true)
        {
            if (rnd.NextDouble() > 0.5)
                heads++;
            else
                tails++;

            if ((heads + tails) % 1000000 == 0)
                Console.WriteLine("Heads: {0}  Tails:  {1}", heads, tails);
        }
    }
}

Достаточно ли разницы для того, чтобы гарантировать преднамеренную компиляцию фрагментов кода "небезопасно" или в библиотеки DLL, в которых не включены некоторые параметры компиляции, такие как проверка переполнения? Или все идет иначе, где было бы полезно компилировать разделы в C ++? Я уверен, что скорость взаимодействия тоже вступит в игру.

Чтобы избежать субъективности, я повторяю конкретные части этого вопроса как:

  • Есть ли в C # повышение производительности от использования небезопасного кода?
  • Повышают ли параметры компиляции, такие как отключение проверки переполнения, и влияют ли они на небезопасный код?
  • Будет ли приведенная выше программа быстрее на C ++ или ничем не отличается?
  • Стоит ли составлять длинные интенсивные задачи по обработке чисел на таком языке, как C ++, или использовать / unsafe для бонуса? Менее субъективно, я мог бы выполнить интенсивную операцию быстрее, делая это?

Ответы [ 2 ]

2 голосов
/ 20 апреля 2010

Приведенный пример некорректен, поскольку не показывает реального использования обоих языков программирования. Использование простых типов данных для измерения скорости языка не принесет ничего интересного. Вместо этого я предлагаю вам создать шаблонный класс в C ++ и сравнить его с тем, что возможно в C # для обобщений классов. В конце концов, объекты принесут некоторые важные результаты, и вы увидите, что C ++ быстрее, чем C #. Не говоря уже о том, что вы сравниваете язык программирования более низкого уровня с C #.

Есть ли у C # прирост производительности от использовать небезопасный код?

Да, это будет иметь толчок, но не рекомендуется писать только код с небезопасным. Вот почему: код, написанный с использованием небезопасного контекста, не может быть проверен на безопасность, поэтому он будет выполняться только тогда, когда код полностью доверен. Другими словами, небезопасный код не может быть выполнен в ненадежной среде. Например, вы не можете запускать небезопасный код напрямую из Интернета. http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

Будет ли указанная выше программа быстрее C ++ или ничем не отличается?

Да, программа будет немного быстрее на C ++. C ++ является более низким языком программирования и даже быстрее, если вы начнете использовать библиотеку алгоритмов (на ум приходит random_shuffle).

Стоит ли долго собирать интенсивные решающие задачи на языке такие как C ++ или использование / unsafe для бонус? Менее субъективно, могу ли я быстрее завершить интенсивную операцию делая это?

Это зависит от проекта ...

1 голос
/ 20 апреля 2010

Скорость более 100% - во многом зависит от задачи.

Более 100% - да, потому что своевременный компилятор знает ваш процессор, и я сомневаюсь, что вы на самом деле оптимизируете для своей аппаратной платформы;)

Нет SSE - это проблема, если вы выполняете матричные операции.

Для некоторых вещей с тоннами массивов (манипулирование изображениями) Тесты массивов убивают вас, но указатели работают (т.е. небезопасный код), поскольку они обходят это.

Относительно таких вещей, как проверка переполнения, будьте осторожны. Как в: в C ++ у вас то же самое возможно. Если вам нужна проверка переполнения, проблемы с производительностью нет;)

Я лично не стал бы беспокоиться о C ++ в большинстве случаев. Частично да, особенно если вы можете воспользоваться SSE:

Итак, в конце концов многое зависит от ПРИРОДЫ, если ваши расчеты.

...