t1ha (Fast Positive Hash) реализован на Rust

Rust-версия бенчмарка не считает такты CPU, а делает замеры исключительно по «wall clock».

Из этого следует только одно - раст-адепт ничего не знает об оптимизации и является героев копипасты.

Я не поленился и глянул код генерируемый компилятором Rust.

Нету у раста компилятора - тебя обманули. Компилятор там llvm, поэтому он должен показывать результаты clang"а - если недоязычок не показывает результаты шланга - он говно убогое, т.к. он по умолчанию должен это делать.

gcc/clang довольно плохо разворачивает граф переходов и не делает каких-то оптимизаций.

Если clang показывает результаты лучше раста - раст это не язык, а говно т.к. по методичке он должен быть эквивалентным крестам/си.

К тому же, никакие переходы clang не разворачивает - их разворачивает llvm, и если их в говноврасте он не смог развернуть - недоязычок говно.

Сорри, тредом ошибся.

Тебе в методичке не расказали про string_view, пару итераторов и std::span? Ну дак вот, сообщаю тебе новость - иди обнови методичку.

std::span

since C++20. Я конечно люблю всё новое, но в С++ как всегда всё попадает с диким опозданием. Они даже std::optional держат в experimental до сих пор, хотя надо было внести его во все компиляторы лет эдак 20 назад, это же простая как 1+1 и ничего не ломающая штука.

никакие переходы clang не разворачивает - их разворачивает llvm

Не все оптимизации можно отложить на уровень ассемблера llvm.

если их в говноврасте он не смог развернуть

llvm не гениален, его дописывать под новые языки нужно.

Так, ты там покажешь мне «все компиляторы раста», либо покажешь стандарт раста? Ты перепутал методичку, клоун. У раста нет компиляторов и стандарта - поэтому я могу брать любые вещи из любого компилятора и ты будешь оправдываться, балабол.

Не все оптимизации можно отложить на уровень ассемблера llvm.

Неверно, отрыжка ввиде раста не делает никаких оптимизаций на уровне фронтенда.

llvm не гениален, его дописывать под новые языки нужно.

А, т.е. под твой недоязычок кто-то должен поправить llvm, да ты совсем упоролся.

В конечном итоге раст опять обосрался, что не ново.

Ты перепутал методичку

Да нет же, я про С++ и то как его компиляторы нарушают стандарт, отказываясь компилить std::optional

под твой недоязычок кто-то должен поправить llvm

Ну да, под какие-то кресты правят сами, а под всё остальное там плугины писать разрешили.

Вообще сам я не любитель llvm, как-то сложно там и туториалов маловато. Да и апи они вечно меняют. Жаль только альтернатив не особо то видно.

это же простая как 1+1

«Простая»? Ты видимо не читал историю развития optional, начиная с буста. Там головной боли хватило.

Ещё раз, в расте нет никакого стандарта и нет никакого компилятора. Почему в контексте крестов кукарекаешь про какие-то компиляторы и стандарты? Либо показывай их в расте, либо ты обосрался - одно из двух.

Я могу взять clang как С++ компилятор и любую возможность, которую даёт шланг и сравнивать это с растом. И это будет корректное сравнение. И ты как всегда обосрался.

Ну не знаю, во всяких хаскелах, окамлах и растах maybe/optional - основа основ и успешно заменяет null pointer. Если плюсы и такое не осилили, то что это за недоязык такой?

Ну да, под какие-то кресты правят сами, а под всё остальное там плугины писать разрешили.

Ну дак где твои правки, балабол? Нету, а чего так? С++ никакие правки от раста не нужны, а почему расту от С++ нужны правки? Как там - методичка не жмёт?

Вообще сам я не любитель llvm, как-то сложно там и туториалов маловато. Да и апи они вечно меняют. Жаль только альтернатив не особо то видно.

Ой, наши раст-ламерки не могут сделать свой llvm? Свой компилятор? Надо воровать крестовый код? А чего так? 10лет+, а llvm"а нет? Опять обосрался? Ну бывает.

К тому же, тебе даже придумывать llvm не нужно - просто перепащивай готовый крестовый код на раст, как адепт перепастил t1ha, но вы даже этого не можете.

Чего же вы все такие убогие? Вас прям там специально таких обирали, немощных?

Сообщаю тебе новость, колхозник, опционал никакая не замена null pointer и никакого null в крестах нет. Ты перепутал методичку.

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

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

А хотя наверно гоню, проблемы были (и отчасти есть) с variant. Но всё равно сравнивать с окамлом-хаскелем не очень-то уместно, там сборка мусора и изначальная ориентация на этот стиль.

показывай их в расте

В том посте я не говорил о том, что раст круче плюсов. Я говорил о том, что С++ - отстой. А кто уже там его заменит, раст или хаскель - другой разговор. По крайней мере в расте слайсы добавили раньше 2020 года)).

опционал никакая не замена null pointer

