LINUX.ORG.RU

Rust быстрее С++? Аргументы.

 ,


2

9

Немного поизучал Rust, и решил собрать все преимущества заявляемые адептами.

  1. Из-за знания компилятором, что & mut - это уникальная ссылка, то параметры функции не будут алиаситься с обычной ссылкой:
fn f(s: & mut str, s2: & str) -> type // s и s2 указывают на разную память, 100% компилятор знает об этом
// в стандарте С++ нет restrict
  1. Возможно, большие возможности в compile-time чем у С++, в частности упоминается возможность прочитать файл во время компиляции:
const IMAGE: &[u8] = include_bytes!("/path/some_file.png");
  1. Map в rust реализован с помощью алгоритма BTreeMap, а в С++ - std::map красно-чёрное дерево, BTreeMap быстрее…

  2. HashMap в rust - открытая адресация, в С++ std::unordered_map - метод цепочек, открытая адресация быстрее…

  3. В rust нет объектов, везде используется memcpy, а тот же resize вектора делается через realloc, бысрее чем move конструкторы в С++

помогите дополнить список.

возможно, в будущем прочтём в блоге у царя, где он помножит на ноль все эти преимущества.

★★★★★

Возможно, большие возможности в compile-time чем у С++, в частности упоминается возможность прочитать файл во время компиляции:

в С++ тоже можно прочитать файл во время компиляции: #include "/path/some_file.png";

Int64 ★★★
()
  1. Да
  2. std::embed уже скоро
  3. Нет, b tree быстрее только при очень дорогом доступе к памяти.
  4. Больший расход памяти, трудное разрешение коллизий самого хэша
  5. extended allocator из boost
CatsCantFly
()
Ответ на: комментарий от anonymous

сейчас прийдет Царь и как всегда обосрётся, потом придут модераторы и потрут его высеры.

fxd4tgj

WatchCat ★★★★★
()
Ответ на: комментарий от CatsCantFly

спасибо за 5, не знал про extended allocator из boost

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

А то на лоре почти всегда пишут, что раст лучше, потому что лучше, или типа таких ссылок: Компилируемый WebDevelopment (комментарий)

http://cliffle.com/blog/prefer-rust/#false-reasons-to-use-c-c

Так вот я нашёл хоть какие-то настоящие аргументы за раст…

fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от Int64

ну это с текстовыми файлами

не просто с текстовыми файлами, а с файлами на языке который потом пойдёт на вход компилятору.

Потому что сишный препроцессор тупо работает с текстом.

WatchCat ★★★★★
()
  1. Да, но не включено пока из-за бага в llvm (поправьте есть устарела инфа).
  2. Ну такое.
  3. Ну такое.
  4. Ну такое.
  5. При чём тут объекты и memcpy?

В общем это не преимущества - а дичь какая-то. До преимуществ вы так и не дошли.

RazrFalcon ★★★★★
()

стандарте С++ нет restrict

Если очень надо, можно навелосипедить. Например, самый простой случай:

void foobarize(Object& lhs, Object& rhs) {
  if (&lhs == &rhs)
    __builtin_unreachable();
  // ...
}

И теперь компилятор всунет UB где нужно для оптимизации.

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)

Пожалейте полоумного, куда ему столько еды.

Virtuos86 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Мой список не про синтаксис языка, не про всякий бороу чекер или патерн матчинг, он про это:

https://habr.com/ru/post/476972/#comment_20920542

http://cliffle.com/blog/prefer-rust/#false-reasons-to-use-c-c

То есть вместо безосновательного:

rust faster than — compiled C/C++ today.

Я попытался найти особенности из-за которых по мнению программистов на раст, раст может быть быстрее чем С++.

fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от fsb4000

rust faster than — compiled C/C++ today.

Вырвали из контекста. Не стыдно?

Ну и имхо нет, не быстрее, а такой же. Там можно много рассуждать об тонкостях, но на типичном коде разницы не будет и быть не может.

RazrFalcon ★★★★★
()

быстрее тормозит разве что.

mos ★★☆☆☆
()

в частности упоминается возможность прочитать файл во время компиляции

incbin, objcopy, bin2obj – это задача тулинга, а не языка

HashMap в rust - открытая адресация, в С++ std::unordered_map - метод цепочек, открытая адресация быстрее…

Было бы хорошо, если бы ты еще понимал, почему сделали именно так.

kawaii_neko ★★★★
()

Rust быстрее С++?

