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

Цитата Black_Dragon @ 04.09.20, 09:34

3) Всякие ООП тоже имеют накладные расходы....

Вот это спорно. По крайней мере если как альтернативу рассматривать плюсы.

Цитата OpenGL @ 04.09.20, 09:49

Вот это спорно

if (pointer != nullptr) - уже накладные расходы, а в ООП тоже будут доп проверки, вычисления. Откуда узнать, какую виртуальную функцию вызвать или это лишний переход, доступ сделать для этого? ООП за бесплатные такты процессора не реализуем. Ну может быть типа простой вариант, когда ты тупо наследуешь...

Просто, что мы рассматриваем. Одно дело, когда это ОС или жесткий реалтайм, тут борьба за быстродействие до тактов и лишних инструкций. Имхо.

В других языках может быть и по другому, но конкретно в Плюсах ООП бесплатен. Объектная модель такова, что написанные руками аналоги будут точно такими же. К примеру виртуальные методы представлены просто указателями на функции, и если переписать полиморфизм на C, получится то же самое.

Добавлено 04.09.20, 10:49

Цитата

Подскажите, как здесь найти список своих тем?

Попробуй ткнуть в «Профиль» под своим ником, зайти в профиль и найти что-то вроде «темы этого участника».

Цитата Black_Dragon @ 04.09.20, 10:24

if (pointer != nullptr) - уже накладные расходы, а в ООП тоже будут доп проверки, вычисления.

Я не понимаю, о каких накладных расходах и дополнительных проверках идёт речь. Если тебе надо проверять указатель на nullptr в плюсах, то надо делать это и в си. Если в программе на си это делать не надо (например, потому что он был проверен уровнем выше), то и в плюсах тебе ничто не мешает построить систему аналогично.

Цитата Black_Dragon @ 04.09.20, 10:24

Откуда узнать, какую виртуальную функцию вызвать или это лишний переход, доступ сделать для этого?

Он и в си будет делаться, если тебе нужна динамическая диспетчеризация, при помощи набора указателей на функции. Это ровно такая же VMT, только написанная руками.

Цитата Black_Dragon @ 04.09.20, 10:24

Просто, что мы рассматриваем. Одно дело, когда это ОС или жесткий реалтайм, тут борьба за быстродействие до тактов и лишних инструкций. Имхо.

Лично я о том, что не на всех языках у тебя будут получаться лишние инструкции в сравнении с Си. С++ - достаточно тонкая прослойка над ним. Если отключить RTTI и исключения (а ядро ОС, если бы писалось на плюсах, писалось бы без них), то вообще не будет никакого оверхеда. С растом чуть сложнее, в нём у тебя у объектов с деструктором есть drop flag, который обязательно проверяется при выходе из скопа, в нём для полиморфизма используются fat pointers, так что на язык без оверхеда в сравнении с си он всё-таки плохо тянет, но и в нём он настолько мал, что, вероятно, даже в ядре ОС это не будет особо важным.

Какой из языков сложнее - C или Rust?

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

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

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

1) Когда выгодно использовать ассемблер?
Когда ты на 100% уверен, что твой код наиболее эффективен.
Как правило, это относительно мелкие, продуманные участки программы.

2) Когда лучше использовать Си вместо ассемблера?
Когда ты пишешь достаточно объемные участки кода, либо неспецифичные.
Тогда разумно полагаться на компилятор и линкер. Ведь они умеют неплохо
оптимизировать код. Простой пример. Ты пересобираешь ядро, мир *nix
системы. Пересобираешь именно под себя. Ты вправе задать компилятору
флаг, который укажет оптимизировать код именно под нужное тебе семейство
процессоров. В результате некоторые участки кода будут задействовать те
фичи, которые есть в твоем процессоре, и которые будут более удачным
решением, нежели ты их заменишь командами общего назначения.

3) Когда лучше использовать С++ (или Rust) вместо Си?
Когда ты осознанно можешь выделить так называемые абстракции с нулевой
стоимостью ("zero-cost abstractions"). Иными словами, используя абстракции
более высокого уровня, которые дают удобство программисту, ты должен
осознавать, что это повлияет на качество (скорость, потребляемые ресурсы)
несущественно, либо вообще не повлияет. В принципе это можно отнести
и ко всем языкам, но в языках более высокого уровня проще напороться на
незаметные на первый взгляд оверхеды.

