Почему программы на с++ тормозят :)

Только вот полиморфизм расширяем,а тупой свитч — нет

За абстракции надо платить

Что это за хрень:

8 * >sizeof(fLastMoveToIndex)

а куда торопится-то?

Это да.
И работа всегда гарантировано есть.

Склонен быть согласным с оратором: я очень скептически отношусь ко многим новомодным фичам (привет «лямбдам»), по крайней мере пока не увижу в какой asm это разворачивается в конкретном случае. Но должен заметить что такой extreme нужен только на hot-paths, в противном случае maintainability и extensibility важнее.

PS. Смотрел с телефона и кода там не разобрать - а actual сорсы где-то есть поиграться?

Хороший видос. Хорошо выявляет тех лошков, кого нельзя подпускать к системному программированию и к C++. Т.е. если ты на это очковтирательство повелся и не видишь очевидного развода, то ты и есть этот лошок. А если ещё и сеньор какой-нибудь, то от тебя вообще надо держаться подальше. А таких, как не удивительно, много в нашей индустрии. На r/programming этот видосик получил более 1000 лайков. Но на r/cpp на него вообще не обратили внимание (там люди посерьезнее).

Примечательно, что чувак комметарии на видос отключил. Ему там, наверное, популярно объяснили в чём он не прав, и ему это не понравилось.

и не видишь очевидного развода

В чём развод? Понятно что там тест синтетический, но Вы будете спорить что indirect jumps (virtuals) are much slower than the regular branches? В отстальном там скорее всего referential locality выстреливает.

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

Эвона как. Тему не разовьёте, а то прям заинтриговали?

Re: Почему программы на с++ тормозят :)

Заменяем крутой полиморфизм на тупой свитч - получаем 1.5 ускорения

Нет, программы тормозят не поэтому.

А вот еще «прекрасное» из исходников GNU grep:

  out_file = (filename_option == 0 && num_operands <= 1
              ? - (directories == RECURSE_DIRECTORIES)
              : 0 <= filename_option);

Продакшен-код, так сказать.

получаем 1.5 ускорения

поджопника?

Это ошибка цитирования. Там так:

int fLastMoveToIndex = 5; // любое число
fLastMoveToIndex ^= ~fLastMoveToIndex >> (8 * sizeof(fLastMoveToIndex) - 1);

КО сообщает, что «красивое» погромирование предполагает определённую степень «обобщённости», в вечной погоне за меньше-кода-больше-функционала-меньше-правок, а «тупой свитч» вхардкоженность, но с невыполнением вышеозначенных целей.

И почему должно удивлять, что второе «быстрее» первого, не ясно.

И почему должно удивлять, что второе «быстрее» первого, не ясно.

Скажите, только честно - когда Вы в последний раз на disasm смотрели?

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

При том что сам свитч вовсе не бесплатный, это либо индексация таблицы, либо куча арифметики с условными переходами, производительность которых зависит от предсказания ветвлений несколько раз подряд (в отличие от vtable).

А в целом это попытка экономии на спичках. Грамотная оптимизация требует анализа архитектуры проекта и анализа алгоритмов на предмет O().

Программисты на высокоуровневых языках часто либо в силу низкой квалификации, либо банального отсутствия времени и бюджета на проект, пишут код по принципу «лишь бы работало», без учёта конкретных алгоритмов и подходов.

На Си мы обычно не видим такие продукты просто потому, что на Си их никто и не пишет (в силу высокой трудоёмкости). А вовсе не потому, что высокоуровневые языки тормознутые сами по себе.

А ни причём. Сумтипы vs наследование да и только.

Я в какой-то степени твой пафос понимаю. Нерациональность расходования ресурсов современных компов современными же программами меня тоже удручает.

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

Один из примеров — то, что EXL писал про шестнадцатиричные редакторы. Другой пример, Matrix, эталонная реализация клиента которого написана на б-гомерзком электроне. Есть более «нативные» реализации, но те, кто их тыкал, говорят, что в каждом из них чего-то да не хватает.

А тут речь даже не про электрон, а всего-то про лишнюю пару CALL/RET или как они там в современных архитектурах называются.

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

Почему программы на с++ тормозят :)

И вот почему они при этом тогда так тоооормоооознооооо компилируются…

Нерациональность расходования ресурсов современных компов современными же программами меня тоже удручает.

Компы нужны для того, чтобы экономить время человеков. Человек не должен превращаться в раба машины ради экономии циклов

Но если можешь писать всё на свитчах, и оно будет таким же полнофункциональным, как и аналоги — пиши, разумеется, ты герой.

Когда свитч один - это нормально, но очень часто они начинают повторяться. Чтобы не усложнять код дублированием и были придуманы указатели на функции, а потом и «оопшный» полиморфизм. Если человек, плодящий свитчи, работает в команде, тот скорее м-к, чем герой.

