Mergiraf — новый движок разрешения конфликтов в коде

Для скорости :)

Протестую. Лямбды туда очень сильно завезли и они радикально упрощают код.

Тут больше вопрос к тому, нахрена было сделано через костыль с вычислимым goto в ведре…

Потому что так быстрее чем через switch-case. Это сишный говнохак типа Duff’s device, чтобы заставить компилятор оптимизировать говнокод.

Так не только в ядре сделано. Многие интерпретаторы используют эту фичу. Как минимум, в Dalvik так же сделано.

Нет, это делается потому, что в современных CPU, конструкция switch/case сильно неэффективна из-за большого количества сравнений, которые не позволяют эффективно использовать branch predictor.

Jump table эффективнее из-за того, что позволяет оптимальнее использовать ресурсы современных CPU, выигрыш по скорости где-то 20-25%.

Нет, это делается потому, что в современных CPU, конструкция switch/case сильно неэффективна из-за большого количества сравнений, которые не позволяют эффективно использовать branch predictor.

Не только. Это быстрее потому что:

The difference between the two is obviously the «bounds check» step of the switch. Why is it required? You may think that this is because of the default clause, but that isn’t true. Even without the default clause, the compiler is forced to generate the bounds check for the switch statement to conform to the C standard. Quoting from C99:

If no converted case constant expression matches and there is no default label, no part of the switch body is executed.

Therefore, the standard forces the compiler to generate «safe» code for the switch. Safety, as usual, has cost, so the switch version ends up doing a bit more per loop iteration.

Из ссылки в моём предыдущем комменте. Ну и branch prediction тут роляет, да. Код не перестаёт быть говнохаком, а сишечка как обычно сосёт.

each of your programs must link statically

Ну что за бред собачий. Уязвимость в одной библиотеке = пересборка половины системы.

no client-side scripting, including JavaScript on web-sites

Наркотики это плохо. Понятненько?

No multithreading (and shared memory)

Особенно тяжёлые наркотики

Speaking generally, in all new protocols and applications the set of cryptographic algorithms being used must be fixed, once and forever.

В рехаб! Срочно в рехаб!

Вроде как даже компиляторы умеют в таблицу. Да и сама оптимизация там не шибко сложная

Ну что за бред собачий.

Большая часть творчества Столярова такая. А теперь прикинь, что он в МГУ студентов учил.

No multithreading (and shared memory)

Особенно тяжёлые наркотики

Не, тут он прав. Если выкинуть нахрен shared-memory parallelism, жизнь становится куда проще и понятнее. Как пример такого подхода, можешь посмотреть хотя бы на Erlang.

Я не обсуждаю все, что там написано. Это тема для отдельного разговора, если вообще таковой нужен. Мое отношение к растаманам полностью совпадает со Столяровским.

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

Ну и как в том C++ лямды реализованы? Не через ad hoc ли класс-функтор с переопределением оператора «скобки»? Синтаксический сахар все это...

Это наркомания в терминальной форме. Мозг сгнил.

Либо он просто не понимает зачем тренды нужны.

Без ветвлений всё это делается на условных инструкциях. Это должен компилятор делать

Да скорее всего но в куте с ними стало радикально удобнее

А теперь прикинь, что он в МГУ студентов учил

Я был о нем лучшего мнения пока эту дичь не увидел

Ты вообще можешь хоть что-то про свой раст написать не копируя в сотый раз одни и те же совершенно нерелевантние маркетинговые слоганы из методички Rust Evangelism Strike Force?

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

Это тот кто заюзал лор только (больше нет сообщений) для рекламы своих книжек?

А что в этом плохого? Если пользователь только читает ЛОР, не участвует в срачах, и делает публикации только по факту появления своих новых наработок - это что, называется неприкрытой рекламой?

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

Да, Qt уходит от традиций предоставления Qt-специфичных API, поэтому постепенно код кутэшных программ становится более похож на обычный цпп.

написать не копируя

Интересно, а как ты определяешь, что я написал не своё мнение, а скопировал что-то откуда-то?

Я вот, почему-то, не имею вообще никаких проблем ни с многопоточностью, ни с UB, ни с типизацией, поэтому решать их мне прсто не требуется

Ну, а у меня нет проблем с расчётом конструкции моста. Потому что я не проектирую их. Ровно как ты не пишешь программы, судя по всему.

маркетинговый шлак

Сильная типизация - объективное и полезное свойство ЯП, упоминают его в маркетинге или нет. Если тебя так коробит от его упоминания, то давай я тебе напишу про свойства языка Си. Перестанешь его использовать после этого, а?