Если говорить про то, насколько язык сует палки в колеса и не дает оптимизировать, то и Rust и С++ дают опускаться до самых низов. Есть особенности, но решаемые. А если говорить про типичный код, то этого самого типичного кода на Rust еще нет. Есть много фанатов, каждый их которых велосипедит так, как ему кажется лучше, и так как ему сходу видно. И это не всегда хорошо сказывается на производительности. Да и сам язык еще развивается, как впрочем и С++.

Serral
()

Доколе

это всё будет продолжатся? В чём вообще фича сравнивать даже не конерктную реализацию компилятора на конктреной платформе а язык и говорить про скорость и эффективность ВНИМАНИЕ стандартной библиотеки? И вот особенно вот эта часть про «BTreeMap» быстрее, т.е. разработчики стандартной библиотеки сидят и рассуждают : «Вот тут мы выберем этот алгоритм, он медленее работает, но мы всё равно его выберем, что бы хоть гдето rust дать шанс…», комон, если бы всё мерилось скоростью работы алгоритма, то везде бы использовали QSort как самый эффективный, но в томже ядре линукс накой то хрен сортировка слиянием…

Было бы круто если бы ты запил сравнения результатов итоговой кодегенерации, на разных платформах arm, x86, powerpc и тд. Сравнить используемые методики оптимизации, какие защиты стека, вызовов втыкаются, насколько эффективно, для максимальной объективности сравнить хотябы самые известные компиляторы g++, clang, msvc.

sparks ★★★
()
Последнее исправление: sparks (всего исправлений: 1)
Ответ на: комментарий от Serral

Есть много фанатов, каждый их которых велосипедит так, как ему кажется лучше, и так как ему сходу видно.

Это вы ещё как пишут на С++ не видели.

O02eg ★★★★★
()
Ответ на: Доколе от sparks

Можно и посравнивать, только что…

А вообще я научился в rust ассемблерный вывод создавать:

rustc -C opt-level=3  -C target-cpu=native --emit=asm -Cllvm-args=--x86-asm-syntax=intel -C linker-plugin-lto main.rs
rustfilt -i main.s -o main.asm

-Cllvm-args=–x86-asm-syntax=intel по желанию конечно…

fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от fsb4000

я ж написал что:

Сравнить используемые методики оптимизации, какие защиты стека, вызовов втыкаются, насколько эффективно, для максимальной объективности сравнить хотябы самые известные компиляторы g++, clang, msvc.

sparks ★★★
()
Ответ на: комментарий от O02eg

Это вы ещё как пишут на С++ не видели.

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

Serral
()

C++, конечно, быстрее, если ты захочешь перенести одну мапу в другую по перемещающему конструктору, потому что в некоторых основных реализациях этот конструктор не объявлен как noexcept. Умный компилятор C++, видя что нет гарантии того, что не может быть кинуто исключений, специально создаст копию мапы на тот случай, а вдруг во время перемещения будет все же кинуто исключение, а потом компилятор уже переместит копию исходной мапы на новое место. А по другому никак, потому что если бы исключение возникло во время перемещения, то старый объект мог бы остаться в невалидном состоянии, и тогда всей приложухе пришел бы серый песец. C++ же не может как Rust просто позволить себе не вызывать деструктор для старого перемещенного объекта, потому что низзя - так надо! Итого, при «перемещении» мапы создаем копию мапы, а потом уже перемещаем.

Конечно, C++ быстрее, чем Rust, хотя и работает программа дольше, потому что медленный Rust при перемещении мапы просто побитово скопирует вмиг всего лишь небольшой хендл, это несколько байтов, но зато Rust ох какой тормозной!

P.S. Просто наболело.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 2)
Ответ на: комментарий от dave

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

Версия и название компилятора? Наверняка это что-то древнее, где поддержки даже С++11 еще толком не было.

Serral
()
Ответ на: комментарий от filosofia

Описаны:

Вот про хеш: https://en.cppreference.com/w/cpp/container/unordered_map/bucket

https://en.cppreference.com/w/cpp/container/unordered_map/bucket_count

https://en.cppreference.com/w/cpp/container/unordered_map/bucket_size

То есть мы явно можем вызвать этот список корзин-цепочек.

А вот про map:

https://stackoverflow.com/questions/4343220/does-insertion-to-stl-map-invalidate-other-existing-iterator/4343287#4343287

The insert members shall not affect the validity of iterators and references to the container, and the erase members shall invalidate only iterators and references to the erased elements.

соотвественно BTreeMap отпадает из-за этого требования…

fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

соотвественно BTreeMap отпадает из-за этого требования…

К слову о стандартных реализациях и требованиях. Вот типичная задача для мапы:

https://www.spoj.com/problems/HOMO/

Мое решение там на первом месте. На стандартной std::unordered_map. Хочешь доказать, что стандарьная библиотека Rust быстрее - сделай решение, запости и проверь.