Другой пример, Matrix, эталонная реализация клиента которого написана на б-гомерзком электроне.

Тут вопрос эталонная или скорее прототипная. Или комбо: прототип, который считают эталоном.

Кстати, эталонную реализацию кодека AV1 писали же не где-то, а в Гугле? Нативную. А другие всё равно умудрились написать более производительную. Хотя они и нырнули глубже: в чёрную магию ассемблера (вот тебе и компиляторы нынче «умнее» ручного ассемблера, хотя, как всегда, смотря кто будет соревноваться).

Водитель движется быстрее авто.

Такая ситуация возможна с Java. Например, автопилот на JVM залипнет в GC, авто врежется в стену, а водитель продолжит движение через лобовое стекло.

Увы нет. А так приятно было - почти сишка и генерило бинарники размером с ассемблерные, без библиотек, без ничего. К - красота.

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

Есть еще один вариант: проект как бы есть, но он 1) падает при корнер-кейсах, про которые разработчик не подумал (входные данные опреденного вида, действия пользователя с гуи, и т.д.); 2) имеет утечки памяти; 3) выдает неверные результаты, так как в код вкралось UB; 4) прибит гвоздями к ОС или машине разработчика, причем не из-за использования каких-то особых технологий, а просто потому, что разработчик не умеет писать портабельный код. На плюсах такое сделать проще простого, а если разработчик новичок, то вряд ли у него что-то иное вообще получится.

очевидного развода

А можно для несистемщиков и неплюсовиков пояснить в чем развод? Говорит вроде складно да и все эти морфизмы и оопы я всегда недолюбливал.

Хахахаха

А можно для несистемщиков и неплюсовиков пояснить в чем развод?

И для тех, кому смотреть лень.

потому что «морфизмы» и ооп, vs оператор switch, это как путать космический корабль с палочкой, на которой ездят верхом. они служат для разных целей, и не заменяют друг друга, хотя при определенной фантазии можно найти их некоторое подобие.

Но тут все таки речь о системном программировании, где скорость работы таки важна, а не о вебне с морфизмами, фактори на фактори через фактори и всратыми паттернами со своими solid.

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

это как путать космический корабль с палочкой, на которой ездят верхом

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

Смотрел недвано это видео (тытруб мне его подбросил, потом еще дядю Боба подбросил; для контраста, наверное).

Автор вовсе не про плюсы задвигает. А про clean code («опрятный код») как парадигму и заповеди от грехов оберегающие.

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

Собственно, критикуемые заповеди:

• Полиморфизм хорошо; if else, switch плохо
• No internals (одна функция не должна лезть в потроха другой)
• Функции должны быть «маленькими»
• Функции должны делать что-то одно и ничего другого
• Don’t repeat yourself (D.R.Y.) (не повторяйся)

В процессе разбора автор приходит к выводу, что «все фигня, кроме D.R.Y».

Заменяем крутой полиморфизм на тупой свитч - получаем 1.5 ускорения :)

Это ерунда ещё. Он потом и свитч убрал, заменив на таблицу. И получил ускорение 10. Вот это уже круто.

Надо пару моментов уточнить:

1. Когда он заменял полиморфизм на свитч, то в процентном отношении такой большой выигрыш получился потому, что само тело функции было очень маленьким.
2. Замена полиморфизма на таблицу дала большой прирост по скорости, но в общем случае полиморфизм (или свитч) на таблицу не поменять. У него просто пример был подходящий.

Справедливости ради, в конце он говорит, что «чистый» код можно использовать, просто надо понимать цену.

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

полиморфизьм, это когда скрыта реализация свойств. когда можно использовать эти свойства, не вдаваясь в детали реализации.

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

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

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

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

В чём развод?

Развод в том, что чувак говорит «делай как я» без объяснения принципов и методов работы над системными оптимизациями. Это cargo cult в чистов виде. Даже не в даваясь в подробности (а он там обсуждает примитивную оптимизацию динамического полиморфизма, которая уже даже не работает на современных процессорах; вот работа аж 1996-го года на эту тему) можно видеть, что чувак не особенно вдается в детали. А в делах оптимизации детали превыше всего. Какой компилятор, какие флаги, какая платформа, какой ассемблерный код, какой memory layout, memory access pattern, cpu performance counters? Чувак вообще о профайлере не слышал. Повторить его результаты невозможно, да это и не стоит времени даже.

Вывод очевиден: видос для школьников. Если ты думаешь, что там какая-то полезная информация, то ты школьник (или веб макака въехавшая в C++, или в Rust :) и у тебя ноль опыта в системном программировании. Веб макаки, кстати, по моему наблюдению любят cargo cult, потому что глубины понимания у них нет ни в чём, одни поверхностные знания.

