C # проти C - велика різниця в продуктивності

Я знаходжу значні відмінності в продуктивності між подібним кодом у C anc C #.

Код С:

#include <stdio.h>
#include <time.h>
#include <math.h>

main()
{
    int i;
    double root;

    clock_t start = clock();
    for (i = 0 ; i <= 100000000; i++){
        root = sqrt(i);
    }
    printf("Time elapsed: %f\n", ((double)clock() - start) / CLOCKS_PER_SEC);   

}

А C # (консольний додаток):

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {
            DateTime startTime = DateTime.Now;
            double root;
            for (int i = 0; i <= 100000000; i++)
            {
                root = Math.Sqrt(i);
            }
            TimeSpan runTime = DateTime.Now - startTime;
            Console.WriteLine("Time elapsed: " + Convert.ToString(runTime.TotalMilliseconds/1000));
        }
    }
}

З наведеним вище кодом C # завершується за 0,328125 секунд (версія випуску), а C займає 11,14 секунди.

С компілюється до виконуваного файлу Windows за допомогою mingw.

Я завжди припускав, що C / C ++ були швидшими або принаймні порівнянними з C # .net. Що саме призводить до того, що C працює над 30 разів повільніше?

РЕДАГУВАТИ: Здається, оптимізатор C # видаляв корінь, оскільки він не використовувався. Я змінив кореневе призначення на root + = і роздрукував загальну суму в кінці. Я також скомпілював C, використовуючи cl.exe з прапором / O2, встановленим для максимальної швидкості.

Результати: 3,75 секунди для C 2,61 секунди для C #

C все ще займає більше часу, але це прийнятно

Оскільки ви ніколи не використовуєте 'root', компілятор, можливо, видаляв виклик для оптимізації вашого методу.

Ви можете спробувати накопичити значення квадратного кореня в акумуляторі, роздрукувати його в кінці методу і подивитися, що відбувається.

Редагувати: див . Відповідь Джалфа нижче

Ви повинні порівнювати збірки налагодження. Я щойно скомпілював ваш C-код і отримав

Time elapsed: 0.000000

Якщо ви не вмикаєте оптимізацію, будь-який порівняльний аналіз, який ви робите, абсолютно марний. (І якщо ви ввімкнете оптимізацію, цикл оптимізується. Таким чином, ваш код порівняльного аналізу теж має недоліки. Вам потрібно змусити його запустити цикл, як правило, підсумовуючи результат або подібне, і роздруковуючи його в кінці)

Здається, те, що ви вимірюєте, в основному полягає в тому, "який компілятор вставляє найбільші накладні витрати". І виявляється, відповідь C. Але це не говорить нам, яка програма найшвидша. Тому що коли вам потрібна швидкість, ви вмикаєте оптимізацію.

До речі, ви заощадите собі багато головного болю в довгостроковій перспективі, якщо відмовитеся від будь-якого поняття про те, що мови "швидші", ніж один одного. C # не більше має швидкість, ніж англійська.

У мові С є певні речі, які були б ефективними навіть у наївному не оптимізуючому компіляторі, а є й інші, які в значній мірі покладаються на компілятор, щоб оптимізувати все. І звичайно, те саме стосується C # або будь-якої іншої мови.

Швидкість виконання визначається:

• платформа, на якій ви працюєте (ОС, апаратне забезпечення, інше програмне забезпечення, що працює в системі)
• компілятор
• ваш вихідний код

Хороший компілятор C # дасть ефективний код. Поганий компілятор C генерує повільний код. А як щодо компілятора C, який створив код C #, який потім можна було б запустити через компілятор C #? Як швидко це бігло? Мови не мають швидкості. Ваш код робить.

Я буду коротко писати, це вже позначено як відповідь. C # має велику перевагу в тому, що має чітко визначену модель з плаваючою комою. Це якраз відповідає рідному режиму роботи набору інструкцій FPU та SSE на процесорах x86 та x64. Немає випадковості там. JITter компілює Math.Sqrt () за кількома вбудованими інструкціями.

Рідний C / C ++ обтяжений роками зворотної сумісності. Параметри / fp: точний, / fp: швидкий та / fp: строгі компіляції є найбільш видимими. Відповідно, він повинен викликати функцію ЕПТ, яка реалізує sqrt () і перевіряє вибрані параметри з плаваючою комою для коригування результату. Це повільно.

Я C ++ і розробник C #. Я розробляв програми C # з першої бета-версії .NET Framework і мав більше 20 років досвіду у розробці програм C ++. По-перше, код С # НІКОЛИ не буде швидшим, ніж додаток С ++, але я не буду довго обговорювати керований код, як він працює, рівень взаємодії, внутрішні елементи управління пам'яттю, систему динамічного типу та збирач сміття. Тим не менше, дозвольте продовжити, сказавши, що перелічені тут контрольні показники дають НЕПРАВИЛЬНІ результати.