Serral
()

Даже если бы Руст был чуточку быстрее разве в этом суть. Неужели не противно на этом мерзком непонятном синтаксисе писать. Неужели так лениво и не любимо занятие программированием что готовы искать что угодно лишь бы не стрелять себя в ногу не быть внимательными к деталям реализации своего же алгоритма. Мне вот за милое дело на Си++ писать, и нафиг не сдалось учить новый синтаксис какого-то очередного убийцы С++. И да, для больших и сложных проектов нет ничего лучше ооп а не какой-то функциональщины с какими-то типажами.

bonta ★★★★★
()

Ну да, есть некоторые фичи, которые позволяют сделать быстрее. Как и у С++. Например в Rust нужно поприседать чтобы доказать компилятору что в два get_mut по двум гарантировано разным ключам - это ок.

Я думаю аргумент про «быстрее» когда вопрос в поправках на ветер - это уход в сторону.

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

vertexua ★★★★★
()
Ответ на: комментарий от sparks

Вы же в курсе, что у clang и rustc общий бекенд? Что там сравнивать?

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Ну открываем список Working Groups

https://github.com/rust-lang/rust/issues/54445

Что угодно есть, GUI нет. Хотите - создавайте. Но отсутствие намекает на приоритеты. Если они с прицелом на язык который допустим должен войти в мейстрим где-то лет через 3-5, то десктопный гуй будет еще менее нужен.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Так никто не сможет.

  1. Это гигантская работа.
  2. Никто не может решить что им нужно: retained mode, immediate mode или reactive. Я склоняюсь к последнему, но слабо себе представляю как это будет выглядеть на чистом расте. Аналог Qt+QML/Swift+SwiftUI выглядит самым логичным решением, но пилить я его конечно же не буду.
RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

А у кого хорошо

Flutter, Swift UI. Без расширения синтаксиса ни у кого. Вангую, что и хипстеры из введут @state variables или что-то подобное

Deleted
()
Ответ на: комментарий от vertexua

Например в Rust нужно поприседать чтобы доказать компилятору что в два get_mut по двум гарантировано разным ключам - это ок.

Ну да, нужно знать библиотечную функцию, я про неё уже прочитал.

https://doc.rust-lang.org/std/primitive.slice.html#method.split_at_mut

Или ты про то как её в ручную реализовать?

fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Обмазатбся макросами - такое. Тем более там GTK+, а значит автоматом ненужно.

Нужен отдельный язык для описания интерфейса.

RazrFalcon ★★★★★
()
Ответ на: комментарий от fsb4000

Но такое не проворачивается на HashMap. Для вектора - да. За счёт ordering.

vertexua ★★★★★
()
Ответ на: комментарий от fsb4000

Модераторы шалят, верну сообщение по поводу твоего цивилизованного ответа нашему форумному душевнобольному. Наивность? Незнание?

Чувак мыслит категориями «что кому принадлежит». Код принадлежит, типо атрибут славы и признания. И все в лагерях, со штампом в паспорте и доспехах. Подумай какая сама эта идея по себе поехавшая.

Код естественно опенсорс, его пишут чтобы работало, а не чтобы поставить свой флаг - вот моё, вот их, вот за вот это меня хвалите.

Логика нашего травмированного ребенка (скорее всего травма непризнанного гения) такова, unsafe - «принадлежит» С++. То есть если ты ним пользуешься что счётчик монеток в голове царя добавляется ему в аккаунт и убавляется у тебя.

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

Это просто как бы религиозная война где все должны забирать у друг друга Иерусалим и кричать «мое - не твое». Это клиника.

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

Я так понимаю, активно пилится замена LLVM-бэкенда на cranelift, написанный на русте. Вместе с новым IR. Забавно будет посмотреть как царь будет тявкать, когда исчезнет коронный аргумент «укррраали»

Deleted
()
Ответ на: комментарий от RazrFalcon

Обмазатбся макросами - такое.

А чем плохо?
Сделать дсл на растовских макросах вполне себе решение, имхо.

WatchCat ★★★★★
()
Ответ на: комментарий от Deleted

Ему ничего не мешает это орать даже в палате обвешаной подушками в смирииельной рубашке.

Дальше скажет что идею украли.

vertexua ★★★★★
()
Ответ на: комментарий от RazrFalcon

Альфа. Не существует на десктопе

Никакого десктопа нет! Тебя поимела пропаданда! ;) Как нет и «мобильной платформы». Есть разрозненные ОС с разными GUI-фреймворками. И еще есть Qt. Но это уже совсем другая история

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.