Производительность Си в сравнении с Rust

Добрый вечер!
Почему Си с компилятором GCC уступает в производительности Rust? Объясните доходчиво, пожалуйста. Источник тут https://benchmarksgame-team.pages.debian.ne...stest/rust.html
Спасибо.

1) Если смотреть тесты, то в половине случаев.
2) И надо все делать самим.
3) Для теста, мне кажется, надо более длительные тесты...

Под линуксом наверно стабильно, но один из тестов на С++ под форточками (рабочий комп) у меня был приличный разброс результатов
0.0167395s
0.0106386s
0.0140187s

Сообщение отредактировано: Black_Dragon - 03.09.20, 03:49

Цитата Sunless @ 02.09.20, 19:43

Почему Си с компилятором GCC уступает в производительности Rust? Объясните доходчиво, пожалуйста. Источник тут https://benchmarksgame-team.pages.debian.ne...stest/rust.html

Потому что это говнотесты, там нет сравнения Си и Rust, там больше похоже на какую то олимпиадку студентов на разных языках. В одном языке значит они юзают один алгоритм, в другом языке другой алгоритм. Т.е. по сути просто сравниваются разные алгоритмы на разных языках. Так себе сравнение быстродействия языков. Больше похоже на сравнение программеров.
Даже судя по написанному в комментарии в шапке каждого исходника, можно сделать вывод что писали тесты разные люди. На Си писал Джон, на Rust писал Alex, Murtaza, Steven, etc.


Добавлено 03.09.20, 06:01
https://benchmarksgame-team.pages.debian.ne...ide-rust-7.html
https://benchmarksgame-team.pages.debian.ne...tide-gcc-1.html

Видно же что совершенно разные алгоритмы.

Или вот:
https://benchmarksgame-team.pages.debian.ne...rot-rust-7.html
https://benchmarksgame-team.pages.debian.ne...brot-gcc-6.html

Rust:

pub fn mbrot8(out: &mut u8, cr: &Vecf64, ci: Constf64) {
    let mut zr = Arr::splat(0f64);
    let mut zi = Arr::splat(0f64);
    let mut tr = Arr::splat(0f64);
    let mut ti = Arr::splat(0f64);
    let mut absz = Arr::splat(0f64);
 
    for _ in 0..MAX_ITER / 5 {
        for _ in 0..5 {
            zi = (zr + zr) * zi + ci;
            zr = tr - ti + cr;
            tr = zr * zr;
            ti = zi * zi;
        }
 
        absz = tr + ti;
        if absz.iter().all(|&t| t > 4.) {
            return;
        }
    }
 
    *out = absz.iter().enumerate().fold(0, |accu, (i, &t)| {
        accu | if t <= 4. { 0x80 >> i } else { 0 }
    });
}

Си

inline void calcSum(__m128d *r, __m128d *i, __m128d *sum, __m128d *init_r, __m128d init_i)
{
    for(long pair=0; pair<4; pair++)
    {
        __m128d r2 = r[pair] * r[pair];
        __m128d i2 = i[pair] * i[pair];
        __m128d ri = r[pair] * i[pair];
 
        sum[pair] = r2 + i2;
 
        r[pair]=r2 - i2 + init_r[pair];
        i[pair]=ri + ri + init_i;
    }
}
 
inline unsigned long mand8(__m128d *init_r, __m128d init_i)
{
    __m128d r[4], i[4], sum[4];
    for(long pair=0; pair<4; pair++)
    {
        r[pair]=init_r[pair];
        i[pair]=init_i;
    }
 
    unsigned long pix8 = 0xff;
 
    for (long j = 0; j < 6; j++)
    {
        for(long k=0; k<8; k++)
            calcSum(r, i, sum, init_r, init_i);
 
        if (vec_nle(sum, 4.0))
        {
            pix8 = 0x00;
            break;
        }
    }
    if (pix8)
    {
        calcSum(r, i, sum, init_r, init_i);
        calcSum(r, i, sum, init_r, init_i);
        clrPixels_nle(sum, 4.0, &pix8);
    }
 
    return pix8;
}