Поясню: перше, що нам потрібно врахувати, це компілятор JIT для C # (.NET Framework 4). Тепер JIT виробляє власний код для центрального процесора, використовуючи різні алгоритми оптимізації (які, як правило, більш агресивні, ніж оптимізатор за замовчуванням C ++, який постачається з Visual Studio), і набір команд, що використовується компілятором .NET JIT, є більш точним відображенням фактичного процесора на машині, щоб можна було зробити певні заміни в машинному коді, щоб зменшити тактові цикли та покращити частоту потрапляння в кеш конвеєра процесора та провести подальші оптимізації гіперпотоків, такі як переупорядкування інструкцій та вдосконалення, пов'язані з прогнозуванням гілок.

Це означає, що якщо ви не скомпілюєте свою програму C ++, використовуючи правильні параметри для збірки RELEASE (а не збірки DEBUG), тоді ваша програма C ++ може працювати повільніше, ніж відповідна програма на базі C # або .NET. Вказуючи властивості проекту у вашому додатку C ++, переконайтеся, що ви ввімкнули "повну оптимізацію" та "віддайте перевагу швидкому коду". Якщо у вас 64-розрядна машина, ви ПОВИННІ вказати для генерації x64 як цільову платформу, інакше ваш код буде виконаний через підшар перетворення (WOW64), що істотно знизить продуктивність.

Після того, як ви виконаєте правильну оптимізацію в компіляторі, я отримую 0,72 секунди для програми C ++ та 1,16 секунди для програми C # (обидві у збірці випуску). Оскільки додаток C # є дуже простим і виділяє пам'ять, що використовується в циклі, у стеці, а не в купі, насправді він працює набагато краще, ніж реальний додаток, що бере участь у об'єктах, важких обчисленнях і з більшими наборами даних. Отже, наведені цифри - це оптимістичні цифри, упереджені до C # та .NET framework. Навіть маючи таке упередження, програма C ++ виконується трохи більше половини часу, ніж еквівалентна програма C #. Майте на увазі, що компілятор Microsoft C ++, який я використовував, не мав правильної оптимізації конвеєра та гіперпотоків (за допомогою WinDBG для перегляду інструкцій з монтажу).

Тепер, якщо ми використовуємо компілятор Intel (який, до речі, є галузевим секретом для створення високопродуктивних додатків на процесорах AMD / Intel), той самий код виконується за .54 секунди для виконуваного файлу C ++ проти .72 секунди за допомогою Microsoft Visual Studio 2010 Тож, врешті-решт, кінцеві результати становлять 0,5 секунди для С ++ та 1,16 секунди для С #. Отже, створення коду компілятором .NET JIT займає в 214% разів більше часу, ніж виконуваний файл C ++. Велику частину часу, проведеного за .54 секунди, отримували час від системи, а не в самому циклі!

У статистиці також бракує часу запуску та очищення, які не включені в терміни. Програми C # зазвичай витрачають на запуск та припинення набагато більше часу, ніж програми C ++. Причина цього складна і пов’язана з процедурами перевірки коду виконання .NET та підсистемою управління пам’яттю, яка виконує багато робіт на початку (а отже, і в кінці) програми з оптимізації розподілу пам’яті та сміття колектор.

Вимірюючи продуктивність C ++ та .NET IL, важливо поглянути на код збірки, щоб переконатися, що ВСІ розрахунки є. Я виявив, що без введення додаткового коду в C # більшість коду у прикладах вище фактично були видалені з двійкового файлу. Це було також у випадку з C ++, коли ви використовували більш агресивний оптимізатор, такий як той, що постачається з компілятором Intel C ++. Результати, які я надав вище, на 100% правильні та підтверджені на рівні складання.

Основна проблема багатьох форумів в Інтернеті полягає в тому, що багато новачків слухають маркетингову пропаганду Microsoft, не розуміючи технології, і роблять неправдиві твердження, що C # швидший за C ++. Твердження полягає в тому, що теоретично C # працює швидше, ніж C ++, оскільки компілятор JIT може оптимізувати код для процесора. Проблема цієї теорії полягає в тому, що в середовищі .NET існує багато сантехніки, яка сповільнює продуктивність; сантехніка, якої не існує в додатку C ++. Крім того, досвідчений розробник знатиме правильний компілятор, який використовуватиметься для даної платформи, і використовувати відповідні прапори під час компіляції програми. На платформах Linux або з відкритим кодом це не проблема, оскільки ви можете розповсюджувати своє джерело та створювати сценарії встановлення, які компілюють код, використовуючи відповідну оптимізацію. На вікнах або платформі із закритим кодом вам доведеться поширювати кілька виконуваних файлів, кожен із яких має певні оптимізації. Бінарні файли Windows, які будуть розгорнуті, базуються на центральному процесорі, виявленому програмою встановлення msi (за допомогою спеціальних дій).

моє перше здогадування - це оптимізація компілятора, оскільки ви ніколи не використовуєте root. Ви просто призначаєте його, а потім перезаписуєте знову і знову.