Но можно же принять факт, что раст лучше си/цпп

Нельзя.

Один Rust плохой почему-то.

Я думаю тут сыграла банальная вещь: раст стали нарекать убийцей С/С++, на этом его путь был определен как трудный и тернистый))))

Ну, а у меня нет проблем с расчётом конструкции моста. Потому что я не проектирую их.

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

Раст хайповый - на этом пока все, т.к. все остальные его достоинства видятся условными или «как у других»…

Я на этот раз из далека глянул:

• синтаксис вырвиглазный
• чтоб быстро работало, нужно писать небезопасно (как собственно в Си)
• Плюсом можно считать преднастроенный процесс компиляции (действительно при необходимости шустрые приложуньку получаются, но не быстрее чем на С с оптимизациями)

Более в расте мне в глаза особо ничего не бросилось… Очередной убийца С/С++ - не более…

Занимательно, но очень уж далеко от наших реалий
Впрочем, я согласен с более. чем половиной пунктов. Теперь у меня даже больше аргументов в пользу использования ini вместо json для конфигов

решить один конкретный класс ошибок в программах.

И из-за этого надо переписать на него всё, и даже Небо и даже Аллаха

SIGSEGV невозможен

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

На Go, скажем, тоже дофига чего переписывают. Есть куча утилит на Go, являющихся аналогами C-шных утилит. Тоже не вижу плача из-за этого. Один Rust плохой почему-то.

Возможно, утилит меньше, а возможно связано с тем, что go утилиты очень часто поставляются статическим бинарником.
Основной негатив к rust идёт со стороны пользователей source-based дистрибутивов, потому что им приходится это всё собирать. А собирать там много:
1. Сам rust + llvm. На слабенькой машине это не один день сборки. Бинрный rust частично решает проблему. И чтобы собрать rust нужен rust, древние версии были на ocaml (вроде), в общем забусттрапить с нуля почти нереально.
2. Многим библиотекам нужны всякие cbindgen, соответственно ещё и clang. И не важно, что в системе уже есть gcc. И тут rust-bin никак не облегчит ситуацию
3. Ок, поставили компилятор - готовьтесь, что к полторакилобайтному проекту накачается гигабайт зависиимостей встроенным в rust пакетным менеджером (основна штука, которую я не люблю в rust). Работоспособность и безопасность этих библиотек проверена только на машине разработчика, аудита не было, сорцы никто не читал
4. Каталог сборки маленького консольного приложения раздувает до 8-12 гигабайт. Собирается всё с сорцов, бинарные либы никто не подтягивает. Вроде даже стдлиба из сорцов
5. В итоге с немалой вероятностью у тебя сборка валится потому что раст старый, возрвращаешься к п. 1

Либо он просто не понимает зачем тренды нужны.

А зачем треды нужны?

чтоб быстро работало, нужно писать небезопасно (как собственно в Си)

Нет. Хуже того, 90% кода на Си — тормозное говно. Хотя бы весь GTK взять.

Тебе секта мешает взять книжку по языку, почитать, написать пару программ и составить своё ЛИЧНОЕ мнение именно о языке?

Вот кстати я не критиковал rust пока не пытался писать на нём. Но со временем накопился негатив. Можно считать «не осилил» наверно XD

Когда его уже на rust перепишут?

Asahi Lina утверждает что rust очень помог с управлению памяти в драйвере gpu:
https://old.reddit.com/r/rust/comments/xwdhwd/asahi_lina_on_her_experience_wr...

Ну вот лялекс переписывают потихоньку. Вопли стоят — ушам услада!

А как этот клоун собирается работать с вьетнамским языком без поддержки комбинированых символов?

В Rust такое делается через tail-call и инлайнинг,

Не делается (компилятор не гарантирует оптимизацию хвостовых вызовов). become же в вечном анстейбле.

Ну да, qt умер ещё на 5 версии

Мне кажется, форк ядра - вопрос времени, и тут даже не в rust дело, а в некоторых событиях, связанных с его разработкой (опять же я не против использование rust в ядре при условии поддержки этого кода несколькими независимыми компиляторами, при этом чтобы хотя бы один не требовал llvm, так что пока что ждём пока gccrs доведут до ума).
Юзерский раст с его cargo же идёт лесом, про антипаттерн тут уже писали. Вот и gtk уже давно не стандатный тулкит, а кусок гнома, так что можно было бы его переписать быстро и безболезненно, но будет куча шума от неудачников, до сих пор использующих gtk. К слову gtk+ у меня в системе только второй версии и исползуется только legacy кодом из браузера

