Поправьте если нет прав. Читаю код раста и C++ и вижу, что создание объектов разное. У раста просто вызывается метод класса, который создаёт обьект на стеке, в С++ создаётся объект в куче. Да ещё и через умный указатель, который имеет свой оверхед в виде сильных и слабых ссылок.
@@vladimirchizh8853 поддерживаю, я сам когда почитал код бэнчмарков, то был в шоке, как можно было так написать код требующий выской производительности, никто бы не стал ничего такого писать ни на С++ ни на Си...
Я категорически не согласен что "веб системы чувствуют одни только преимущества". Посмотри на загрузку памяти с 10 вкладками в гугл хроме. Я уж молчу про нагрузку процессора на любом сейчас сайте "модерновом". У любой абстракции есть стоимость, и к сожалению слишком много "программистов" нынешних не знают даже таких базовых вещей. Изза чего живут они, как будто стоимости нет. И теперь мы в ситуации когда никто уже без этих абстракций не знает как что либо сделать. Джаваскрипт и модерновый веб - это доказательство, что последние 10-20 лет на "инженеров" идет негативный, дисгенический отбор. Когда с каждым годом веб становится все хуже, ДАЖЕ не смотря на старания разработчиков компилятора V8 внутри JS.
@@АлександрВолобуев-м1л Забей, у автора коммента нормальной рыботы нет, чтобы хотябы себе железо 2018го года купить). До сих пор сидит на пеньке1 доставшемуся по наследству от отца 🤣
@@Александр-ф9в4ю Эм, у меня свой кластер из 6ти ятх 3060ти. Нормальное железо у меня есть. Суть вопроса в оперативке а не процессорах. Открой активные 10 вкладок ютуба одновременно. Плевать какое у тебя железо, гений.
@@doodocina нет. "C" простой как топор, в отличии от других языков из ролика. И абстракциями тоже нужно уметь пользоваться. Как сюда язык с GC забрался тоже вопрос интересный. Судя по повествованию в стиле "а... ммм... ну наверное это работает как то так..." автор только на си и писал, ибо в отношении других языков только доводы и слышны. "Ну наверное компилятор раста написан с использованием llvm". И вот в этих домыслах весь ролик. Очередной популист. Или вы из касты "много возможностей в языке - плохо, а шаблоны и вовсе запретить нужно"? Не можешь в плюсы/раст/го, ну и не лезь туда, либо бенчмарки делай показательными и с доступными исходниками, как это и делают люди когда сравнивают реализации на разных языках.
@@neromoonnn что нет? при чем тут си? к чему вся эта простыня текста? автор комментария с сарказмом назвал это лучшим бенчмарком, что он видел, потому что это худший бенчмарк, который можно придумать. нету никаких замеров нормальных, сравнивается время выполнения всей программы, инициализация рантайма, флаги кривые в первом тесте
Я почитал код бэнчмарков и это вообще что-то коричневое, никто так не пишет ни на С++ ни на Си, и даже на расте этот код будут писать по другому, т.к. к нему предъявляются требования по производительности... В общем я не доверяю этим результатам...
Я почитал твой код бэнчмарков и могу следать вывод, что ты либо не умеешь писать ни на Си, ни на С++, либо ты специально исопльзовал конструкции и подходы, не используемые в этих языках в задачах требующих высокой производительности... В общем я не одобряю данные тесты... Кстати да, на расте ты как ни странно тоже плохо код написал, но некоторые вещи для оптимизации использовал в отличии от С++ и Си. Код Go я не смотрел, возможно ты использовал эти решения чтобы не сильно отличаться от него... в общем как-то так себе ты написал бэнчмарки...
Это вообще не тесты, а мусор какой-то. Вообще валидные тесты - это решение какой-то реальной алгоритмической задачи, а в идеале - нескольких задач, при этом используя если не максимальные оптимизации (не в ущерб пониманию), то близкие к ним для каждого из языков. В противном случае я могу и на Java обогнать C++, если захочу.
@@MariaEseninaтак он использовал максимальные оптимизации, плюс, что такое реальные алгоритмические задачи и чем они отличаются от того что человек привел?
@@MariaEseninaя сам занимаюсь криптографией где функции для подсчета хэшей не отличаются какой то синтаксической выразительностью на СИ и не понимаю чем эти примеры не валидны для бенчмарков
И C++ тоже. То, что бы написали на C, он переварит (с мелкими оговорками на различия на языки). Но, и поддержка самого C++ тоже реализуема в том числе и на самом языке, без рантайма. Итого: различие в быстродействии С и C++ обычно не наблюдается. А вот конкретная реализация компилятора, даже для одного и того же языка, может дать разные результаты.
Более того, если на "не нативный" С# с unsafe, грамотно переписать код с Си, то не смотря на рантайм получим практически тоже самое быстродействие. Что я лично проверил на эмуляторе i486, где тестом выступает старая игра, и сравнивается достигнутый FPS. И разница быстродействия между C++, C# и Rust... практически никакая, менее 5%. То есть кривой исходник теста, влияет сильнее чем компиляторы и языки.
Интересно получается, три языка на llvm, которые в большинстве случаев генерируют практически одинаковый байткод, но при этом с++ сильно уступает. Это как? В бенчмарке с го, автор видимо в цикле выделяет массивы из-за чего ГЦ и задыхается, отсюда и такое отставание. И отсутстивие исходников, это только подтверждает.
та небось массивы копирует в аргументах. сколько раз уже такое было. ну, собственно говоря, для таких кадров и придумали упрощённые язычки, типа go и rust
@@proletarian Я посмотрел код бэнчмарков, там вообще всё не очень... Код явно написан чтобы получить предъвзятые результаты, на Си и С++ никто так не пишет, тем более производительный код, даже на расте тесты можно написать было лучше, в общем, такие себе результаты, вообще ни о чём...
А вообще я делал филосовские размышления на тему появления go, java и т.д. и соответсвующей депопуляризации Си. И я пришел к выводу что делается это намеренно в первую очередь что бы исключить появление новых ОС. Знание тонкостей железа сейчас тоже не в тренде, есть же языки которые "позволяют" тебе об этом не думать. Сложите 2+2 и сделайте вывод.
Нет, эти языки делаются намерено, чтобы быстрее писать бизнес-приложения. Бизнесу плевать на тонкости железа, ему важнее сделать быстрее продукт, продать его, тем самым заработав денег. Будет твой софт работать 1 с, а не 0,1 мс - вообще насрать.
Все различия в бенчмарках говорят лишь о неидеальности компиляторов. В мире идеальных компиляторов на выходе всех языков должен быть идеальный неотличимый бинарный код.
Есть минимум два сайта, где тестируют много языков на разных задачах. Там для одной задачи несколько вариантов кода. Результаты очень разные даже для одного языка.
В Расте вроде тоже можно бесшовно работать с Си, типа перегрузить стандартные сишные функции из libc в растовскую stdlib, и использовать сишные зависимости вместо стандартной растовской библиотеки. Или просто отключить растовскую стандартную библиотеку и использовать сишную. P.S. То есть, ты в Расте можешь просто отключить стандартную библиотеку и использовать сишную, при этом тебе будут доступны всякие растовские фишки типа владения, контроля ссылок, супер-пупер абстракции с нулевой стоимостью и т. п.
@ я не очень понимаю, как это возможно - аби у языков совсем разный. Не ясно, как встраивать си код в сборку. Какие-то костыли в Карго, может и есть. В плюсах и си используется один компилятор и система сборки
В С++ data 2 раза заполняется нулями. std::array инициализирует элементы по умалчанию. std::fill в крнструкторе не нужно. В С быстрее было бы сделать memset для инициализации data.
@@XpIOHdeJIb3000 эмм -- а как тогда будет аналогичный код то? в си же вообще передается для таких целей void* или что то подобное (типа указателя на базовый класс...) -- просто делается все ручками. ну и что вообще значит "в функции всегда передается this" -- конечно же нет, -- это для нестатических методов только. И тут как раз при этом следует отметить, что компиляторы во многих случаях обязаны девиртуализировать -- тоесть не посещать vtable -- а напрямую вызывать нужный вариант -- чего в си как раз не реализовать никак при динамическом полиморфизме.
зачем ставить флаги оптимизации, которые "примерно соответствуют"? если ты не можешь поставить О3 в расте или других языках, это проблемы исключительно этих языков. надо использовать весь потенциал языка в бенчмарке
Все просто - берем задачу в которой то чего зависит деньги или благополучие счета автора видео и спрашиваем он в таких условиях бы писал на каком языке? на С? или С++?;)
Тема модулей крестов не раскрыта))) У меня тестовые проекты в крестах в 1,5-3 раза быстрее собиралось. Но жду полноценной поддержки всех компиляторов и в СМаке. Производительность не проверял. 🤷
У Go запускается рантайм в котором есть планировщик горутин и сборщик мусора, из-за этого он столько всего делает. Вообще чтобы уровнять Rust и Go, можно в расте запустить метод main в рантайме tokio и вызывать все с async/await 😂 А так в целом для более объективной картины стоит проводить несколько разных тестов, но я думаю оно примерно так и будет C быстрее всех, Rust и C++ где-то рядом и медленнее всех Go. Но если например использовать в вебе, на каждый реквест ходить в базу и гонять json туда-сюда используя корутины, горутины, футуры и чего там есть асинхронного у C, то результат уже будет совершенно другим, причем даже больше будет завистеть от фреймворков чем от языка.
Чтобы написать на С или С++ то что может сделать новичок на Go нужно иметь довольно высокий уровень. Опять же, Go выбирают не ради производительности, а ради баланса между производительностью, масштабируемостью процесса разработки и продуктивностью разработчиков. Rust - хороший язык, но очень сложный если вам нужен Async. В С++20 появился function coloring (есть обычные функции и методы, а есть корутины), в Rust есть function coloring (обычные функции, async функции, unsafe) но плюс есть еще type coloring (есть тип а есть тип + lifetime annotation). И получается что вы пишете код, потом вам нужно сделать что-то асинхронное (начали использовать tokio например) и код нужно переделывать, потом выясняется что типы теперь возвращаются из асинхронных функций и передаются в асинхронные функции и теперь они требуют других lifetime аннотаций либо нужно все делать через Arc/mutex итд. В Go ничего этого нет. Сегментированные стеки, грутины, каналы, memory safety через GC, нет ичключений. Очень низкий когнитивный оверхед на каждую строчку кода.
именно. И тот же го от этого страдает дико, как бы не пыжились гуглы со своими миллиардами. Разрыв растет. Чо там говорить если в го существует проблема паддинга. И Нередко эти самые сеньоры что бы на каком нибудь сервисе крутящемся миллионными инстансами, переменные местами таскают вверх вниз чтоб съэкономить гигабайты упавшие с этих инстансов в сумме
Удивительно, как lto стал решать, оптимизации на этапе линковки работают когда в проекте больше одного файла, в данном случае весь бенч умещается в один файлик Не защищаю никакой язык, это просто инструмент, но все-таки использование unique_ptr в плюсах неоправдано как и нетривиальный std::fill вместо zero инициализации В си массив на стеке вообще, тоже нечестно
автор видимо сначала скомпилил код в объектник, а уже потом его в бинарник слинковал, соответственно компилятор не смог сделать оптимизации, т.к. не знал можно ли что-то выкинуть или оно будет использоваться в других объектниках... Там и сами бэнчмарки через одно место написаны, в общем такие себе результаты, вообще не релевантные...
дилетантский вопрос: Возможно ли, или на сколько правильным может быть создание связки железа и высокоуровнего языка программирования? Т. е. разработать железо под Rust к примеру... максимально оптимизированное, удобное и безопасное. (походу вопрос лежит больше в философской плоскости, "что первично материя или идея" железо или ПО)
@@SuperEuro процы разрабатывают с определённым набором команд, в зависимости от философии и спроса. потом на основе этих команд делают ассемблер. а из ассемблера делают примитивы для других языков и вот над этими примитивами уже строится стандартный везде одинаковый с/с++
И vlang в придачу с D :) Но смысл видео как бы намекает. Кстати там Завалишин Д.К. как-то давно начал писать ОСь Фантом, которая не переключает контекст, интересно что там получилось
Причем тут распараллеливание в случае Go?) Авторы вы корутины не исспользуете у вас нет паралельного кода в бенчмарке. Видео какой то поток слабосвязанных мыслей и домыслов.
чувак, если у тебя вызывает сомнение идея о том, что general-purpose programming language может и должен быть использован для всего, то у тебя проблемы.
Насчет "почему плюсы медленнее раста". Плюсы - вечно растущая раковая опухоль, которая руководится не логикой и здравым смыслом, а комитетом "ученых" которые в своей жизни ничего не написали НЕ на белой доске. Раст - такая же опухоль, растет так же, руководится такими же людьми, и даже хуже, ибо они еще и политические активисты. Но раст моложе, опухоль вечнорастущая и поглощающая, еще только начала расти.
чудовищно ФЪ точку :)) а ещё стоит отметить, что у ржаки нет нормальной модульности == вся херь пихуарится в один бинарь == на больших проектах ржака просто обречена дичайше лагать. в той же плюхе мало-мальски приличная раскладка проги в длл-ки даёт возможность настроить её по скорости / расходу озу / стабильности.
@@wennerryle1768 во ржаке модульность делать можно, но практически получается сиха на препроцессоре ржаки + никто не может объяснить "зачем надо было лепить горбатого, когда уже давно слепили аду???". а ещё стоит помнить, что у ржаки плоховато с обратной совместимостью. куча публики орёт как ржака хороша, но толком на ней никто не пишет, а процентов 50 проектов давно заброшены :))
Пробовал полюбить rust, не вышло. Для бэка он не такой удобный как Go. Производительности для бэка на Go более чем хватает. Rest запросы и походы в БД сводят на нет выигрыш в производительности. Как системный язык Rust не годится из-за своей параноидальной "безопасности". Системный язык должен позволять делать небезопасные трюки. В rust-е приходится обрастать unwrap-ами и переходит unsaved секции, что сводит его не нет. Плюсом C очень хорошо соотносится с ассемблером. Rust имеет высокоуровневые абстракции, которые сложно понять как развернуться в asm. Что то среднее где верховодит С++, rust делает гораздо хуже. Сделали эксперимент с лидом. Задача сводилась к общему указателю. Во первых в расте пришлось обрастать костылем в виде arс, и количество строк было раза в два больше чем в С++. И на мой взгляд синтаксис rust-а просто ужасен!!! Для вновь создаваемого языка, для которого не нужно тащить ни какого легаси, это просто факап.
Зависит от того какие задачи решаешь. Если Бэк с CRUD простенький то конечно Go. Если более менее сложная бизнес логика или требования по перформансу или интеропу - Го уже не катит. Если системное программирование - Логгеры, Протоколы, операционные системы, то это конечно Rust, никакой Go там и близко не стоял. Go может подойти для Control Plane в облаках но Data Plane это или Rust (linkerd) или С++ (Envoy). Кстати создатель Envoy сказал что он охотно бы переписал свой продукт на Rust, а Go вообще с проекта выкинул. То, с какой скоростью CloudFlare выкидывает Go и Nginx и заменяет это на Rust, тоже кагбе намекает. Но если задача - типичный бэк CRUD - то гошечки хватит с головой.
@@mikeofs1304 Я что то упустил тот момент, когда мы с вами на "ты" перешли. Судя по изложению, вы являетесь очень юным дарованием. Я понимаю что уважение к старшим у вашего поколения скорее всего исключение нежели правило. Это первая часть вопроса. Попробуем теперь разобраться со вторым. Я бы конечно спросил что такое raw pointer и про внутреннее устройство arc. А также immutable идеологию Rust-а, но уверен что в ответ получу копипасту из чата GPT.
@@bigtown2012 Я думаю, если бы ваша светлость писала бы в каждом коментарии свой возраст, список титулов и заслуг, то таких ситуаций можно бы было избежать. Искренне сожалею, бью тройной поясной поклон и прошу прощения. ЗЫ Immutable далеко не в расте появилась
Столько странных рассуждений о более консервативных оптимизациях в gcc по сравнению с llvm... А потом автор демонстрирует первопричину этого своего бреда, показав команды компиляции. Только `-O2` на gcc и `-O3 -march=native` у clang. Видимо этот бутерброд вкупе ещё и с `-flto` упорно выискивался с целью получить перф не хуже раста у плюсов и си при использовании clang. Реальную причину разницы в перфе почти гарантировано надо в коде искать. rustc без эквивалентов -march=native и без lto запускался.
Все что использует ЛЛВМ - априори не может быть эффективнее С. Таким макаром можно просто напрямую программировать на ЛЛВМ, без прослойки "псевдо-языка" между. Что некоторые люди делают прекрасно. По этому когда вы пишете на "расте" вы на самом деле просто программируете ЛЛВМ что бы он делал что вам нужно. Просто напрямую на ЛЛВМ писать очень громоздко и не удобно.
почему не может? ллвм может узнает больше паттернов или использует более продвинутый кодогенератор, такое точно не исключено. но что исключено - интеллект автора видео. "ой, у раста нету О3, поставлю ка я О2 на си, чтобы показать, какой раст быстрый"....
Какую же ты бредоту несёшь, давай эту бредоту развивать будем. Программируя на ЛЛВМ или С вы в конечном итоге программируете процессор. Просто напрямую на процессор писать очень громоздно и не удобно. Про особенности разных ЯП конечно ты ничего не слышал.
Раст к сожалению бесполезен для человека с уровнем интеллекта выше температуры в комнате. Не смотря на все заявления, он абсолютно НЕ безопасен. И в нем абсолютно так же можно сотворить кучу грязи. При этом абстракции которые построены поверх базы, настолько лимитирующие, что при малейших изменениях в лайфтаймах нужно менять структуру половины всей программы. Я уж молчу про то, что в стабильных версиях раста до недавнего времени сидели в открытую баги с памятью которые анулировали всю его "защиту". В итоге суть какая, очень интересно, концепт лайфтаймов и борроу чекера - забавная новая методика. Которые к сожалению абсолютно ни чем не помогают нормальному человеку, а даже делают хуже, замедляя его работу, во всех смыслах, и дев тайм, и ран тайм самой программы. Ах да, не забываем про время компиляции, но тут уже и раст и плюсы лицом упали в лужу.
@@voidptr_t Ох извините, что вас заставили читать больше трех слов. Тряска - где и от чего? Я просто комментирую по ходу просмотра видео. Можешь процетировать любой мой комент и показать мне где я не прав. Хотя бы один.
Раст к сожалению бесполезен для человека, с уровнем "насрать кусок говна и забыть", потому что насрать кусок говна и забыть в целом получится, но если потом с этой кучей говна придётся работать, то будут плак плак, ой ничего не работает, сложна. Дайте заговнокодить побыстрому багованное говно на С 🤣
@@RichardLofty за меня всё написали, могу добавить лишь то, что на данный момент математическая модель раста полностью безопасна, и по скорости он не уступает плюсам (у них даже выхлоп ассемблерный практически одинаковый). Аргументы про "ааа сложна(((((" отбросим, сложность и ограничения в говнокодинге с лихвой окупают себя в перспективе, когда накопленный код приходится поддерживать. Ну и что остаётся от "правоты" о которых ты мне говоришь? То, что когда-то в расте был баг с памятью? Ну поздравляю, когда-то в либси был баг с копированием памяти из-за которого влц вроде сломался в один момент. Я такое про что угодно сказать могу
Поправьте если нет прав. Читаю код раста и C++ и вижу, что создание объектов разное. У раста просто вызывается метод класса, который создаёт обьект на стеке, в С++ создаётся объект в куче. Да ещё и через умный указатель, который имеет свой оверхед в виде сильных и слабых ссылок.
Более честно будет и там и там создавать объекты на стеке
@@vladimirchizh8853 поддерживаю, я сам когда почитал код бэнчмарков, то был в шоке, как можно было так написать код требующий выской производительности, никто бы не стал ничего такого писать ни на С++ ни на Си...
Я категорически не согласен что "веб системы чувствуют одни только преимущества".
Посмотри на загрузку памяти с 10 вкладками в гугл хроме.
Я уж молчу про нагрузку процессора на любом сейчас сайте "модерновом".
У любой абстракции есть стоимость, и к сожалению слишком много "программистов" нынешних не знают даже таких базовых вещей.
Изза чего живут они, как будто стоимости нет.
И теперь мы в ситуации когда никто уже без этих абстракций не знает как что либо сделать.
Джаваскрипт и модерновый веб - это доказательство, что последние 10-20 лет на "инженеров" идет негативный, дисгенический отбор.
Когда с каждым годом веб становится все хуже, ДАЖЕ не смотря на старания разработчиков компилятора V8 внутри JS.
Который год живу с шестью окнами с общим количеством вкладок примерно пару тысяч. Понятно что все одновременно не открываются точнее не обновляются
@@АлександрВолобуев-м1л Забей, у автора коммента нормальной рыботы нет, чтобы хотябы себе железо 2018го года купить). До сих пор сидит на пеньке1 доставшемуся по наследству от отца 🤣
@@Александр-ф9в4ю железо железом а сайты всё таки говно
@@Александр-ф9в4ю
Эм, у меня свой кластер из 6ти ятх 3060ти.
Нормальное железо у меня есть.
Суть вопроса в оперативке а не процессорах.
Открой активные 10 вкладок ютуба одновременно.
Плевать какое у тебя железо, гений.
у любой вкладки есть стоимость, и к сожалению слишком много "пользователей" нынешних не знают даже таких базовых вещей
Это лучший бенчмарк который я видел! Жаль что даже не увидел код на C++, но кому вообще нужен код в бенчмарках?
Лол, может людям, которые пишут на этих языках и могут переписать бенчмарк лучше?
@@neromoonnnя так понял это сарказм
@@doodocina нет. "C" простой как топор, в отличии от других языков из ролика. И абстракциями тоже нужно уметь пользоваться. Как сюда язык с GC забрался тоже вопрос интересный. Судя по повествованию в стиле "а... ммм... ну наверное это работает как то так..." автор только на си и писал, ибо в отношении других языков только доводы и слышны. "Ну наверное компилятор раста написан с использованием llvm". И вот в этих домыслах весь ролик. Очередной популист. Или вы из касты "много возможностей в языке - плохо, а шаблоны и вовсе запретить нужно"? Не можешь в плюсы/раст/го, ну и не лезь туда, либо бенчмарки делай показательными и с доступными исходниками, как это и делают люди когда сравнивают реализации на разных языках.
@@neromoonnn что нет? при чем тут си? к чему вся эта простыня текста? автор комментария с сарказмом назвал это лучшим бенчмарком, что он видел, потому что это худший бенчмарк, который можно придумать. нету никаких замеров нормальных, сравнивается время выполнения всей программы, инициализация рантайма, флаги кривые в первом тесте
Я почитал код бэнчмарков и это вообще что-то коричневое, никто так не пишет ни на С++ ни на Си, и даже на расте этот код будут писать по другому, т.к. к нему предъявляются требования по производительности... В общем я не доверяю этим результатам...
Я почитал твой код бэнчмарков и могу следать вывод, что ты либо не умеешь писать ни на Си, ни на С++, либо ты специально исопльзовал конструкции и подходы, не используемые в этих языках в задачах требующих высокой производительности... В общем я не одобряю данные тесты...
Кстати да, на расте ты как ни странно тоже плохо код написал, но некоторые вещи для оптимизации использовал в отличии от С++ и Си. Код Go я не смотрел, возможно ты использовал эти решения чтобы не сильно отличаться от него... в общем как-то так себе ты написал бэнчмарки...
Это вообще не тесты, а мусор какой-то. Вообще валидные тесты - это решение какой-то реальной алгоритмической задачи, а в идеале - нескольких задач, при этом используя если не максимальные оптимизации (не в ущерб пониманию), то близкие к ним для каждого из языков. В противном случае я могу и на Java обогнать C++, если захочу.
Нуу, а вы бы на что заменили эти конструкции и как бы оптимизировали (спортивный интерес)?
@@MariaEseninaтак он использовал максимальные оптимизации, плюс, что такое реальные алгоритмические задачи и чем они отличаются от того что человек привел?
@@MariaEseninaя сам занимаюсь криптографией где функции для подсчета хэшей не отличаются какой то синтаксической выразительностью на СИ и не понимаю чем эти примеры не валидны для бенчмарков
Из чего ты сделал вывод? Какие конструкциии, он объявил структуру и в цикле переменные прибавлял...... безосновательный наброс
Интересно будет сравнить Zig когда он перейдет на свой компилятор без llvm.
Использовать С без рантайма CRT можно абсолютно спокойно и БЕЗ ассемблера внутри кода.
Используя вызовы к кернелу напрямую.
И C++ тоже. То, что бы написали на C, он переварит (с мелкими оговорками на различия на языки). Но, и поддержка самого C++ тоже реализуема в том числе и на самом языке, без рантайма.
Итого: различие в быстродействии С и C++ обычно не наблюдается. А вот конкретная реализация компилятора, даже для одного и того же языка, может дать разные результаты.
Более того, если на "не нативный" С# с unsafe, грамотно переписать код с Си, то не смотря на рантайм получим практически тоже самое быстродействие.
Что я лично проверил на эмуляторе i486, где тестом выступает старая игра, и сравнивается достигнутый FPS.
И разница быстродействия между C++, C# и Rust... практически никакая, менее 5%.
То есть кривой исходник теста, влияет сильнее чем компиляторы и языки.
Интересно получается, три языка на llvm, которые в большинстве случаев генерируют практически одинаковый байткод, но при этом с++ сильно уступает. Это как? В бенчмарке с го, автор видимо в цикле выделяет массивы из-за чего ГЦ и задыхается, отсюда и такое отставание. И отсутстивие исходников, это только подтверждает.
та небось массивы копирует в аргументах. сколько раз уже такое было. ну, собственно говоря, для таких кадров и придумали упрощённые язычки, типа go и rust
ну как бы очевидно - у остальных фронтендов оптимизация включена по умолчанию.
Без кода бенчмарков результаты и все выводы недостоверны
Посмотрите пожалуйста в описание, там ссылка на гитхаб, очень благодарен что смог вам помочь
@@proletarian Я посмотрел код бэнчмарков, там вообще всё не очень... Код явно написан чтобы получить предъвзятые результаты, на Си и С++ никто так не пишет, тем более производительный код, даже на расте тесты можно написать было лучше, в общем, такие себе результаты, вообще ни о чём...
@@AlexAlex-jk2tn я послушал несколько видео, какой то автор сомнительный
А вообще я делал филосовские размышления на тему появления go, java и т.д. и соответсвующей депопуляризации Си. И я пришел к выводу что делается это намеренно в первую очередь что бы исключить появление новых ОС. Знание тонкостей железа сейчас тоже не в тренде, есть же языки которые "позволяют" тебе об этом не думать. Сложите 2+2 и сделайте вывод.
Нет, эти языки делаются намерено, чтобы быстрее писать бизнес-приложения. Бизнесу плевать на тонкости железа, ему важнее сделать быстрее продукт, продать его, тем самым заработав денег. Будет твой софт работать 1 с, а не 0,1 мс - вообще насрать.
Все различия в бенчмарках говорят лишь о неидеальности компиляторов. В мире идеальных компиляторов на выходе всех языков должен быть идеальный неотличимый бинарный код.
Есть минимум два сайта, где тестируют много языков на разных задачах. Там для одной задачи несколько вариантов кода. Результаты очень разные даже для одного языка.
Их можно найти по запросу «programming language benchmarks»
Огромный плюс плюсов в том, что можно бесшовно работать с Си кодом. Кроме того, Си код валиден в плюсах.
У других языков не так гладко это работает
В Расте вроде тоже можно бесшовно работать с Си, типа перегрузить стандартные сишные функции из libc в растовскую stdlib, и использовать сишные зависимости вместо стандартной растовской библиотеки. Или просто отключить растовскую стандартную библиотеку и использовать сишную.
P.S. То есть, ты в Расте можешь просто отключить стандартную библиотеку и использовать сишную, при этом тебе будут доступны всякие растовские фишки типа владения, контроля ссылок, супер-пупер абстракции с нулевой стоимостью и т. п.
@ я не очень понимаю, как это возможно - аби у языков совсем разный. Не ясно, как встраивать си код в сборку. Какие-то костыли в Карго, может и есть. В плюсах и си используется один компилятор и система сборки
Хороший разбор. Что скажете о производительности языка D? Мне кажется язык незаслуженно обделён вниманием
В С++ data 2 раза заполняется нулями. std::array инициализирует элементы по умалчанию. std::fill в крнструкторе не нужно. В С быстрее было бы сделать memset для инициализации data.
20:54 -- можно хоть один пример платы за абстракции с++? примененные в данном случае ессесна...
один пример: в с++ в функции всегда передаётся указатель на this. В с такого нет, соответственно все вызовы короче.
@@XpIOHdeJIb3000 эмм -- а как тогда будет аналогичный код то? в си же вообще передается для таких целей void* или что то подобное (типа указателя на базовый класс...) -- просто делается все ручками.
ну и что вообще значит "в функции всегда передается this" -- конечно же нет, -- это для нестатических методов только. И тут как раз при этом следует отметить, что компиляторы во многих случаях обязаны девиртуализировать -- тоесть не посещать vtable -- а напрямую вызывать нужный вариант -- чего в си как раз не реализовать никак при динамическом полиморфизме.
зачем ставить флаги оптимизации, которые "примерно соответствуют"? если ты не можешь поставить О3 в расте или других языках, это проблемы исключительно этих языков. надо использовать весь потенциал языка в бенчмарке
Все просто - берем задачу в которой то чего зависит деньги или благополучие счета автора видео и спрашиваем он в таких условиях бы писал на каком языке? на С? или С++?;)
Тема модулей крестов не раскрыта))) У меня тестовые проекты в крестах в 1,5-3 раза быстрее собиралось. Но жду полноценной поддержки всех компиляторов и в СМаке. Производительность не проверял. 🤷
У Go запускается рантайм в котором есть планировщик горутин и сборщик мусора, из-за этого он столько всего делает. Вообще чтобы уровнять Rust и Go, можно в расте запустить метод main в рантайме tokio и вызывать все с async/await 😂 А так в целом для более объективной картины стоит проводить несколько разных тестов, но я думаю оно примерно так и будет C быстрее всех, Rust и C++ где-то рядом и медленнее всех Go. Но если например использовать в вебе, на каждый реквест ходить в базу и гонять json туда-сюда используя корутины, горутины, футуры и чего там есть асинхронного у C, то результат уже будет совершенно другим, причем даже больше будет завистеть от фреймворков чем от языка.
Чтобы написать на С или С++ то что может сделать новичок на Go нужно иметь довольно высокий уровень. Опять же, Go выбирают не ради производительности, а ради баланса между производительностью, масштабируемостью процесса разработки и продуктивностью разработчиков.
Rust - хороший язык, но очень сложный если вам нужен Async. В С++20 появился function coloring (есть обычные функции и методы, а есть корутины), в Rust есть function coloring (обычные функции, async функции, unsafe) но плюс есть еще type coloring (есть тип а есть тип + lifetime annotation). И получается что вы пишете код, потом вам нужно сделать что-то асинхронное (начали использовать tokio например) и код нужно переделывать, потом выясняется что типы теперь возвращаются из асинхронных функций и передаются в асинхронные функции и теперь они требуют других lifetime аннотаций либо нужно все делать через Arc/mutex итд. В Go ничего этого нет. Сегментированные стеки, грутины, каналы, memory safety через GC, нет ичключений. Очень низкий когнитивный оверхед на каждую строчку кода.
Огромный плюс плюсов в том, что можно бесшовно работать с Си кодом. Кроме того, Си код валиден в плюсах
Логичнее в списке сравнивать с zig а не с go
Невероятно интересное видео, несмотря на то что я тёмный лес - всё понятно.
Чувак, страшную вещь я принес в твой дом: LLVM нынче везде под капотом. А если еще нет, то скоро все равно да.
именно. И тот же го от этого страдает дико, как бы не пыжились гуглы со своими миллиардами. Разрыв растет. Чо там говорить если в го существует проблема паддинга. И Нередко эти самые сеньоры что бы на каком нибудь сервисе крутящемся миллионными инстансами, переменные местами таскают вверх вниз чтоб съэкономить гигабайты упавшие с этих инстансов в сумме
Версии языков не указаны :(
Удивительно, как lto стал решать, оптимизации на этапе линковки работают когда в проекте больше одного файла, в данном случае весь бенч умещается в один файлик
Не защищаю никакой язык, это просто инструмент, но все-таки использование unique_ptr в плюсах неоправдано как и нетривиальный std::fill вместо zero инициализации
В си массив на стеке вообще, тоже нечестно
автор видимо сначала скомпилил код в объектник, а уже потом его в бинарник слинковал, соответственно компилятор не смог сделать оптимизации, т.к. не знал можно ли что-то выкинуть или оно будет использоваться в других объектниках... Там и сами бэнчмарки через одно место написаны, в общем такие себе результаты, вообще не релевантные...
Так же заполнение массива нулями в конструкторе С++ через std::fill не очень эффективно, быстрее будет использовать std::memset
быстрее будет инициализация через `{}`, но автор видимо намеренно написал корявый код...
а поч для го не было принято оптимизаций
Кода нет что-ли?
30:39 Не тот размер показан. А то кажется, что бинарник занимает почти МБ
дилетантский вопрос: Возможно ли, или на сколько правильным может быть создание связки железа и высокоуровнего языка программирования? Т. е. разработать железо под Rust к примеру... максимально оптимизированное, удобное и безопасное. (походу вопрос лежит больше в философской плоскости, "что первично материя или идея" железо или ПО)
@@SuperEuro процы разрабатывают с определённым набором команд, в зависимости от философии и спроса. потом на основе этих команд делают ассемблер. а из ассемблера делают примитивы для других языков и вот над этими примитивами уже строится стандартный везде одинаковый с/с++
@@animuspexus th-cam.com/video/YUd1A1jCF38/w-d-xo.htmlsi=2qmMYoBdtj5Sc3xQ&t=3040 тут немного тему вопроса затронули...
Насчет ОС на Rust действительно хороший вопрос, а вот если Kubernetes на Rust (или аналог) ? Кто что думает ?
Redox же есть на расте
linux, k8s и js должны сдохнуть как можно скорее. но это вряд ли произойдет, слишком много говна уже накручено поверх этого базового говна
Спасибо огромное за такое классное видео!
а что таблицы excel уже заблочили? Нельзя было сразу все полученные данные залить в ячейки и сравнить?
Так он же фанат vim какой ещё Эксель. Даже маркдаун-форматированя не положено.
30:37 это почти один мегабайт на хеллоуворлд с ассемблерными вставками? моё почтение.
потестил на Си без ассемблера, с флагом -O3, размер 16Кб
а если добавить к сравнению carbon и zig? я так понял они позиционируются как "лучше чем си/си++"
И vlang в придачу с D :) Но смысл видео как бы намекает. Кстати там Завалишин Д.К. как-то давно начал писать ОСь Фантом, которая не переключает контекст, интересно что там получилось
@@ram0973 так и что такое сравнение должно показать? если это шутка то я её не догнал, я не программист даже)
Может тогда уже сразу низкоуровневые языки использовать?
Карбон не существует
@@RichardLofty он в разработке
Причем тут распараллеливание в случае Go?) Авторы вы корутины не исспользуете у вас нет паралельного кода в бенчмарке. Видео какой то поток слабосвязанных мыслей и домыслов.
чувак, если у тебя вызывает сомнение идея о том, что general-purpose programming language может и должен быть использован для всего, то у тебя проблемы.
У меня выгрузка из локальной базы оркл на го значительно быстрее раста получилось. Код простейший
Насчет "почему плюсы медленнее раста".
Плюсы - вечно растущая раковая опухоль, которая руководится не логикой и здравым смыслом, а комитетом "ученых" которые в своей жизни ничего не написали НЕ на белой доске.
Раст - такая же опухоль, растет так же, руководится такими же людьми, и даже хуже, ибо они еще и политические активисты.
Но раст моложе, опухоль вечнорастущая и поглощающая, еще только начала расти.
чудовищно ФЪ точку :)) а ещё стоит отметить, что у ржаки нет нормальной модульности == вся херь пихуарится в один бинарь == на больших проектах ржака просто обречена дичайше лагать. в той же плюхе мало-мальски приличная раскладка проги в длл-ки даёт возможность настроить её по скорости / расходу озу / стабильности.
@@SunHail8можно сделать отдельную либу которая будет компилироваться лишь один раз при изменениях прямо в проекте
@@wennerryle1768 во ржаке модульность делать можно, но практически получается сиха на препроцессоре ржаки + никто не может объяснить "зачем надо было лепить горбатого, когда уже давно слепили аду???". а ещё стоит помнить, что у ржаки плоховато с обратной совместимостью. куча публики орёт как ржака хороша, но толком на ней никто не пишет, а процентов 50 проектов давно заброшены :))
@@SunHail8 ну, как говорится, если на язык ругаются - значит им пользуются
@@wennerryle1768 для малых проектов попрёт, но альт хватает :) тот же typescript сильно посимпатичней :))
viddy уже на rust :D
Я слышал правильно называть кланг, а не силанг
Правильно называть шланг
клЭнг
Я слышал, что всем насрать, как называть clang
Пробовал полюбить rust, не вышло. Для бэка он не такой удобный как Go. Производительности для бэка на Go более чем хватает. Rest запросы и походы в БД сводят на нет выигрыш в производительности. Как системный язык Rust не годится из-за своей параноидальной "безопасности". Системный язык должен позволять делать небезопасные трюки. В rust-е приходится обрастать unwrap-ами и переходит unsaved секции, что сводит его не нет. Плюсом C очень хорошо соотносится с ассемблером. Rust имеет высокоуровневые абстракции, которые сложно понять как развернуться в asm. Что то среднее где верховодит С++, rust делает гораздо хуже. Сделали эксперимент с лидом. Задача сводилась к общему указателю. Во первых в расте пришлось обрастать костылем в виде arс, и количество строк было раза в два больше чем в С++. И на мой взгляд синтаксис rust-а просто ужасен!!! Для вновь создаваемого языка, для которого не нужно тащить ни какого легаси, это просто факап.
Зависит от того какие задачи решаешь. Если Бэк с CRUD простенький то конечно Go. Если более менее сложная бизнес логика или требования по перформансу или интеропу - Го уже не катит. Если системное программирование - Логгеры, Протоколы, операционные системы, то это конечно Rust, никакой Go там и близко не стоял. Go может подойти для Control Plane в облаках но Data Plane это или Rust (linkerd) или С++ (Envoy). Кстати создатель Envoy сказал что он охотно бы переписал свой продукт на Rust, а Go вообще с проекта выкинул. То, с какой скоростью CloudFlare выкидывает Go и Nginx и заменяет это на Rust, тоже кагбе намекает. Но если задача - типичный бэк CRUD - то гошечки хватит с головой.
То что ты считаешь Arc костылем в принципе все о тебе, и о твоем понимание Rust-а говорит, ггг
@@mikeofs1304 Я что то упустил тот момент, когда мы с вами на "ты" перешли. Судя по изложению, вы являетесь очень юным дарованием. Я понимаю что уважение к старшим у вашего поколения скорее всего исключение нежели правило. Это первая часть вопроса. Попробуем теперь разобраться со вторым. Я бы конечно спросил что такое raw pointer и про внутреннее устройство arc. А также immutable идеологию Rust-а, но уверен что в ответ получу копипасту из чата GPT.
@@bigtown2012 Я думаю, если бы ваша светлость писала бы в каждом коментарии свой возраст, список титулов и заслуг, то таких ситуаций можно бы было избежать. Искренне сожалею, бью тройной поясной поклон и прошу прощения. ЗЫ Immutable далеко не в расте появилась
Столько странных рассуждений о более консервативных оптимизациях в gcc по сравнению с llvm...
А потом автор демонстрирует первопричину этого своего бреда, показав команды компиляции. Только `-O2` на gcc и `-O3 -march=native` у clang.
Видимо этот бутерброд вкупе ещё и с `-flto` упорно выискивался с целью получить перф не хуже раста у плюсов и си при использовании clang.
Реальную причину разницы в перфе почти гарантировано надо в коде искать. rustc без эквивалентов -march=native и без lto запускался.
Хватит повторять повторять
Все что использует ЛЛВМ - априори не может быть эффективнее С.
Таким макаром можно просто напрямую программировать на ЛЛВМ, без прослойки "псевдо-языка" между.
Что некоторые люди делают прекрасно.
По этому когда вы пишете на "расте" вы на самом деле просто программируете ЛЛВМ что бы он делал что вам нужно.
Просто напрямую на ЛЛВМ писать очень громоздко и не удобно.
почему не может? ллвм может узнает больше паттернов или использует более продвинутый кодогенератор, такое точно не исключено.
но что исключено - интеллект автора видео. "ой, у раста нету О3, поставлю ка я О2 на си, чтобы показать, какой раст быстрый"....
Какую же ты бредоту несёшь, давай эту бредоту развивать будем. Программируя на ЛЛВМ или С вы в конечном итоге программируете процессор. Просто напрямую на процессор писать очень громоздно и не удобно.
Про особенности разных ЯП конечно ты ничего не слышал.
@@Александр-ф9в4ю Походу его в школе какие то любители раста обижают больно. Других объяснений нет
Раст к сожалению бесполезен для человека с уровнем интеллекта выше температуры в комнате.
Не смотря на все заявления, он абсолютно НЕ безопасен.
И в нем абсолютно так же можно сотворить кучу грязи.
При этом абстракции которые построены поверх базы, настолько лимитирующие, что при малейших изменениях в лайфтаймах нужно менять структуру половины всей программы.
Я уж молчу про то, что в стабильных версиях раста до недавнего времени сидели в открытую баги с памятью которые анулировали всю его "защиту".
В итоге суть какая, очень интересно, концепт лайфтаймов и борроу чекера - забавная новая методика.
Которые к сожалению абсолютно ни чем не помогают нормальному человеку, а даже делают хуже, замедляя его работу, во всех смыслах, и дев тайм, и ран тайм самой программы.
Ах да, не забываем про время компиляции, но тут уже и раст и плюсы лицом упали в лужу.
тряска на половину комментариев. выйди на улицу, траву потрогай 😕
@@voidptr_t
Ох извините, что вас заставили читать больше трех слов.
Тряска - где и от чего?
Я просто комментирую по ходу просмотра видео.
Можешь процетировать любой мой комент и показать мне где я не прав.
Хотя бы один.
Раст к сожалению бесполезен для человека, с уровнем "насрать кусок говна и забыть", потому что насрать кусок говна и забыть в целом получится, но если потом с этой кучей говна придётся работать, то будут плак плак, ой ничего не работает, сложна. Дайте заговнокодить побыстрому багованное говно на С 🤣
@@RichardLofty за меня всё написали, могу добавить лишь то, что на данный момент математическая модель раста полностью безопасна, и по скорости он не уступает плюсам (у них даже выхлоп ассемблерный практически одинаковый).
Аргументы про "ааа сложна(((((" отбросим, сложность и ограничения в говнокодинге с лихвой окупают себя в перспективе, когда накопленный код приходится поддерживать.
Ну и что остаётся от "правоты" о которых ты мне говоришь? То, что когда-то в расте был баг с памятью? Ну поздравляю, когда-то в либси был баг с копированием памяти из-за которого влц вроде сломался в один момент. Я такое про что угодно сказать могу
- Раст пытается вас приучить к горшку
- Не мне лучше под себя
интересный ролик, только я вообще на петухоне пишу)
АСУЖДАЮ