Редагувати: блін, бити на 9 секунд!

Щоб побачити, чи оптимізовано цикл, спробуйте змінити код на

root += Math.Sqrt(i);

ans аналогічно в коді C, а потім надрукуйте значення root поза циклом.

Можливо, компілятор c # помічає, що ви ніде не використовуєте root, тому він просто пропускає весь цикл for. :)

Це може бути не так, але я підозрюю, що б не була причина, це залежить від реалізації компілятора. Спробуйте скомпілювати програму C із компілятором Microsoft (cl.exe, доступний як частина win32 sdk) з оптимізацією та режимом випуску. Б'юся об заклад, ви побачите покращення в порівнянні з іншим компілятором.

EDIT: Я не думаю, що компілятор може просто оптимізувати цикл for, оскільки він повинен знати, що Math.Sqrt () не має побічних ефектів.

Незалежно від часу різниця. може бути, що "минулий час" недійсний. Він буде дійсним лише у тому випадку, якщо ви гарантуєте, що обидві програми працюють за однакових умов.

Можливо, вам слід спробувати виграти. еквівалентно $ / usr / bin / time my_cprog; / usr / bin / time my_csprog

Я склав (на основі вашого коду) ще два порівнянні тести на C та C #. Ці двоє записують менший масив, використовуючи модуль-оператор для індексації (це додає трохи накладних витрат, але привіт, ми намагаємось порівняти продуктивність [на сирому рівні]).

Код C:

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <math.h>

void main()
{
    int count = (int)1e8;
    int subcount = 1000;
    double* roots = (double*)malloc(sizeof(double) * subcount);
    clock_t start = clock();
    for (int i = 0 ; i < count; i++)
    {
        roots[i % subcount] = sqrt((double)i);
    }
    clock_t end = clock();
    double length = ((double)end - start) / CLOCKS_PER_SEC;
    printf("Time elapsed: %f\n", length);
}

У C #:

using System;

namespace CsPerfTest
{
    class Program
    {
        static void Main(string[] args)
        {
            int count = (int)1e8;
            int subcount = 1000;
            double[] roots = new double[subcount];
            DateTime startTime = DateTime.Now;
            for (int i = 0; i < count; i++)
            {
                roots[i % subcount] = Math.Sqrt(i);
            }
            TimeSpan runTime = DateTime.Now - startTime;
            Console.WriteLine("Time elapsed: " + Convert.ToString(runTime.TotalMilliseconds / 1000));
        }
    }
}

Ці тести записують дані в масив (тому середовищі виконання .NET не слід дозволяти відбирати sqrt op), хоча масив значно менший (не хотів використовувати надмірну пам'ять). Я скомпілював їх у конфігурації випуску та запустив зсередини вікна консолі (замість запуску через VS).

На моєму комп'ютері програма C # варіюється від 6,2 до 6,9 секунди, тоді як версія C варіюється від 6,9 до 7,1.

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

Не потрібно освічених здогадок.

Іншим фактором, який може бути проблемою тут, є те, що компілятор C компілюється до загального власного коду для цільового сімейства процесорів, тоді як MSIL, що генерується під час компіляції коду C #, потім компілюється JIT для націлювання на точний процесор, який ви маєте в комплекті з будь-яким оптимізації, які можуть бути можливими. Отже, власний код, згенерований із C #, може бути значно швидшим, ніж C.

Мені здається, це не має нічого спільного з самими мовами, скоріше це стосується різних реалізацій функції квадратного кореня.

Насправді, хлопці, цикл НЕ оптимізується. Я склав код Джона і вивчив отриманий файл .exe. Кишки петлі такі:

 IL_0005:  stloc.0
 IL_0006:  ldc.i4.0
 IL_0007:  stloc.1
 IL_0008:  br.s       IL_0016
 IL_000a:  ldloc.1
 IL_000b:  conv.r8
 IL_000c:  call       float64 [mscorlib]System.Math::Sqrt(float64)
 IL_0011:  pop
 IL_0012:  ldloc.1
 IL_0013:  ldc.i4.1
 IL_0014:  add
 IL_0015:  stloc.1
 IL_0016:  ldloc.1
 IL_0017:  ldc.i4     0x5f5e100
 IL_001c:  ble.s      IL_000a

Хіба що час виконання розумний, щоб зрозуміти, що цикл нічого не робить і пропускає його?

Редагувати: Зміна C # на:

 static void Main(string[] args)
 {
      DateTime startTime = DateTime.Now;
      double root = 0.0;
      for (int i = 0; i <= 100000000; i++)
      {
           root += Math.Sqrt(i);
      }
      System.Console.WriteLine(root);
      TimeSpan runTime = DateTime.Now - startTime;
      Console.WriteLine("Time elapsed: " +
          Convert.ToString(runTime.TotalMilliseconds / 1000));
 }

Результати за час, що минув (на моїй машині) переходив від 0,047 до 2,17. Але чи це лише накладні витрати на додавання 100 мільйонів операторів додавання?