Я почитал твой код бэнчмарков и могу следать вывод, что ты либо не умеешь писать ни на Си, ни на С++, либо ты специально исопльзовал конструкции и подходы, не используемые в этих языках в задачах требующих высокой производительности... В общем я не одобряю данные тесты... Кстати да, на расте ты как ни странно тоже плохо код написал, но некоторые вещи для оптимизации использовал в отличии от С++ и Си. Код Go я не смотрел, возможно ты использовал эти решения чтобы не сильно отличаться от него... в общем как-то так себе ты написал бэнчмарки...
Это вообще не тесты, а мусор какой-то. Вообще валидные тесты - это решение какой-то реальной алгоритмической задачи, а в идеале - нескольких задач, при этом используя если не максимальные оптимизации (не в ущерб пониманию), то близкие к ним для каждого из языков. В противном случае я могу и на Java обогнать C++, если захочу.
Я категорически не согласен что "веб системы чувствуют одни только преимущества". Посмотри на загрузку памяти с 10 вкладками в гугл хроме. Я уж молчу про нагрузку процессора на любом сейчас сайте "модерновом". У любой абстракции есть стоимость, и к сожалению слишком много "программистов" нынешних не знают даже таких базовых вещей. Изза чего живут они, как будто стоимости нет. И теперь мы в ситуации когда никто уже без этих абстракций не знает как что либо сделать. Джаваскрипт и модерновый веб - это доказательство, что последние 10-20 лет на "инженеров" идет негативный, дисгенический отбор. Когда с каждым годом веб становится все хуже, ДАЖЕ не смотря на старания разработчиков компилятора V8 внутри JS.
@@АлександрВолобуев-м1л Забей, у автора коммента нормальной рыботы нет, чтобы хотябы себе железо 2018го года купить). До сих пор сидит на пеньке1 доставшемуся по наследству от отца 🤣
@@Александр-ф9в4ю Эм, у меня свой кластер из 6ти ятх 3060ти. Нормальное железо у меня есть. Суть вопроса в оперативке а не процессорах. Открой активные 10 вкладок ютуба одновременно. Плевать какое у тебя железо, гений.
Поправьте если нет прав. Читаю код раста и C++ и вижу, что создание объектов разное. У раста просто вызывается метод класса, который создаёт обьект на стеке, в С++ создаётся объект в куче. Да ещё и через умный указатель, который имеет свой оверхед в виде сильных и слабых ссылок.
@@vladimirchizh8853 поддерживаю, я сам когда почитал код бэнчмарков, то был в шоке, как можно было так написать код требующий выской производительности, никто бы не стал ничего такого писать ни на С++ ни на Си...
@@doodocina нет. "C" простой как топор, в отличии от других языков из ролика. И абстракциями тоже нужно уметь пользоваться. Как сюда язык с GC забрался тоже вопрос интересный. Судя по повествованию в стиле "а... ммм... ну наверное это работает как то так..." автор только на си и писал, ибо в отношении других языков только доводы и слышны. "Ну наверное компилятор раста написан с использованием llvm". И вот в этих домыслах весь ролик. Очередной популист. Или вы из касты "много возможностей в языке - плохо, а шаблоны и вовсе запретить нужно"? Не можешь в плюсы/раст/го, ну и не лезь туда, либо бенчмарки делай показательными и с доступными исходниками, как это и делают люди когда сравнивают реализации на разных языках.
@@neromoonnn что нет? при чем тут си? к чему вся эта простыня текста? автор комментария с сарказмом назвал это лучшим бенчмарком, что он видел, потому что это худший бенчмарк, который можно придумать. нету никаких замеров нормальных, сравнивается время выполнения всей программы, инициализация рантайма, флаги кривые в первом тесте
Я почитал код бэнчмарков и это вообще что-то коричневое, никто так не пишет ни на С++ ни на Си, и даже на расте этот код будут писать по другому, т.к. к нему предъявляются требования по производительности... В общем я не доверяю этим результатам...
И C++ тоже. То, что бы написали на C, он переварит (с мелкими оговорками на различия на языки). Но, и поддержка самого C++ тоже реализуема в том числе и на самом языке, без рантайма. Итого: различие в быстродействии С и C++ обычно не наблюдается. А вот конкретная реализация компилятора, даже для одного и того же языка, может дать разные результаты.
Более того, если на "не нативный" С# с unsafe, грамотно переписать код с Си, то не смотря на рантайм получим практически тоже самое быстродействие. Что я лично проверил на эмуляторе i486, где тестом выступает старая игра, и сравнивается достигнутый FPS. И разница быстродействия между C++, C# и Rust... практически никакая, менее 5%. То есть кривой исходник теста, влияет сильнее чем компиляторы и языки.
У Go запускается рантайм в котором есть планировщик горутин и сборщик мусора, из-за этого он столько всего делает. Вообще чтобы уровнять Rust и Go, можно в расте запустить метод main в рантайме tokio и вызывать все с async/await 😂 А так в целом для более объективной картины стоит проводить несколько разных тестов, но я думаю оно примерно так и будет C быстрее всех, Rust и C++ где-то рядом и медленнее всех Go. Но если например использовать в вебе, на каждый реквест ходить в базу и гонять json туда-сюда используя корутины, горутины, футуры и чего там есть асинхронного у C, то результат уже будет совершенно другим, причем даже больше будет завистеть от фреймворков чем от языка.
А вообще я делал филосовские размышления на тему появления go, java и т.д. и соответсвующей депопуляризации Си. И я пришел к выводу что делается это намеренно в первую очередь что бы исключить появление новых ОС. Знание тонкостей железа сейчас тоже не в тренде, есть же языки которые "позволяют" тебе об этом не думать. Сложите 2+2 и сделайте вывод.
Нет, эти языки делаются намерено, чтобы быстрее писать бизнес-приложения. Бизнесу плевать на тонкости железа, ему важнее сделать быстрее продукт, продать его, тем самым заработав денег. Будет твой софт работать 1 с, а не 0,1 мс - вообще насрать.
@@proletarian Я посмотрел код бэнчмарков, там вообще всё не очень... Код явно написан чтобы получить предъвзятые результаты, на Си и С++ никто так не пишет, тем более производительный код, даже на расте тесты можно написать было лучше, в общем, такие себе результаты, вообще ни о чём...
Интересно получается, три языка на llvm, которые в большинстве случаев генерируют практически одинаковый байткод, но при этом с++ сильно уступает. Это как? В бенчмарке с го, автор видимо в цикле выделяет массивы из-за чего ГЦ и задыхается, отсюда и такое отставание. И отсутстивие исходников, это только подтверждает.
та небось массивы копирует в аргументах. сколько раз уже такое было. ну, собственно говоря, для таких кадров и придумали упрощённые язычки, типа go и rust
Все различия в бенчмарках говорят лишь о неидеальности компиляторов. В мире идеальных компиляторов на выходе всех языков должен быть идеальный неотличимый бинарный код.
Все просто - берем задачу в которой то чего зависит деньги или благополучие счета автора видео и спрашиваем он в таких условиях бы писал на каком языке? на С? или С++?;)
Тема модулей крестов не раскрыта))) У меня тестовые проекты в крестах в 1,5-3 раза быстрее собиралось. Но жду полноценной поддержки всех компиляторов и в СМаке. Производительность не проверял. 🤷
В С++ data 2 раза заполняется нулями. std::array инициализирует элементы по умалчанию. std::fill в крнструкторе не нужно. В С быстрее было бы сделать memset для инициализации data.
Удивительно, как lto стал решать, оптимизации на этапе линковки работают когда в проекте больше одного файла, в данном случае весь бенч умещается в один файлик Не защищаю никакой язык, это просто инструмент, но все-таки использование unique_ptr в плюсах неоправдано как и нетривиальный std::fill вместо zero инициализации В си массив на стеке вообще, тоже нечестно
автор видимо сначала скомпилил код в объектник, а уже потом его в бинарник слинковал, соответственно компилятор не смог сделать оптимизации, т.к. не знал можно ли что-то выкинуть или оно будет использоваться в других объектниках... Там и сами бэнчмарки через одно место написаны, в общем такие себе результаты, вообще не релевантные...
именно. И тот же го от этого страдает дико, как бы не пыжились гуглы со своими миллиардами. Разрыв растет. Чо там говорить если в го существует проблема паддинга. И Нередко эти самые сеньоры что бы на каком нибудь сервисе крутящемся миллионными инстансами, переменные местами таскают вверх вниз чтоб съэкономить гигабайты упавшие с этих инстансов в сумме
дилетантский вопрос: Возможно ли, или на сколько правильным может быть создание связки железа и высокоуровнего языка программирования? Т. е. разработать железо под Rust к примеру... максимально оптимизированное, удобное и безопасное. (походу вопрос лежит больше в философской плоскости, "что первично материя или идея" железо или ПО)
@@SuperEuro процы разрабатывают с определённым набором команд, в зависимости от философии и спроса. потом на основе этих команд делают ассемблер. а из ассемблера делают примитивы для других языков и вот над этими примитивами уже строится стандартный везде одинаковый с/с++
зачем ставить флаги оптимизации, которые "примерно соответствуют"? если ты не можешь поставить О3 в расте или других языках, это проблемы исключительно этих языков. надо использовать весь потенциал языка в бенчмарке
И vlang в придачу с D :) Но смысл видео как бы намекает. Кстати там Завалишин Д.К. как-то давно начал писать ОСь Фантом, которая не переключает контекст, интересно что там получилось
чувак, если у тебя вызывает сомнение идея о том, что general-purpose programming language может и должен быть использован для всего, то у тебя проблемы.
Причем тут распараллеливание в случае Go?) Авторы вы корутины не исспользуете у вас нет паралельного кода в бенчмарке. Видео какой то поток слабосвязанных мыслей и домыслов.
Насчет "почему плюсы медленнее раста". Плюсы - вечно растущая раковая опухоль, которая руководится не логикой и здравым смыслом, а комитетом "ученых" которые в своей жизни ничего не написали НЕ на белой доске. Раст - такая же опухоль, растет так же, руководится такими же людьми, и даже хуже, ибо они еще и политические активисты. Но раст моложе, опухоль вечнорастущая и поглощающая, еще только начала расти.
чудовищно ФЪ точку :)) а ещё стоит отметить, что у ржаки нет нормальной модульности == вся херь пихуарится в один бинарь == на больших проектах ржака просто обречена дичайше лагать. в той же плюхе мало-мальски приличная раскладка проги в длл-ки даёт возможность настроить её по скорости / расходу озу / стабильности.
@@wennerryle1768 во ржаке модульность делать можно, но практически получается сиха на препроцессоре ржаки + никто не может объяснить "зачем надо было лепить горбатого, когда уже давно слепили аду???". а ещё стоит помнить, что у ржаки плоховато с обратной совместимостью. куча публики орёт как ржака хороша, но толком на ней никто не пишет, а процентов 50 проектов давно заброшены :))
Столько странных рассуждений о более консервативных оптимизациях в gcc по сравнению с llvm... А потом автор демонстрирует первопричину этого своего бреда, показав команды компиляции. Только `-O2` на gcc и `-O3 -march=native` у clang. Видимо этот бутерброд вкупе ещё и с `-flto` упорно выискивался с целью получить перф не хуже раста у плюсов и си при использовании clang. Реальную причину разницы в перфе почти гарантировано надо в коде искать. rustc без эквивалентов -march=native и без lto запускался.
Пробовал полюбить 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 далеко не в расте появилась
Все что использует ЛЛВМ - априори не может быть эффективнее С. Таким макаром можно просто напрямую программировать на ЛЛВМ, без прослойки "псевдо-языка" между. Что некоторые люди делают прекрасно. По этому когда вы пишете на "расте" вы на самом деле просто программируете ЛЛВМ что бы он делал что вам нужно. Просто напрямую на ЛЛВМ писать очень громоздко и не удобно.
почему не может? ллвм может узнает больше паттернов или использует более продвинутый кодогенератор, такое точно не исключено. но что исключено - интеллект автора видео. "ой, у раста нету О3, поставлю ка я О2 на си, чтобы показать, какой раст быстрый"....
Какую же ты бредоту несёшь, давай эту бредоту развивать будем. Программируя на ЛЛВМ или С вы в конечном итоге программируете процессор. Просто напрямую на процессор писать очень громоздно и не удобно. Про особенности разных ЯП конечно ты ничего не слышал.
Раст к сожалению бесполезен для человека с уровнем интеллекта выше температуры в комнате. Не смотря на все заявления, он абсолютно НЕ безопасен. И в нем абсолютно так же можно сотворить кучу грязи. При этом абстракции которые построены поверх базы, настолько лимитирующие, что при малейших изменениях в лайфтаймах нужно менять структуру половины всей программы. Я уж молчу про то, что в стабильных версиях раста до недавнего времени сидели в открытую баги с памятью которые анулировали всю его "защиту". В итоге суть какая, очень интересно, концепт лайфтаймов и борроу чекера - забавная новая методика. Которые к сожалению абсолютно ни чем не помогают нормальному человеку, а даже делают хуже, замедляя его работу, во всех смыслах, и дев тайм, и ран тайм самой программы. Ах да, не забываем про время компиляции, но тут уже и раст и плюсы лицом упали в лужу.
@@voidptr_t Ох извините, что вас заставили читать больше трех слов. Тряска - где и от чего? Я просто комментирую по ходу просмотра видео. Можешь процетировать любой мой комент и показать мне где я не прав. Хотя бы один.
Раст к сожалению бесполезен для человека, с уровнем "насрать кусок говна и забыть", потому что насрать кусок говна и забыть в целом получится, но если потом с этой кучей говна придётся работать, то будут плак плак, ой ничего не работает, сложна. Дайте заговнокодить побыстрому багованное говно на С 🤣
@@RichardLofty за меня всё написали, могу добавить лишь то, что на данный момент математическая модель раста полностью безопасна, и по скорости он не уступает плюсам (у них даже выхлоп ассемблерный практически одинаковый). Аргументы про "ааа сложна(((((" отбросим, сложность и ограничения в говнокодинге с лихвой окупают себя в перспективе, когда накопленный код приходится поддерживать. Ну и что остаётся от "правоты" о которых ты мне говоришь? То, что когда-то в расте был баг с памятью? Ну поздравляю, когда-то в либси был баг с копированием памяти из-за которого влц вроде сломался в один момент. Я такое про что угодно сказать могу
Я почитал твой код бэнчмарков и могу следать вывод, что ты либо не умеешь писать ни на Си, ни на С++, либо ты специально исопльзовал конструкции и подходы, не используемые в этих языках в задачах требующих высокой производительности... В общем я не одобряю данные тесты...
Кстати да, на расте ты как ни странно тоже плохо код написал, но некоторые вещи для оптимизации использовал в отличии от С++ и Си. Код Go я не смотрел, возможно ты использовал эти решения чтобы не сильно отличаться от него... в общем как-то так себе ты написал бэнчмарки...
Это вообще не тесты, а мусор какой-то. Вообще валидные тесты - это решение какой-то реальной алгоритмической задачи, а в идеале - нескольких задач, при этом используя если не максимальные оптимизации (не в ущерб пониманию), то близкие к ним для каждого из языков. В противном случае я могу и на Java обогнать C++, если захочу.
Я категорически не согласен что "веб системы чувствуют одни только преимущества".
Посмотри на загрузку памяти с 10 вкладками в гугл хроме.
Я уж молчу про нагрузку процессора на любом сейчас сайте "модерновом".
У любой абстракции есть стоимость, и к сожалению слишком много "программистов" нынешних не знают даже таких базовых вещей.
Изза чего живут они, как будто стоимости нет.
И теперь мы в ситуации когда никто уже без этих абстракций не знает как что либо сделать.
Джаваскрипт и модерновый веб - это доказательство, что последние 10-20 лет на "инженеров" идет негативный, дисгенический отбор.
Когда с каждым годом веб становится все хуже, ДАЖЕ не смотря на старания разработчиков компилятора V8 внутри JS.
Который год живу с шестью окнами с общим количеством вкладок примерно пару тысяч. Понятно что все одновременно не открываются точнее не обновляются
@@АлександрВолобуев-м1л Забей, у автора коммента нормальной рыботы нет, чтобы хотябы себе железо 2018го года купить). До сих пор сидит на пеньке1 доставшемуся по наследству от отца 🤣
@@Александр-ф9в4ю железо железом а сайты всё таки говно
@@Александр-ф9в4ю
Эм, у меня свой кластер из 6ти ятх 3060ти.
Нормальное железо у меня есть.
Суть вопроса в оперативке а не процессорах.
Открой активные 10 вкладок ютуба одновременно.
Плевать какое у тебя железо, гений.
у любой вкладки есть стоимость, и к сожалению слишком много "пользователей" нынешних не знают даже таких базовых вещей
Поправьте если нет прав. Читаю код раста и C++ и вижу, что создание объектов разное. У раста просто вызывается метод класса, который создаёт обьект на стеке, в С++ создаётся объект в куче. Да ещё и через умный указатель, который имеет свой оверхед в виде сильных и слабых ссылок.
Более честно будет и там и там создавать объекты на стеке
@@vladimirchizh8853 поддерживаю, я сам когда почитал код бэнчмарков, то был в шоке, как можно было так написать код требующий выской производительности, никто бы не стал ничего такого писать ни на С++ ни на Си...
Это лучший бенчмарк который я видел! Жаль что даже не увидел код на C++, но кому вообще нужен код в бенчмарках?
Лол, может людям, которые пишут на этих языках и могут переписать бенчмарк лучше?
@@neromoonnnя так понял это сарказм
@@doodocina нет. "C" простой как топор, в отличии от других языков из ролика. И абстракциями тоже нужно уметь пользоваться. Как сюда язык с GC забрался тоже вопрос интересный. Судя по повествованию в стиле "а... ммм... ну наверное это работает как то так..." автор только на си и писал, ибо в отношении других языков только доводы и слышны. "Ну наверное компилятор раста написан с использованием llvm". И вот в этих домыслах весь ролик. Очередной популист. Или вы из касты "много возможностей в языке - плохо, а шаблоны и вовсе запретить нужно"? Не можешь в плюсы/раст/го, ну и не лезь туда, либо бенчмарки делай показательными и с доступными исходниками, как это и делают люди когда сравнивают реализации на разных языках.
@@neromoonnn что нет? при чем тут си? к чему вся эта простыня текста? автор комментария с сарказмом назвал это лучшим бенчмарком, что он видел, потому что это худший бенчмарк, который можно придумать. нету никаких замеров нормальных, сравнивается время выполнения всей программы, инициализация рантайма, флаги кривые в первом тесте
Я почитал код бэнчмарков и это вообще что-то коричневое, никто так не пишет ни на С++ ни на Си, и даже на расте этот код будут писать по другому, т.к. к нему предъявляются требования по производительности... В общем я не доверяю этим результатам...
Использовать С без рантайма CRT можно абсолютно спокойно и БЕЗ ассемблера внутри кода.
Используя вызовы к кернелу напрямую.
И C++ тоже. То, что бы написали на C, он переварит (с мелкими оговорками на различия на языки). Но, и поддержка самого C++ тоже реализуема в том числе и на самом языке, без рантайма.
Итого: различие в быстродействии С и C++ обычно не наблюдается. А вот конкретная реализация компилятора, даже для одного и того же языка, может дать разные результаты.
Более того, если на "не нативный" С# с unsafe, грамотно переписать код с Си, то не смотря на рантайм получим практически тоже самое быстродействие.
Что я лично проверил на эмуляторе i486, где тестом выступает старая игра, и сравнивается достигнутый FPS.
И разница быстродействия между C++, C# и Rust... практически никакая, менее 5%.
То есть кривой исходник теста, влияет сильнее чем компиляторы и языки.
У Go запускается рантайм в котором есть планировщик горутин и сборщик мусора, из-за этого он столько всего делает. Вообще чтобы уровнять Rust и Go, можно в расте запустить метод main в рантайме tokio и вызывать все с async/await 😂 А так в целом для более объективной картины стоит проводить несколько разных тестов, но я думаю оно примерно так и будет C быстрее всех, Rust и C++ где-то рядом и медленнее всех Go. Но если например использовать в вебе, на каждый реквест ходить в базу и гонять json туда-сюда используя корутины, горутины, футуры и чего там есть асинхронного у C, то результат уже будет совершенно другим, причем даже больше будет завистеть от фреймворков чем от языка.
Интересно будет сравнить Zig когда он перейдет на свой компилятор без llvm.
А вообще я делал филосовские размышления на тему появления go, java и т.д. и соответсвующей депопуляризации Си. И я пришел к выводу что делается это намеренно в первую очередь что бы исключить появление новых ОС. Знание тонкостей железа сейчас тоже не в тренде, есть же языки которые "позволяют" тебе об этом не думать. Сложите 2+2 и сделайте вывод.
Нет, эти языки делаются намерено, чтобы быстрее писать бизнес-приложения. Бизнесу плевать на тонкости железа, ему важнее сделать быстрее продукт, продать его, тем самым заработав денег. Будет твой софт работать 1 с, а не 0,1 мс - вообще насрать.
Без кода бенчмарков результаты и все выводы недостоверны
Посмотрите пожалуйста в описание, там ссылка на гитхаб, очень благодарен что смог вам помочь
@@proletarian Я посмотрел код бэнчмарков, там вообще всё не очень... Код явно написан чтобы получить предъвзятые результаты, на Си и С++ никто так не пишет, тем более производительный код, даже на расте тесты можно написать было лучше, в общем, такие себе результаты, вообще ни о чём...
@@AlexAlex-jk2tn я послушал несколько видео, какой то автор сомнительный
Огромный плюс плюсов в том, что можно бесшовно работать с Си кодом. Кроме того, Си код валиден в плюсах.
У других языков не так гладко это работает
Интересно получается, три языка на llvm, которые в большинстве случаев генерируют практически одинаковый байткод, но при этом с++ сильно уступает. Это как? В бенчмарке с го, автор видимо в цикле выделяет массивы из-за чего ГЦ и задыхается, отсюда и такое отставание. И отсутстивие исходников, это только подтверждает.
та небось массивы копирует в аргументах. сколько раз уже такое было. ну, собственно говоря, для таких кадров и придумали упрощённые язычки, типа go и rust
ну как бы очевидно - у остальных фронтендов оптимизация включена по умолчанию.
Все различия в бенчмарках говорят лишь о неидеальности компиляторов. В мире идеальных компиляторов на выходе всех языков должен быть идеальный неотличимый бинарный код.
Все просто - берем задачу в которой то чего зависит деньги или благополучие счета автора видео и спрашиваем он в таких условиях бы писал на каком языке? на С? или С++?;)
Тема модулей крестов не раскрыта))) У меня тестовые проекты в крестах в 1,5-3 раза быстрее собиралось. Но жду полноценной поддержки всех компиляторов и в СМаке. Производительность не проверял. 🤷
Хороший разбор. Что скажете о производительности языка D? Мне кажется язык незаслуженно обделён вниманием
Спасибо огромное за такое классное видео!
а что таблицы excel уже заблочили? Нельзя было сразу все полученные данные залить в ячейки и сравнить?
Так он же фанат vim какой ещё Эксель. Даже маркдаун-форматированя не положено.
В С++ data 2 раза заполняется нулями. std::array инициализирует элементы по умалчанию. std::fill в крнструкторе не нужно. В С быстрее было бы сделать memset для инициализации data.
Удивительно, как lto стал решать, оптимизации на этапе линковки работают когда в проекте больше одного файла, в данном случае весь бенч умещается в один файлик
Не защищаю никакой язык, это просто инструмент, но все-таки использование unique_ptr в плюсах неоправдано как и нетривиальный std::fill вместо zero инициализации
В си массив на стеке вообще, тоже нечестно
автор видимо сначала скомпилил код в объектник, а уже потом его в бинарник слинковал, соответственно компилятор не смог сделать оптимизации, т.к. не знал можно ли что-то выкинуть или оно будет использоваться в других объектниках... Там и сами бэнчмарки через одно место написаны, в общем такие себе результаты, вообще не релевантные...
Невероятно интересное видео, несмотря на то что я тёмный лес - всё понятно.
Огромный плюс плюсов в том, что можно бесшовно работать с Си кодом. Кроме того, Си код валиден в плюсах
Логичнее в списке сравнивать с zig а не с go
Чувак, страшную вещь я принес в твой дом: LLVM нынче везде под капотом. А если еще нет, то скоро все равно да.
именно. И тот же го от этого страдает дико, как бы не пыжились гуглы со своими миллиардами. Разрыв растет. Чо там говорить если в го существует проблема паддинга. И Нередко эти самые сеньоры что бы на каком нибудь сервисе крутящемся миллионными инстансами, переменные местами таскают вверх вниз чтоб съэкономить гигабайты упавшие с этих инстансов в сумме
20:54 -- можно хоть один пример платы за абстракции с++? примененные в данном случае ессесна...
дилетантский вопрос: Возможно ли, или на сколько правильным может быть создание связки железа и высокоуровнего языка программирования? Т. е. разработать железо под Rust к примеру... максимально оптимизированное, удобное и безопасное. (походу вопрос лежит больше в философской плоскости, "что первично материя или идея" железо или ПО)
@@SuperEuro процы разрабатывают с определённым набором команд, в зависимости от философии и спроса. потом на основе этих команд делают ассемблер. а из ассемблера делают примитивы для других языков и вот над этими примитивами уже строится стандартный везде одинаковый с/с++
@@animuspexus ruclips.net/video/YUd1A1jCF38/видео.htmlsi=2qmMYoBdtj5Sc3xQ&t=3040 тут немного тему вопроса затронули...
Так же заполнение массива нулями в конструкторе С++ через std::fill не очень эффективно, быстрее будет использовать std::memset
быстрее будет инициализация через `{}`, но автор видимо намеренно написал корявый код...
зачем ставить флаги оптимизации, которые "примерно соответствуют"? если ты не можешь поставить О3 в расте или других языках, это проблемы исключительно этих языков. надо использовать весь потенциал языка в бенчмарке
30:37 это почти один мегабайт на хеллоуворлд с ассемблерными вставками? моё почтение.
потестил на Си без ассемблера, с флагом -O3, размер 16Кб
а поч для го не было принято оптимизаций
Версии языков не указаны :(
Насчет ОС на Rust действительно хороший вопрос, а вот если Kubernetes на Rust (или аналог) ? Кто что думает ?
Redox же есть на расте
linux, k8s и js должны сдохнуть как можно скорее. но это вряд ли произойдет, слишком много говна уже накручено поверх этого базового говна
а если добавить к сравнению carbon и zig? я так понял они позиционируются как "лучше чем си/си++"
И vlang в придачу с D :) Но смысл видео как бы намекает. Кстати там Завалишин Д.К. как-то давно начал писать ОСь Фантом, которая не переключает контекст, интересно что там получилось
@@ram0973 так и что такое сравнение должно показать? если это шутка то я её не догнал, я не программист даже)
Может тогда уже сразу низкоуровневые языки использовать?
Карбон не существует
@@RichardLofty он в разработке
чувак, если у тебя вызывает сомнение идея о том, что general-purpose programming language может и должен быть использован для всего, то у тебя проблемы.
Кода нет что-ли?
У меня выгрузка из локальной базы оркл на го значительно быстрее раста получилось. Код простейший
30:39 Не тот размер показан. А то кажется, что бинарник занимает почти МБ
Причем тут распараллеливание в случае Go?) Авторы вы корутины не исспользуете у вас нет паралельного кода в бенчмарке. Видео какой то поток слабосвязанных мыслей и домыслов.
Насчет "почему плюсы медленнее раста".
Плюсы - вечно растущая раковая опухоль, которая руководится не логикой и здравым смыслом, а комитетом "ученых" которые в своей жизни ничего не написали НЕ на белой доске.
Раст - такая же опухоль, растет так же, руководится такими же людьми, и даже хуже, ибо они еще и политические активисты.
Но раст моложе, опухоль вечнорастущая и поглощающая, еще только начала расти.
чудовищно ФЪ точку :)) а ещё стоит отметить, что у ржаки нет нормальной модульности == вся херь пихуарится в один бинарь == на больших проектах ржака просто обречена дичайше лагать. в той же плюхе мало-мальски приличная раскладка проги в длл-ки даёт возможность настроить её по скорости / расходу озу / стабильности.
@@SunHail8можно сделать отдельную либу которая будет компилироваться лишь один раз при изменениях прямо в проекте
@@wennerryle1768 во ржаке модульность делать можно, но практически получается сиха на препроцессоре ржаки + никто не может объяснить "зачем надо было лепить горбатого, когда уже давно слепили аду???". а ещё стоит помнить, что у ржаки плоховато с обратной совместимостью. куча публики орёт как ржака хороша, но толком на ней никто не пишет, а процентов 50 проектов давно заброшены :))
@@SunHail8 ну, как говорится, если на язык ругаются - значит им пользуются
@@wennerryle1768 для малых проектов попрёт, но альт хватает :) тот же typescript сильно посимпатичней :))
Столько странных рассуждений о более консервативных оптимизациях в gcc по сравнению с llvm...
А потом автор демонстрирует первопричину этого своего бреда, показав команды компиляции. Только `-O2` на gcc и `-O3 -march=native` у clang.
Видимо этот бутерброд вкупе ещё и с `-flto` упорно выискивался с целью получить перф не хуже раста у плюсов и си при использовании clang.
Реальную причину разницы в перфе почти гарантировано надо в коде искать. rustc без эквивалентов -march=native и без lto запускался.
viddy уже на rust :D
Пробовал полюбить 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 далеко не в расте появилась
Я слышал правильно называть кланг, а не силанг
Правильно называть шланг
клЭнг
Я слышал, что всем насрать, как называть clang
Все что использует ЛЛВМ - априори не может быть эффективнее С.
Таким макаром можно просто напрямую программировать на ЛЛВМ, без прослойки "псевдо-языка" между.
Что некоторые люди делают прекрасно.
По этому когда вы пишете на "расте" вы на самом деле просто программируете ЛЛВМ что бы он делал что вам нужно.
Просто напрямую на ЛЛВМ писать очень громоздко и не удобно.
почему не может? ллвм может узнает больше паттернов или использует более продвинутый кодогенератор, такое точно не исключено.
но что исключено - интеллект автора видео. "ой, у раста нету О3, поставлю ка я О2 на си, чтобы показать, какой раст быстрый"....
Какую же ты бредоту несёшь, давай эту бредоту развивать будем. Программируя на ЛЛВМ или С вы в конечном итоге программируете процессор. Просто напрямую на процессор писать очень громоздно и не удобно.
Про особенности разных ЯП конечно ты ничего не слышал.
@@Александр-ф9в4ю Походу его в школе какие то любители раста обижают больно. Других объяснений нет
Хватит повторять повторять
Раст к сожалению бесполезен для человека с уровнем интеллекта выше температуры в комнате.
Не смотря на все заявления, он абсолютно НЕ безопасен.
И в нем абсолютно так же можно сотворить кучу грязи.
При этом абстракции которые построены поверх базы, настолько лимитирующие, что при малейших изменениях в лайфтаймах нужно менять структуру половины всей программы.
Я уж молчу про то, что в стабильных версиях раста до недавнего времени сидели в открытую баги с памятью которые анулировали всю его "защиту".
В итоге суть какая, очень интересно, концепт лайфтаймов и борроу чекера - забавная новая методика.
Которые к сожалению абсолютно ни чем не помогают нормальному человеку, а даже делают хуже, замедляя его работу, во всех смыслах, и дев тайм, и ран тайм самой программы.
Ах да, не забываем про время компиляции, но тут уже и раст и плюсы лицом упали в лужу.
тряска на половину комментариев. выйди на улицу, траву потрогай 😕
@@voidptr_t
Ох извините, что вас заставили читать больше трех слов.
Тряска - где и от чего?
Я просто комментирую по ходу просмотра видео.
Можешь процетировать любой мой комент и показать мне где я не прав.
Хотя бы один.
Раст к сожалению бесполезен для человека, с уровнем "насрать кусок говна и забыть", потому что насрать кусок говна и забыть в целом получится, но если потом с этой кучей говна придётся работать, то будут плак плак, ой ничего не работает, сложна. Дайте заговнокодить побыстрому багованное говно на С 🤣
@@RichardLofty за меня всё написали, могу добавить лишь то, что на данный момент математическая модель раста полностью безопасна, и по скорости он не уступает плюсам (у них даже выхлоп ассемблерный практически одинаковый).
Аргументы про "ааа сложна(((((" отбросим, сложность и ограничения в говнокодинге с лихвой окупают себя в перспективе, когда накопленный код приходится поддерживать.
Ну и что остаётся от "правоты" о которых ты мне говоришь? То, что когда-то в расте был баг с памятью? Ну поздравляю, когда-то в либси был баг с копированием памяти из-за которого влц вроде сломался в один момент. Я такое про что угодно сказать могу
- Раст пытается вас приучить к горшку
- Не мне лучше под себя
интересный ролик, только я вообще на петухоне пишу)
АСУЖДАЮ