В первом исходнике на Rust 2 вложенных цикла, во втором на Си - 3 вложенных цикла. Что с чем тут сравнивается?
Я вообще не понимаю что там с чем сравниватся, и что это за херотень.

Сообщение отредактировано: Wound - 03.09.20, 06:05

Цитата Sunless @ 02.09.20, 19:43

Почему Си с компилятором GCC уступает в производительности Rust? Объясните доходчиво, пожалуйста. Источник тут https://benchmarksgame-team.pages.debian.ne...stest/rust.html

Да тем тесты дебильные. Например, в pi-digits в расте они подключают gmp и пишут safe обёртку над ним. Что они хотели этим протестировать - мне неведомо.
А если абстрагироваться от этих конкретных тестов, то исходник на расте предоставляет компилятору больше информации и, соответственно, у него больше возможностей для оптимизации. Например, если у тебя в расте есть mut ссылка, то компилятор будет знать, что никто другой на неё не указывает, и будет генерировать код, который бы сгенерировал сишный код с указателями, объявленными как restrict. Также наверняка не последнюю роль оптимизации llvm играют, т.е. если взять вместо gcc clang, то разрыв будет меньше при одинаковых алгоритмах.

Цитата Wound @ 03.09.20, 05:56

Больше похоже на сравнение программеров

Тоже в исходниках "запутался".
Получается так, есть какая-то обобщенная задача, и кто из программеров разработает алгоритм и напишет быструю реализацию.

То есть языка производительнее Си с человеческим синтаксисом не может быть, там же очень простой синтаксис для анализа?

Цитата Sunless @ 03.09.20, 08:48

То есть языка производительнее Си с человеческим синтаксисом не может быть

Может. Си++.

Почему он производительнее? У него же сложнее синтаксис. Улучшают ли авторы стандартов С/С++ производительность языков?

Sunless
Процессор не обрабатывает языки высокого уровня.
Компиляторы "конвертируют" язык в инструкции процессора.
И для большинства разных языков, выражение a=b+1 будет кодироваться одинаково.
Но оптимизация и другие особенности зависит от компилятора.

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

Black_Dragon, истину глаголишь!

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

Есть ли универсальный способ, чтобы проверить, какой из компиляторов сгенерировал более оптимальную программу? Может, даже есть готовое сравнение C,C++,Rust, на которое вы бы посоветовали обратить внимание?

Цитата Sunless @ 03.09.20, 15:58

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

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

JoeUser
Знаем.... Межплатформенные языки, Java, например, если память не подводит.

Qraizer
Было у меня такое. Любитель оптимизировать расчеты просто, так и через OpenMP.
В одной программе были несколько разных тестовых кусков кода (оптимизировал и тестил), и сравнивал i7-4770 (ddr3) и i5-6500 (ddr4) (рабочий и домашний). Часть кода была быстрее на одном проце, другая часть на другом.

Всё-таки не совсем понятно, почему ядра ОС и серверы пишут на Ассемблере и Си и не переписывают на другие языки, если осталььные языки их могут обогнать.
P.S.
Подскажите, как здесь найти список своих тем?

Сообщение отредактировано: Sunless - 04.09.20, 09:04

Цитата Sunless @ 04.09.20, 09:04

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

1) Вы знаете сколько кода в ОС-ах? И как вы себе представляете "переписать", а если еще что-то новое, быстрое появиться, опять переписывать?
2) Другие языки не быстрее. Языки высокого уровня (могут) внедряют разные защиты, например, проверка границ массива, а это накладные расходы...
3) Всякие ООП тоже имеют накладные расходы....

ОС-ы пишут очень профессиональные программисты, и весь контроль за работой кода и логики на них, а не на авторах библиотек или компилятора.
Например, перед тем как работать с указателем, надо проверить его на валидность, чтоб не получить крах программы по доступам.
Но в логике твой программы 100% дойдя до этого места указатель будет точно валиден и тебе не нужен код, где он будет лишний раз проверяться. По этому тебе не нужна библиотека, в которой есть лишние проверки, так как тебе нужно быстродействие.