Правильно ли я пишу на Rust?

тут мелькало мнение, что мы несём с собой умение кодить тем-то языком в другие, А вот они, как раз, требуют другого подхода ))) Или знаний ))) А так - benchmark на простую хрень.

Алгоритм довольно примитивный, реализовал теми средствами, что нашёл по книгам и SO.

требуют другого подхода

Собственно, потому и создал тему.

Собирал с оптимизацией?

Все обращения с проверкой. Вот и думай, почему так медленно.

t[i*n + j] = b[j*n + i]
c[i*n + j]
a[i*n + j]
a[i*n + j]

тут мелькало мнение, что мы несём с собой умение кодить тем-то языком в другие

Это описывается термином «Программируйте с использованием языка, а не языке».

Да, пробовал -O, потом нагуглил -C opt-level=3 -С target-cpu=native. Большой разницы не получилось.

Ты про плюсы или про ржавчину?

Ты тег с указал специально, чтоб потроллить?

Ээ, я о таком даже не подумал… Просто указал теги, которые связаны с темой. Хм, думаете лучше убрать?

Хм, думаете лучше убрать?

Поздно, эта тема уже набрала потенциал «Русские физики выбирают Slackware».

Видел на одной странице.

Не может быть, чтобы Rust был медленнее.

А замерялось, я так понимаю, на глаз? Бенчи где?

Видел тред без царя.

Добавил.

Это не бенчи. Ну и у вас c++ код не эквивалентен сишному, поэтому и медленнее.

Ну и сравнивать нужно без fast-math, ибо это фича компилятора, а не языка.

В расте проверка границ в векторе. Можешь ради интереса заменить квадратные скобки на at() в С++ и показать сколько получится

Ну или в расте get_unchecked+unsafe

Ну и сравнивать нужно без fast-math, ибо это фича компилятора

В Rust использовались аналогичные intrinsic.

Ну и у вас c++ код не эквивалентен сишному

Там рядом есть аналогичный. За вычетом restrict, которого нет в С++.

Характерно, что среди уже поступивших предложений от растосектантов есть советы типа «попробуй замедить код на C/C++», но пока нет совета, как ускорить код на Rust.

Я посоветовал или то, или то, на выбор. Если применить совет, то будет понятно что в этом основная причина - проверки границ

Ты опаздал, уже на V https://github.com/vlang/v переписывают, причём автоматически.

Уже несколько раз написали, что тормоза из-за bound checking. Просто ТС не понимает что сравнивает.

Заменил на get_unchecked, но получил ошибку «left-hand of expression not valid». Смотрел rustc --explain E0070, но не не понял в чём проблема.

get_unchecked возвращает ссылку, которую нужно разименовать.

Ты и есть автор этого язычка, что ли? Вроде ты один на ЛОРе пихаешь его во все дыры.

Вольдемар

Спасибо. Теперь получилось.

И какой результат?

Как же уродливо выглядит эта лапша из get_unchecked, fmul_fast, fadd_fast. Ну ничего, может со следующим язычком повезет.

Арсений

основная причина - проверки границ

Похоже на то. Замена [] на at() в варианте С++ дало такое же время как у Rust(71.75). Но вот наоборот что-то не совсем получается, я добавил get_unchecked, вариант Rust ускорился(41.40), но всё равно немного медленнее, чем С++. Может быть что-то ещё есть?

Для присвоения используете еще get_unchecked_mut? Или оставили скобки? Можно весь код пожалуйста

За раст не знаю, а vector<vector<double>> и malloc(N * N * sizeof(double)) - это разная раскладка по памяти. Код разный.

Что получается с

    for (i, c_row) in c.chunks_exact_mut(n).enumerate() {
        for (j, c_val) in c_row.iter_mut().enumerate() {
            let a_row = &a[i*n..i*n+n];
            let t_row = &t[j*n..j*n+n];
            *c_val = a_row.iter().zip(t_row.iter()).map(|(&a,&t)| unsafe{ fmul_fast(a,t) } ).sum();
        }
    }

Код на C отличается от кода на C++. Плюсовый код совсем не cache friendly. Но ведь это не важно, главное сишный код победил :)

Ну и сравнивать нужно без fast-math, ибо это фича компилятора, а не языка.

Лолшто? Ну давай не будем использовать O3 тоже этож тоже фича компилятора…

Но ведь это не важно, главное сишный код победил :)

Какие ещё голоса вы слышите у себя в голове?

Михаил

Выхлопы асма на первый взгляд без какой-то MMX/SSE магии у обоих. Но это в онлайн редактора, например плюсовому я не доверяю, локально мог добавить больше

https://godbolt.org/z/4hiFPd

https://play.rust-lang.org/?version=nightly&mode=release&edition=2018...

Ну и сравнивать нужно без fast-math, ибо это фича компилятора, а не языка.

Ибо очередной вакуумный недоязычек.

Даже пожалуй вот так:

    for (i, c_row) in c.chunks_exact_mut(n).enumerate() {
        for (j, c_val) in c_row.iter_mut().enumerate() {
            let a_row = &a[i*n..i*n+n];
            let t_row = &t[j*n..j*n+n];
            *c_val = a_row.iter().zip(t_row.iter()).fold(0.0, |sum, (&a,&t)| unsafe{ fadd_fast(fmul_fast(a,t), sum) } );
        }
    }

Сделай векторам reserve - глядишь и догонишь сишную реализацию…

-O3 уже нарушает стандарт?

У меня на машине C-шный вариант ТС-а с restrict дает 22s, а он же, но без restrict — уже 28s. Разница только в наличии/отсутствии этого ключевого слова.

Так что отсутствие в C++ restrict-а, плюс дополнительные поля в std::vector, которые дают другую раскладку данных в памяти, вероятно, и приводят к такой разнице между C и C++.

Лолшто? Ну давай не будем использовать O3 тоже этож тоже фича компилятора…

Да уж, растишники поражают своей непосредственностью и наивностью.

Без пруфца - не нарушает.

Сделай векторам reserve - глядишь и догонишь сишную реализацию…

Там сразу делается resize, так что reserve уже не имеет смысла.

Напомни, где там у Rust стандарт на nightly фичи.

Пруфца чего? fast-math нарушает IEEE 754.

дополнительные поля в std::vector, которые дают другую раскладку данных в памяти, вероятно, и приводят к такой разнице между C и C++.

Именно. В плюсовом тесте измеряется не производительность языка, а производительность и размер кеша.

Я про вектор который копируется как минимум. Там анон выше уже подметил. Хотя я чёт второй раз не нашёл. Может это жизофрения?

Ты где-то видел в этом коде серриализацию?

При чём тут серриализация? fast-math влияет на округление, внося погрешность.