Проблемы сложных язков решаются глобализацией (ну или другим словом на ту же букву)

Интересно, а как ты определяешь, что я написал не своё мнение, а скопировал что-то откуда-то?

По содержимому, очевидно.

Ну, а у меня нет проблем с расчётом конструкции моста. Потому что я не проектирую их. Ровно как ты не пишешь программы, судя по всему.

Я пишу и продаю весьма дорогое, сложное и востребованное промышленное ПО.

Сильная типизация - объективное и полезное свойство ЯП

Полезное кому и для чего? Мне вот пофиг на сильность типизации. Она мне даже иногда сильно мешает при её наличии.

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

Я Си и другие языки использую вовсе не по причине наличия или отсутствия типизации.

Как будет gtk на расте, так можно поспорить, а пока из виденных тестов Си примерно на 25% быстрее раста с оптимизациями аналогичными расту. Да и может ли быть иначе, ибо С, фактически - это голый ассемблер…?

Я думаю тут сыграла банальная вещь: раст стали нарекать убийцей С/С++, на этом его путь был определен как трудный и тернистый))))

Насколько я могу помнить (всё же почти 30 лет прошло), Java тоже позиционировали как убийцу C++. И ничего, никто не жужжал. Были попытки сделать Java-CPU, ОС на Java. Ещё более безумные, чем нынешняя истерия с Rust, но всё же, шума не было. Негатива в сторону Java тоже особо не помню. М.б. тогда просто не состоял в каких-то сообществах.

Во-первых, 25% - это не смертельно. Разница не на порядки и даже не в разы. Во-вторых, скорость исполнения - это не единственный критерий в разработке. В-третьих, все бенчмарки показывают одно (синтетику), а в реальных приложениях, из сотен тысяч строк, со сложной бизнес-логикой, со сложными взаимосвязями, производительность всегда ведёт себя иначе, чем в бенчмарке.

Негатива в сторону Java тоже особо не помню.

А как же https://pastebin.com/DX20rb5S

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

Во-первых, 25% - это не смертельно

Очень субъективно. Не все могут ждать, когда частоты cpu повысятся хотя бы на 25%, притом что не факт, что при этом достаточно возрастёт производительность конкретного алгоритма

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

Бизнес-логику и на коболах пишут, но не всем интересно, какой там в целом бардак творится

Java тоже позиционировали как убийцу C++

Я про это тоже говорю, нашел java свою нишу и С/С++ не мешается и не пересекается, вот думаю и с растом так будет))))

gtk на расте

Их там с десяток уже наклепали, любой из них на голову, как минимум, лучше жкт(это не описка), хотя бы тем что не на сишке, и аналог Qt пилят, кутешники же и пилят если чё.

виденных тестов Си примерно на 25% быстрее раста

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

с оптимизациями аналогичными расту

Си принципиально не может в оптимизации «аналогичные расту» - типами не вышел

ибо С, фактически - это голый ассемблер

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

Их там с десяток уже наклепали

Это не считается, должна быть объявлена новая версия gtk, а старая должна лишиться поддержки вот прям ещё вчера. В добавку должна объявиться какая-нибудь страшная RCE с переполнением буффера, из-за которой старый gtk должен считаться небезопасным и быть закопанным тут же, как это было с rsvg

На реальном софте с некотоых пор стабильно наоборот

но только на определённой машине с определённым процессором и опциями компилятора, сишный код, использующийся для сравнения следует собирать БЕЗ ОПТИМИЗАЦИЙ

Си принципиально не может в оптимизации «аналогичные расту» - типами не вышел

Зато умеет в strict aliasing

Это тот кто заюзал лор только (больше нет сообщений) для рекламы своих книжек?

Нет, ещё для распространения своих шизоидных идей

Тут либо так, либо прием граждан с черного хода как в мире раста.

Чем тебя Си то так обидел?)))) Си еще как может в оптимизации как раст, просто в Си ручками делать нужно, а из коробки все как есть.

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

То, что наклепали в линуксе на расте, не является чем то важным, критика вся на Си написано и это не изменится, ибо дальше только асм…

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

А что тебе в типах Си не зашло, вот тут я не понял…?

Насколько я могу помнить (всё же почти 30 лет прошло), Java тоже позиционировали как убийцу C++. И ничего, никто не жужжал

Что характерно, так и вышло. Жаба и потом .net убили C++ наглухо в куче сегментов и новые проекты, для которых раньше использовали C++, стали писаться на этих язычках.

С Rust выйдет аналогично: нового кода, где раньше использовали бы сишечку, на Rust будет больше.