видос для школьников

Ну почему же только для школьников. Вполне сойдет для нубов, только что прочитавших «С++ за 21 день» и решивших, что любые задачи на плюсах правильно решать с помощью ООП. К чистому коду это, естественно, никакого отношения не имеет.

Вывод очевиден: видос для школьников. Если ты думаешь, что там какая-то полезная информация

А она таки есть. Я удивлён что Вы не видите посылов along the lines «не всё то солнышко что встаёт».

то ты школьник (или веб макака въехавшая в C++, или в Rust :) и у тебя ноль опыта в системном программировании.

Хех.

А она таки есть.

Я же говорю, хороший видос ;)

Это cargo cult в чистов виде.

cargo, говорите..)

• Полиморфизм хорошо; if else, switch плохо
• No internals (одна функция не должна лезть в потроха другой)
• Функции должны быть «маленькими»
• Функции должны делать что-то одно и ничего другого
• Don’t repeat yourself (D.R.Y.) (не повторяйся)

В процессе разбора автор приходит к выводу, что «все фигня, кроме D.R.Y».

Если D.R.Y. не фигня, то методом несложных размышлений все остальные принципы выводятся в обратном порядке из него. Начиная с конца списка. Сначала, что функции должны делать что-то одно, и вверх по пунктам.

На плюсах такое сделать проще простого, а если разработчик новичок, то вряд ли у него что-то иное вообще получится.

Ну такой говнокод на любом ЯП можно написать.

Вон очень неновичок Поттеринг вполне специально это делает на Си.

Увы нет. А так приятно было - почти сишка и генерило бинарники размером с ассемблерные, без библиотек, без ничего. К - красота.

https://justine.lol/cosmopolitan/index.html

Поттеринг вполне специально это делает на Си.

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

В сишке даже умных указателей нет, смысл ее отдельно рассматривать.

Их и в C++ не использую потому, что метаданные объектов знают о полях все и вся.

Освобождение памяти выполняет функция закрытия объекта.

При этом никакие умные указатели не нужны (API можно использовать и в Си).

Беда нынешних технологий в том, что

Много "Горя от ума"

Почему программы на с++ тормозят :)

ИМХО потому, что многие программисты

тормозные колодки

а actual сорсы где-то есть поиграться?

Этот тип не выложил , но кто-то с reddit перепечатал по видео. Не знаю насколько точно, но вроде похоже: https://gcc.godbolt.org/z/5o9Mvbfqr

Ещё нашли старое видео этого типа, по которому стали судить об его отношении к С++.

Этому видео 7 лет, и какие-то взгляды могли измениться, но похоже что нет: https://www.youtube.com/watch?app=desktop&t=460&v=zjkuXtiG1og&feature=youtu.be#menu

Здравствуйте, вот таким несложным способом можно ускорить программу в 20 раз

На реддите есть комменты что разница лишь 2 раза между первоначальным кодом и последним с таблицами и avx…

has anyone else tried this out?

I don’t see anything like the magnitude of performance improvement he claims with GCC or Clang on Linux (-O3 and -march=native on a second-gen Ryzen). Both switch and coefficient array approaches are around 2x the virtual function approach (with little separating them), which would quickly dwindle to irrelevance if the calculations performed were any less trivial or the shapes had more variety. That said I know optimizers can often outwit naïve benchmark code.

Я ж в предыдущем ответе тебе и выражал сомнение насчет процентов ускорения. Но я одобряю сам импульс, который чувак задает: народ заинтересовался, полез, проверил. Если это впечатлит нуба - уже хорошо.

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

Тут можно ещё посмотреть на другую метрику - количество строк кода. В примере со switch будет в примерно 2 раза меньше, чем в примере с полиморфизмом. А при использовании таблицы вообще в 3 или даже 4 раза меньше. При том, можно не только коэффициенты так хранить. Например, если мы делаем функцию, которая выводит имя фигуры, то мы тоже можем использовать таблицу имён. И это будет нагляднее.

Полиморфизм даёт только гибкость при разработке. В остальном он зачастую проигрывает. И не только по строчкам кода. Если надо поддерживать большой проект, то найти ошибку в «конкретном» коде обычно проще, потому что понятно, как части программы связаны между собой. В «полиморфном» коде части программы может связывать какая-то третья часть. При том, эта часть может производить эту связку по информации из базы данных. Вот тут вообще не поймёшь что и как работает.

Вангую, что variant тормознее виртуальных функций.

Почему программы на с++ тормозят :)

Если на слуху нет «крестового» кода, побивающего «сишный» код по производительности, то вывод напрашивается сам собой: Си++ тормознее Си. А возражения лишь обнажают вопрос веры, а не логики и знания «крестовиков». Разве возможно каким-то исходным кодом переубедить сектанта в вопросе его веры?

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