4) Когда лучше использовать Rust вместо С/C++?
Тут скорее дело вкусовщины, практики, наличия комьюнити, наличие цели.
Лично мне Rust очень симпатичен. Но, если подворачивается практическая
задача, да еще есть и ограничение по времени - я даже не заморачиваюсь,
и начинаю ее решать, используя С++. Все просто - наличие практики. Так
даже сотня написанных хэлоу-ворлдов на Rust не сделают этот язык твоим
рабочим инструментом. Только реальный/реальные проекты, только время.
Отсутствие уже устоявшихся стереотипов в разработке на других языках
возможно даже будет бонусом.

Все написанное выше - ИМХО. Ошибаться право имею!

Добавлено 06.09.20, 05:50

Цитата OpenGL @ 04.09.20, 11:04

С растом чуть сложнее, в нём у тебя у объектов с деструктором есть drop flag

В Rust, также как и в C++, ты можешь отдельные (наиболее требовательные) участки кода писать в стиле процедурного программирования, не так ли? Ну а если совсем уже невмоготу - использовать unsafe блоки. Тогда от оверхеда вообще можно избавится.

Цитата JoeUser @ 06.09.20, 05:45

Тогда от оверхеда вообще можно избавится.

Можно, но это неудобно, т.к. не будет ни трейтов (и динамическую диспетчеризацию придётся писать руками), ни деструкторов (и, если в си можно воспользоваться либо attribute cleanup, либо goto, то тут ничего из этого нет), и с массивами придётся работать исключительно через unsafe, чтобы проверок индексов не было. Проще уж на чистом си или плюсах тогда, если цель - ни грамма оверхеда.

Цитата OpenGL @ 06.09.20, 09:08

Можно, но это неудобно, т.к. не будет ни трейтов (и динамическую диспетчеризацию придётся писать руками), ни деструкторов (и, если в си можно воспользоваться либо attribute cleanup, либо goto, то тут ничего из этого нет), и с массивами придётся работать исключительно через unsafe, чтобы проверок индексов не было. Проще уж на чистом си или плюсах тогда, если цель - ни грамма оверхеда.

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

Цитата JoeUser @ 06.09.20, 10:20

Иными словами, писать с использованием того, что "есть" только в Си - так почему же в Си удобнее?

Потому что это такой уровень, что плюсы раста становятся ограничением. Из преимуществ будет разве что его enum, tuples, паттерн-матчинг и возможность что-нибудь деструктурировать с его помощью. Но зато всё остальное, что нужно на этом уровне, становится таким неудобным, что ну его нафиг
Впрочем, ты прав в том, что спуск на такой низкий уровень почти никогда не нужен. А даже если он будет нужен, то не факт, что там придётся городить какие-то сложные вещи, которые потребуют деструкторов. Но как камень в огород раста "а вот это на плюсах делается просто" сойдёт.

Вот так пришлось извращаться (не мне):
Инкремент элементов вектора

Сообщение отредактировано: Black_Dragon - 07.09.20, 04:31

Развивается ли стандарт Си в сторону роста производительности программ на этом языке в то время, как создаются языки наподобие Rust? Сам не шибко следил за стандартами,поэтому инетерсуюсь у вас, как более опытных товарищей.

Цитата Sunless @ 09.09.20, 03:01

Развивается ли стандарт Си в сторону роста производительности программ

Нет, не развивается в этом направлении. Си - знатный сторожил, и пережил уже многие взлеты/падения, тихонько наблюдая со стороны. А вот С++ в тренде движухи! Недавно я мельком зацепил тему концептов с++20, прикольная штука (если я не плыву - привет Раст). Ну а в плане именно быстродействия, тут не так! Быстродействие на фоне языка - определяется реализациями компиляторов. А быстродействие стандартной либы - определяется ее "доработками".

Нельзя так вот сказать, мол новый стандарт Си++ стал лучше языка-N (пусть того же Раста). Да, идут видоизменения, как в плане изменения (оптимизации) кода, так и в плане последующей сборки. Они идут. Они идут постоянно. Но не в языке дело, и слава Богу.

Простой пример.

Я начинал изучать язык Perl с 1998 года, там была версия 4. Потом перескочил на версию 5 вообще, как по маслу. Грамотные фиксы, лайт-модификации. Но потом вышел Perl 6. С конкретными видоизменениями, в том числе и синтаксиса. Оно мне надо? Оно мне не надо!

Так будет и с Си++, если "перегнут черту" - будут обосратушки. Но тут парни видимо трезвее, ИМНО.

С развивается в сторону общей оптимизации. А так C достаточно близко к аппаратной архитектуре, какими-то изменениями языка редко получается повысить его быстродействие. Из того, что помню, только добавление более быстрых вызовов функций с передачей параметров через регистры и встраивание функций.

Народ, обычно, заморачивается под ручное программирование векторных операций AVX
Умножение матриц: эффективная реализация шаг за шагом

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