Всякий раз когда сишник хочет сказать что в переменной значения нет, он переделывает ее в указатель и запихивает туда nullptr. Все нормальные растовики, окамлисты и хаскелисты заворачивают в оптионал. Ну есть еще котлинисты и валисты, которые дорисовуют вопросик у типа. Но тем не менее сишник (да и джавист тоже) получает очередную возможность выстрелить себе в ногу, а все остальные корректно выражают понятие «отсутсвие значения».

В том посте я не говорил о том, что раст круче плюсов.

Т.е. ты обосрался - ну это не ново.

Я говорил о том, что С++ - отстой. А кто уже там его заменит, раст или хаскель - другой разговор.

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

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

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

Всякий раз когда сишник хочет сказать что в переменной значения нет,

Ты обосрался клоун. nullptr - это уже значение переменной. С какими идиотами бездарными я говорю - это просто ужас. Откуда тебя такого тупого откопали? Что не адепт раста - тупой как полено.

Но тем не менее сишник (да и джавист тоже) получает очередную возможность выстрелить себе в ногу, а все остальные корректно выражают понятие «отсутсвие значения».

Какое значение, мамка птушная, ты перепутал null из жавы и NULL из си. Опять обосрался - иди читай методичку заново.

бегом побежал показывать.

Ага, побежал. Во-первых мне вообще посрать на наличие стандарта. Если мне надо я и язык готов форкнуть у себя на винте и писать на чем хочу. Ну а компилятор раста так и быть один покажу: curl https://sh.rustup.rs -sSf | sh

Во-первых мне вообще посрать на наличие стандарта. Если мне надо я и язык готов форкнуть у себя на винте и писать на чем хочу.

Тогда, макака, ты обосралась - т.к. std::span есть - ты можешь его форкнуть у себя на винте и писать. Молодец, прям себе на рожу нассал.

Ну а компилятор раста так и быть один покажу: curl https://sh.rustup.rs -sSf | sh

Нет бездарность, не компилятор, а компиляторы, макака. Ты кукарекала про компиляторы С++ - дак вот побежала показывать компиляторЫ раста. Компилятором своим ты можешь себе только жопу подтереть.

nullptr - это уже значение переменной

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

ты перепутал null из жавы и NULL из си.

NPE конечно лучше сегфолта, но тоже выстрел в ногу.

компиляторы

Типа дайте два? А зачем? Один компилятор другим компилировать?

std::span есть - ты можешь его форкнуть у себя на винте и писать.

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

Если плюсы и такое не осилили, то что это за недоязык такой?

наверное, с неявными кастами как-то конфликтует

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

Современный С++ - это уже синтаксическая каша, которую тяжело оптимизировать.

А аргументы в стиле «А ты не используй это! Пиши правильно!» тогда зачем мне нужен С++, если есть уже готовый и прекрасный С!??

Когда мы говорим о каких-то там «плечах», то мы имеем «С с классами»,а не C++.

Rust выигрывает в 5 тестах у С++, в 2 тестах примерно одинаково, и только в 3 выигрывает С++.

Чтобы насчитать аж 5 тестов, где «Rust выигрывает», ты должен был отнести к этому и случай «spectral-norm: Rust 1.97 - C++ 1.98». Почему тогда случаи «fannkuch-redux: Rust 10.15 - C++ 10.12» и «fasta: Rust 1.47 - C++ 1.33» ты назвал «Rust и C++ примерно одинаковы», а не «выигрывает С++»?

Вся суть растофанатиков.

Вообще то про то что Ява не совсем компилятор и требовать от нее скорости компилятора как то неправильно.

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

Извините что придираюсь но человек с таким же успехом мог после Явы поставить запятую и написать к примеру Питон.

Но он этого не сделал значит понимает бессмысленность этого, но в случае Явы почему-то не понимает.

Так кстати будет сравнение этого алгоритма с его ГО реализацией хотя бы ?

Они даже std::optional держат в experimental до сих пор

std::optional был принят в C++17 и доступен во всех компиляторах, которые C++17 поддерживают.

std::optional был принят в C++17 и доступен во всех компиляторах, которые C++17 поддерживают.

Таки да. Но вроде совсем недавно было иначе и флаг -std=c++17 не помогал. Или я попутал что?

Но вроде совсем недавно

«Совсем недавно» в контексте 34-х летнего существования C++ — это не очень понятное определение. std::optional из коробки доступен, как минимум, в clang-6, gcc-7 и vc++ 15.9. Т.е. с весны 2018-го, уже год как.

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

У Rust действительно весьма «легковесная» обработка ошибок. Но за это придётся платить терпением - каждый случай ошибки нужно обрабатывать явно. Некоторые избегают этого, используя unwrap() или, в лучшем случае expect(). Но эти функции вызывают панику, поведение которой по-умолчанию похоже на throw из C++. Впрочем, стоит отметить, что поведение можно поменять на abort.

Современный С++ - это уже синтаксическая каша, которую тяжело оптимизировать.

Любой развивающиеся язык рано или поздно станет «синтаксическо кашей», если не принять для этого разграничительных мер, чтобы огородить новые практики от старых. В Rust для этого ввели edition. Ну, а в C++ среде, как вы уже отметили, предпочитают просто говорить:

«А ты не используй это! Пиши правильно!»

Как по мне, это основная проблема современного C++.

33 года без оптионал. Найс.

33 года без оптионал в stdlib

Fixed.

Кому был нужен optional в C++, те использовали его уже лет 15, минимум. Если не 20.

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

Да, это имеет место быть. Но.

В C++ средства для создания optional появились где-то в 1991-1992-ом годах, с созданием первых компиляторов с поддержкой шаблонов. Массово эти компиляторы стали доступны с 1994-1995-го. Формально шаблоны зафиксировали в стандарте в 1998-ом. В Boost реализация optional вошла в начале 2000-х.

Так что применять optional в C++ можно было очень и очень давно. Кому нужно было, тот это делал.

Собственно, по куче других направлений в C++ происходит то же самое: сеть, GUI, криптография, XML и т.д. и т.п.

PS. Покажите какой-нибудь другой мейнстрим язык из 1998-ого года, в котором была бы поддержка шаблонов/генериков и optional в стандартной библиотеке.

другой мейнстрим язык из 1998-ого года

В те времена уже и окамл придумали. Ну да, не совсем мейнстрим, идеи ML-семейства языков только недавно начали входить в моду.

PS. Покажите какой-нибудь другой мейнстрим язык из 1998-ого года, в котором была бы поддержка шаблонов/генериков и optional в стандартной библиотеке.

Хитрий ход. Любой ответ на этот вопрос можно отвечать что он не mainstream ;) А так конечно например Haskell: parametric polymorphism, Maybe. И psst, изначально нет Null. К каждому типу подходить с головой надо и определять нужные его инвариации.

идеи ML-семейства языков только недавно начали входить в моду.

Идеи ML-семества использовались для внесения в C++ тех же шаблонов.

Хитрий ход.

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

Когда язык является мейнстримом, то это ведет, как минимум, к следующим последствиям:

1. Языком пользуются разные люди с совершенно разными требованиями к языку. И сам язык применяется в широком спектре областей.

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

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

Так что пока про Rust больше говорят, чем его используют, Rust может развиваться так динамично, что релизы выходят каждые 1.5 месяца. А когда пройдет лет 15-20 пребывания Rust-а в мейнстриме (чего еще нужно дождаться вообще-то), вот тогда посмотрим, как быстро Rust сможет вбирать новые идеи и подходы.

А когда пройдет лет 15-20 пребывания Rust-а в мейнстриме

Тогда будут орать, что раст гавно, а ЯзыкИкс рулит. В то время как про С++ вспоминать будут только старички вроде нас (как про фортран сейчас вспоминают). Так что всем кто доживет предлагаю, вместо того, чтоб вбирать новые идеи в устаревший язык, присоеденятся к молодежи и орать с ней вместе про новые языки. А раст - его сегодня уже надо узать в хобби-проектах.

Тогда будут орать, что раст гавно

В том-то и дело, что говорить будут. Но сам инструмент при этом таковым не будет.

В то время как про С++ вспоминать будут только старички вроде нас (как про фортран сейчас вспоминают).

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

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

Ну, если дело только в поорать, то нет проблем. Трындеть — не мешки ворочать.

Главное подходить к процессу спокойно, созерцательно.

Да, да, конечно. Также я подошел к haskell.

Теоретически можно использоваться BigInteger, но вместо _одной_ инструкции умножения в ~100 раз больше.

Теоретически никто не запрещает оптимизировать «малоразрядные» подмножества bigint, примерно как это сделано с интами.

Код, который генерится JIT-ом яваскрипта не имеет ничего общего с тем, что может себе представить нормальный здоровый человек :)

Подробности в студию. У них какие-то явные проблемы или теоретические исследования не закончены?

У всех одна либа была в то время - boost.

Сложность optional в плюсах - то, что это value type. То есть если я делаю копию, то копируется содержимое, например, будет вторая строка, которую я могу снять независимо. И он может полностью быть на стеке. Там, где остальные языки используют nullptr копируется только указатель, который будет указывать на тот же самый объект что ведёт к сложностям когда надо использовать в разных потоках.

Конечно, если строки и массивы immutable, такой проблемы не будет, но не будет возможности оптимизировать меняя содержимое in place.

Царя не переспоришь. Царь - пиши ещё!

Сложность optional в плюсах - то, что это value type.

Нет там никакой сложности. Если потребуется быстро копировать или тип еще не известен или еще что такое, всегда можно использовать std::optional<P*> или даже std::optional<std::shared_ptr<P>>. Другой вопрос в том, нафига такое в С++, если указатель сам по себе optional. Вот собственно наверно и есть основная причина малой нужности optional в плюсах (особенно учитывая отсутсвие паттернматчинга, без которого обращение с оптионалом в принципе ничем не отличается от обращения с указателем).

Ты совсем не разбираешься в вопросе. Почитай ещё раз внимательно что я написал.