Ну так трекать время жизни переменных для рантайма раста буквально zero-cost.
Это неверное утверждение. Как я уже говорил — эти конструкции и тезисы валидны ТОЛЬКО в рамках внутренней логики раста, которая сводится к «запрещаем множественные ссылки — нет проблем», «запрещаем отделять скоуп от потока выполнения — нет проблем».
Т.е., если попроще — этот тезис существует в рамках модели, которая накладывает множество ограничений со стороны возможностей. Это ограничения НЕ ПОЗВОЛЯЮТ РЕАЛИЗОВАТЬ что-то НАСТОЛЬКО ЖЕ ЭФФЕКТИВНО как в случае, КОГДА ЭТИХ ОГРАНИЧЕНИЙ НЕТ.
Таким образом абсолютно неважно что там стоит какой-то там мифический тректинг — важно лишь одно — позволит ли этот тректинг делать то, что можно делать без него. Ответ очевиден — нет. Поэтому он вызывает оверхед и не является zero-cost.
Это вообще типичная методика манипулирования. Когда мы выделяем какую-то подзадачу и говорим «ну дак время её выполнения не изменилось», постоянно всем этим тыча. Но, это никого не волнует, ведь нас не интересует время выполнения под-задачи — нас интересует время выполнения задачи. А ваше решение задачи усложняет(т.е. замедляет) все остальные(некоторые другие) подзадачи.
Таким образом, в рамках одно части задачи разницы нет, а в рамках всей задачи — разница есть.
Что с этим не так?
Ну ведь я уже десять раз объяснял. Но ваши ответы, скорее всего, связаны не с «непониманием разницы», которую(разницу) я декларирую, а с идеологическими проблемами.
Т.е. у вас есть тезисы, которыми вы пытаетесь крыть мои. Все эти тезисы работают только в заранее ограниченном фентезийном мире, т.к. мы убираем всё неудобное и оставляем удобное. А далее нам нужно просто попытаться завести оппонента в этот фентезийный мир, чтобы он начал обсуждать какой-то нелепые и никому не интересные трекинг, вместо реальных проблем и задач. Не нужно делать так.
То, что следует из этого понятия. Это значит, что написать «в рамках абстракции» я могу так же эффективно, как «в обход абстракции». Любые ограничения, которые забирают у кода эффективность — не являются zero-cost. Даже крестовое raii не является zero-cost. И для поддержания хотя-бы минимальной эффективности нужно постоянно латать абстракции.
Очень часто что раст-адепты, что крестовые адепты определяют zero-cost как «если мы напишем такой же код, который обеспечивает нашу абстракцию, то он не будет быстрее».
Пример я уже приводил выше. Допустим, у нас есть объекты, которые создаются и удаляются. Абстракции работает с памятью как с неким ресурсов, уникальным для каждой каждой аллокации, а значит должна для каждой аллокации делать обратную операцию.
Под абстракциями всё не так — я могу снести хоть весь хип. И никакой обратной операции вызывать не нужно. Это уже оверхед.
Да, подобные проблемы можно залатать добавив ещё одну абстракцию, которая будете эмулировать деаллокацию, а далее сносить всё махом, но всё это уже за рамками базовых абстракций, костыли и всё равно требуют оверхеда.
Да, эти хаки можно(в каких-то случаях) сделать и на уровне имплементации самой абстракции, но это всё происходит тогда, когда кто-то обжёгся и кто-то придумал и рассчитывать на это нельзя. К тому же — это отнимает предсказуемость и лишает возможности вообще понимать «как работает».
Подобными хаками раст-адепты очень часто обманывают и пускают пыль в глаза зелёным сишно-крестовым адептам, которых, на самом деле, очень просто обмануть и запутать.
Но факт остаётся фактом — ты не можешь рассчитывать на это(как минимум тебе нужно знать все существующие оптимизации в stdlib, что уже почти невозможно сделать), это работает в самых примитивных с случаях и работает очень плохо.
Поэтому, как только кто-то пытается повторить на расте(и подобных «безопасных» изваяниях) реальный zero-cost, когда какой-то адепт будет перепащивать очередной сишный/крестовый код — он будет заниматься сплошным взломом абстракций, либо на уровне stdlib, либо на уровне своего кода.
Я человек простой, clang — compiler front end для C++, а rustc — compiler front end для Rust. Не?
Не, вопрос был в том, что «раст более портируемый» и как мы выяснили «фронтенд сложнее милд/бек-ендов». И то и то опровергается.
А llvm часть инфраструктуры крестов, создавался для шланг и под шланг. Шланг настолько же портируемый как кресты/си, т.к. зависим только от них. Шланг написан на крестах, а значит является полноценный компилятором на крестах.
К тому же, куда подевался тот же gcc? А это топ1 компилятор.
Ответить нечего — так и запишем. Вас поймали на вранье и как всегда, вместо ответов я увидел оправдания. К тому же, это не я побежал себя минусовать без малейших объяснений. А если кто-то бежит минусовать меня и минусовать какого-то балабола в интернете, который наврал — это адепты, это сектанты и я имею полное право их так называть.
Поэтому, вам просто не повезло ответить мне и результат чего был ожидаем.
А вот и пошла типичная подмена понятий, адепты выдумывают новые значения понятия «компилятор».
С учетом того, что основная сложность Rust приходится именно на семантику языка и его систему типов, а не на кодогенерацию, то такое сравнение я считаю уместным.
Один тезис нелепей другого. У нас есть 4 компилятора, каждый «сложнее» кодогена и оптимизатора, т.е. llvm«а, но почему-то без llvm»а никуда? Как же так? Неужели опять путаница в показаниях? Какая досада.
Но я сообщу адептам важную новость — компилятор, это то, что производит из исходного кода программу, причём программу релевантную.
К тому же, мы тут видим очередную попытку врать и игнорировать контекст от адептов. О чём говорилось там? О кол-ве таргетов и о том, что у раста нет компилятора на расте и он зависит от С/С++ и в компилтайме и в рантайме.
Что же нам предлагают адепты?
IntelliJ Rust и rust-analyzer,
Не компиляторы. Причём первый неизвестно на чём написан, т.е. уже проблема.
И того, кол-во реальных таргетов равно нулю. Количество компиляторов — равно нулю. Есть два транслятора — rust -> ir, rust -> С, к тому же второй не является полноценным(т.з. базовой методички, ведь (i.e. without borrow checking)).
Итого 4.
Главное верить, врать и плюсовать друг друга. В этом сила.
Компиляторов уже два. Посмотрите на github.com/thepowersgang/mrustc, пару месяцев назад проскальзывала статья, как они забутстраппились.
Об этом я написал выше.
А вы уверены, что вы правильно поняли семантику Rust? В С++ время жизни — это рантаймовое свойство,
Это всегда рантаймовое свойство. Это базовая семантика стека и чего бы вы там не придумали — оно этого факта не изменит.
тогда как в Rust это статическое свойство, известное на этапе компиляции. Стораджей-ссылок нет.
Это не более чем манипуляция. Можно что угодно называть чем угодно, но это ничего не изменит. «Стораджей-ссылок» есть всегда.
Да, вы правы. Поэтому когда в C++ замыкание захватывает объект по ссылке, а объект умирает, то ссылка оказывается вникуда. Конечно же это описано в требованиях к правильному использованию С++ замыканий, тем не менее это ментальный оверхэд, за которым надо следить самому.
Какие-то новые откровения. Почему мы все другие оверхеды игнорируем, а тут вдруг сразу «оверхед — и плохо»? К тому же, других решение нету. Но об этом позже.
И так как время жизни в Rust — это статическое свойство, известное на этапе компиляции, подсчет кол-ва мутабельных/иммутабельных ссылок стоит ровным ничего(прямо как С++ шаблоны)
Опять какие-то мантры и ни на чём не основанные утверждения. Можно мне пример с парой(активных) мутабельных ссылок? Можно мне пример подсчёта времени жизни без синтаксического мусора(с передачей объектов в функции и т.д.)?
компилятор может сделать вывод о том, будет ли объект, на который ссылается ссылка, жить достаточно
Он будет всегда жить недостаточно — это базовое ограничение стека. Его ничем и никак не обойти. Только оверхедом, но в этом случае вы запутались в показаниях.
чтобы замыкание/корутина/тред могли использовать ссылку или нет.
Они никогда не могут использовать ссылку, т.е. любой не-глобальный объект имеет непредсказуемое с т.з. замыкание/корутина/тред время жизни.
В Раст существует настоящая мув-семантика, например:
Любой адепт называет свою веру «настоящей», только это ничего не меняет. Где критерии «настоящий» и где обоснование этих критериев за «единственно верные»? Нету, ну это достаточно типичная ситуация.
Это сделано специально, чтобы избежать неопределенного поведения, присущего С++:
О боже, эти нелепые манипуляции. Когда в одном случае показывают одно, а в другом другое. Где идентичный код на С++? Нету, потому что «не получилось» и пришлось выдумать новый пример?
std::vector<std::string> v;
std::string str = "example";
v.push_back(std::move(str)); // str is now valid but unspecified
str.back(); // undefined behavior if size() == 0: back() has a precondition !empty()
Ещё более нелепые манипуляции. На кого это рассчитано? Какое отношение эти попытки имеют к move? Да никакого.
std::string str;
str.back(); // undefined behavior if size() == 0: back() has a precondition !empty()<
Опять попытки обмануть выдавая дефолтное поведение строки за следствие move? Для протокола поясню — метод back() не возвращает никаких ошибок, поэтому он не может сообщить об ошибке. Так сделаано для потому, чтобы не городить синтаксический мусор из которого состоит обработка ошибок на расте.
Итак, у нас есть мув-семантика, следовательно объекты можно действительно перемещать.
Ну манёвры я уже понял — поясню читателям. Есть данные — они хранятся в неком «локальном сторедже»(т.е. время жизни привязано к потоку выполнения). Эти данные перемещать никуда нельзя — только копировать.
Так что же такое перемещение? В объекте могут быть данные хранящиеся в глобальном сторедже(т.е. там, где их время жизни ничем не ограничено) — это некие ресурсы. В том же raii время жизни этих ресурсов привязывает к времени жизни объекта — это владелец ресурса. В базовом виде владелец всегда один и move — это и есть передача владения.
Мало того, что это уже оверхед и не zero-cost, т.к. привязка одного к другому может быть менее эффективно, нежели отсутствие каких-либо привязок, а следовательно отсутствие вообще какой-либо проблемы «времени жизни».
Два основных тезисы — все объекты из локального стореджа копируются ВСЕГДА. Все проблемы связанные с временем жизни — вызваны raii.
При перемещении стековых объектов возможно фактическое перемещение объекта на другой адрес
Оверхед. Ссылка предполагает передачу без копирования. move — копирование. Никаких «фактическое», «перемещение» и прочих нелепых базвордов — не существует. Это всё про ресурсы, а не объекты в локальном сторедже(стеке).
и если в объекте есть поля-ссылки на свои же поля (самоссылающиеся структуры), то перемещение объекта приведет к инвалидации этих ссылок (указывают на старый адрес).
Опять же, подмена понятий. Не перемещение, а копирование. Перемещение — это про глобальные ресурсы, у которых адреса никак не изменяются.
Кстати, тут можно заметить — как человек игнорирует некий основной момент. Дело в том, что "(самоссылающиеся структуры)" — это не единственный кейс, в котором происходит «инвалидации этих ссылок». Любая ссылка на объект — это уже та самая "(самоссылающиеся структуры)" и любое «перемещение» объекта — вызовет инвалидацию всех ссылок на этот объект.
Именно поэтому там выше выдаётся убогость за плюс:
После перемещения обращаться к b переменной нельзя.
Из этого следует, что b уже ссылка, а не сторедж. В любом случае — это инвалидирует все ссылки на b. Ах да, как я могу забыть — мы же можешь жить в мире поней, где «ссылки иметь нельзя» и в этом мире всё нормально. Только это не более, чем убогие абстракции, которые никоим образом не являются zero-cost.
Если это самоссылающаяся структура на стеке, то ее нельзя перемещать.
Копировать — опять манипуляции. Копирование — уже оверхед. Ссылочная передача не вызывает копирования и не приводит к оверхеду. На этом уже можно закончить, вы уже запутались в показаниях.
Пользоваться такой корутиной можно, но локально.
Это не имеет смысла. В этом случае всё можно передавать по ссылкам, не получая никакого оверхеда.
Ее можно создать на стеке, но нельзя возвращать из функции и нельзя перекидывать в другую переменную по типу let a = b.
За этими нельзя следит компилятор без пенальти для рантайма, без UB, полностью zero-cost.
Опять какие-то нелепые манипуляции. Это типичная тактика — сражаться с соломенным чучелом. Кто и где говорил, что отслеживание подобного вообще кому-то интересно? Я об этом говорил? Нет. Сам придумал — сам опроверг, как говориться.
К тому же, оверхед здесь есть и я об этом сообщил выше — «копирование», которое тут манипулятивно называется каким-то «перемещением».
Хотя ладно, я разоблачу и эту историю. Дело в том, что в подобных попытках все рассуждения существуют в рамках подложного контекста. Допустим, в данном случае предполагается, что поток управления — основание, под которым ничего нет.
В реальности же, я могу сделать что угодно — хоть привязать время жизни стека к времени жизни корутины, хоть скопировать контекст, хоть остановить поток на уровне ОС. Очевидно, что ничего из этого подобные схемы не учитывают, но адептами подобных изваяний выдаются за «аналоги», либо за полные(т.е. те, которые учитывают всё).
В Rust реализовали оба, пользуйся любым.
Опять же, тут видно явные подлоги. Адепт выдумывает какие-то два случая, которые существуют в рамках его фентейзиного мира, но при этом выдаёт их за реально — т.е. будто был ТОЛЬКО эти два случая существуют. На самом деле нет, и об этом я уже говорил выше.
Дак мало того, что два случая — вранье, дак ещё и каждый случай — враньё. На самом деле тут прослеживается типичная тактика, когда адепт какого-то учения говорит тезисами понятиями этого учения, которые непротиворечивы в рамках этого учения(этого понятийного аппарата). Но проблема в том, что мне как-то вообще не интересно это учение и эти понятия никак не соотносятся с реальным миром, и их «внутренняя корректность» никак и ничего не означает.
Т.е. это обычный такой фентезийный мир, где существует какая-то физическая модель и всё повествование ей соответствует. А далее приходит подмена контекста, мы подменяем мир фентезийный на мир реальный, в котором действуют совершенно другие законы и существуют совершенно другие понятия. И вся аргументация адептов этого мира сводится к жонглированию этими самыми фентейзиными понятиями и упование на их корректность. Но они не работают за рамками контекста(фентезийного) и за рамками контекста(фентезийного) адепт ничего не знает, именно поэтому он всегда пытается затащить оппонента в этот самый контекст. Это всегда очень явно прослеживается в спорах с подобными людьми. Это видео и тут.
Почитайте статьи, это действительно увлекательное чтиво.
Банальная попытка накрутить значимости очередной нелепости, делая вид «какой же оппонент тупой — не читал такого чтива».
std::pin — это возможность дать компилятору инфу о том, можно ли перемещать объект или нет. Т.е. история с «переместить стековую корутину нельзя, а хиповую можно» было описано чисто языковыми средствами, а не захардкожено в компиляторе.
Тут мы видим опять какие-то глупые попытки манипулировать, выдавая убогость за плюс. Но я расшифрую это.
Мы просто запретили всё, но срочно понадобилось решение проблемы. Поэтому наделали unsafe-хаков, и везде раструбили о том, что «мы нашли решение» — на самом деле нет. Это значит только одно — начальная модель несостоятельна, раз требуется её взламывать. Но вера есть вера.
На самом деле это фундаментальная манипуляция на котором основан раст. Раст разделён на два языка — язык на котором НИЧЕГО НЕЛЬЗЯ НАПИСАТЬ(базовый), и язык на котором НАПИСАТЬ ЧТО_ТО МОЖНО(unsafe). Как дальше действуют адепты, т.к. на базовом языке ничего написать нельзя, то они пишут на unsafe-языке базовые примитивы, а далее выдают их корректность за корректность языка(на самом деле тут такой же подлог. Корректность модели — не означает корректность имплементации). Далее, путём компоновки этих примитивов уже пишется код на базовом языке.
По-сути они пытаются впарить корректность библиотеки за корректность языка, сравнивая это с тем же С++. В С++ любые библиотеки так же корректны, но в чём заключается подлог? А подлог заключается в том, что язык не разделён на два, хотя раст тоже не разделён на два, но его адепты всегда поют мантру «unsafe всегда видно» и это единственное отличие их языка от любого другого.
А далее происходит ещё более нелепая схема. «ты в крестах можешь передать по ссылке и сломать, а у нас не можешь», только вот адепты тебе не скажут, что «не можешь» относится не к «сломать», а к «передать».
Их модель не работает с исключениями? Зачем исключения — мы придумаем очередную мантру и будем в неё верить. Мы придумаем свои трактовки zero-cost, будем всегда врать и подменять понятия.
Тепло встретят, помогут, подскажут, разжуют, объяснят. Без смс и без регистрации =)
Это как? Будут минусовать неугодынх и плюсовать своих, которые засирают те темы, которые к ним никакого отношения не имеют? Плюсовать просто пофакту того, что «мы одной веры»? О да, всегда мечтал о таком.
И таки теперь это решение в стабильной версии компилятора.
В чём смысл достижения? Это банальность банальная — константный указатель. К тому же, в ситуации с C++ — это вообще ненужно, т.к. ссылка итак pinned. Это какая-то борьба с расто-проблемами не актуальными в С++? Или это действительно такая наивность?
К тому же, это никак не решает проблему времени жизни — если локальный сторедж для объекта умрёт — объект умрёт. А временем жизни этого стореджа — управлять нельзя. Управлять временем жизни можно только в глобальном сторедже — т.е. в хипе. А это уже оверхед и подобные рассуждения:
без UB, без проверок в рантайме, полностью zero-cost и без пенальти)
По умолчанию являются несостоятельными.
К тому же, все всегда забывают, что «ограничение» — есть оверхед и никакого zero-cost уже нет. Допустим, если мы вводим ограничение на кол-во мутабельных ссылок — это уже оверхед и не zero-cost и любые попытки назвать это zero-cost — враньё и манипуляции.
К тому же, существует так же синтаксический оверхед, который адептами раста постоянно игнорируется. Если какое-то решение требует от меня во много раз больше синтаксического мусора, нелепой помощи компилятору и прочей борьбы с ограничениями и костылями — это решение не может сравниваться с другим решением без учёта этих нюансов. А это очень важные нюансы.
Да, настоящее время раст имеет ровно один компилятор — но это не значит, что так будет всегда.
Какая глупость.
Да, настоящее время с++ имеет ровно проблемы — но это не значит, что так будет всегда.
Поздравляю, вы умножили на ноль основной довод к существованию раста, который каждый день ретранслируется на хабре.
Так что ваше высказывание — неверно просто по факту
Оно верно по-факту. И вы даже не сообщили в чём именно оно неверно.
да, таки раст может-таки поддерживать архитектуры, которые не умеет поддерживать LLVM — просто так получилось, что сейчас — это не так.
Какие основания у этого утверждения?
В конечном итоге я так и не увидел основания для «неверно». К тому же, как всегда был проигнорирован основной тезис, а именно «без бубна компилируются под разные архитектуры.» — тут говорится именно о лучшей портируемости раста. Попытки вида «потом что-то будет» не работают, даже если в них поверить. Ведь он не просто должен быть портируемым на пару платформ, но и портироваться проще и шире(как минимум не уже).
Ну и конечно же, я мог бы сослаться на
без бубна компилируются под разные архитектуры
компилируются
Это настоящие время, а не фентезийное. И этого уже было достаточно для опровержения ваших рассуждений.
О, уже побежали минусовать адепты раста. Но я, специально для них, поясню. Компилятор раста имеет всего один таргет — это llvm-ir, но даже его он не генерирует самостоятельно. Таким образом ни о каких 10-15, да даже о двух архитектурах речи идти не может.
Так же, даже если мы забудем об этом факте — хост-компилятор раста зависит от С/С++ кода и не может быть более портабельным, нежели С/С++-код, т.к. напрямую зависит от него.
Так же, даже в рантайме раст зависит от llvm-рантайма и libc — таким образом тут он не может быть портабельнее С/С++ т.к. напрямую зависит от них и в рантайме.
Кто-нибудь из минусующих хочет объясниться? Все(по крайне мере я) хотят знать — почему то, что написано в комменте плохо, либо почему и с чем конкретные люди несогласны?
Действительно, в 7 шланге работает, даже в их транковом работает. В моём не работает. godbolt.org/z/usAV3s — тут(восьмая версия) аналогичная проблема. Значит где-то они что-то сломали.
Так же, если переписать цикл нормально:
cnt += (arr[i] == VAL);
Сразу заработала автовекторизация в шланге, а в gcc заработал openmp.
В любом случае — качество этой векторизации не особо высокое.
«zero idioms» — Как я понял это про полную элиминацию
Это про то, как add/xor и ещё много чего может иметь трупут 1/4 такта.
BM_SSE_COUNT_NG_NAIVESUMM_ARRAY 18.3 ns 18.3 ns 38331316
BM_SSE_COUNT_NG_NAIVESUMM 35.8 ns 35.8 ns 19558590
Я очень сомневаюсь в том, что подобная разница может существовать. Опять явно что-то не так.
Чуда не произошло — это самое медленное решение из всех, хуже обычного во много раз.
Шланг написал:
warning: loop not vectorized: the optimizer was unable to perform the requested transformation; the transformation might be disabled or specified as part of an unsupported transformation ordering [-Wpass-failed=transform-warning]
Судя по выхлопу gcc — он тоже не смог ничего векторизовать, но почему-то об этом не сообщил.
Возможно я не прав, но я вижу 64 * 2 + eps инструкций которые выполняются в цикле, причем это суммарно занимает 18 * 3.1 ~= 56 тактов на цикл, причем соотношение сохраняется при росте размера задачи (пока она влезает в L1).
Это попытка подбить неверное представление под результат. Для того, что такого не было — надо взять флоаты, где различия уже более существенны и даже в таком колхозе сложно что-то перепутать.
Реорганизация вычислений действительно может случатся, я не смотрел как написан libbenchmark (rdtscp?). Но даже rdtscp разрешает реордеринг, который может всё испортить, если компилятор развернет цикл бенчмарка.
Я не про это, а про реорганизацию вычислений в теле цикла, которому может(и делает) компилятор.
Этого уже должно хватать на 5/6 такта на 16 элементов, а если еще и они друг другу не мешают — то и 1/2 такта (во что я лично не верю, т.к. skylake на картинке только 3 INT Vect ALU).
Вообще трупут — это очень глупая метрика от интела. Хотя интел нигде не писал 1/4 такта — это скорее всякие таблицы. Но я дам объяснение — man «zero idioms».
По поводу всего остального — считаю, что там всё неверно. У меня сейчас нет времени на «почему?». Как будет — отвечу подробнее.
Через год оптимальные варианты станут менее оптимальными из-за нового AVX1024/AVX2048/…
Это ничего не меняет, это изменит лишь одну константу в нормальном коде, а в хорошем коде вообще само всё заработает.
Лучше критичные к производительности части выносить в отдельные функции, которые отдавать компилятору
Ну да, чтобы он не смог.
Объём программы не влияет на качество оптимизации отдельно взятой функции.
Дело не в объёме программы, а сложности задачи, которая вынесена в ту самую «функцию». С простой может повести, с чем-то более-менее сложным — поможет только чудо.
Зато код можно будет собрать при необходимости и под старые процессоры и под другие архитектуры.
Это итак работает без проблем. Допустим, мой код, который BM_SSE_COUNT_NG_NAIVESUMM — спокойно собирается и под старые процессоры и под другие архитектуры. Для автоматической поддержки AVX2/AVX512/AVX1024/AVX2048/… — там нужно только реализовать обобщённую функцию summ();
Далее можно поменять __vector_size__(16) на __vector_size__(32) и будет не sse, а avx2, на 64 — будет avx512.
И как я уже говорил — она без проблем собирается и для других процессоров/архитектур: godbolt.org/z/muBfnL
Для подобных вещей существуют специальные библиотеки, т.к. компиляторы обобщают не все возможности симдов.
Это неверное утверждение. Как я уже говорил — эти конструкции и тезисы валидны ТОЛЬКО в рамках внутренней логики раста, которая сводится к «запрещаем множественные ссылки — нет проблем», «запрещаем отделять скоуп от потока выполнения — нет проблем».
Т.е., если попроще — этот тезис существует в рамках модели, которая накладывает множество ограничений со стороны возможностей. Это ограничения НЕ ПОЗВОЛЯЮТ РЕАЛИЗОВАТЬ что-то НАСТОЛЬКО ЖЕ ЭФФЕКТИВНО как в случае, КОГДА ЭТИХ ОГРАНИЧЕНИЙ НЕТ.
Таким образом абсолютно неважно что там стоит какой-то там мифический тректинг — важно лишь одно — позволит ли этот тректинг делать то, что можно делать без него. Ответ очевиден — нет. Поэтому он вызывает оверхед и не является zero-cost.
Это вообще типичная методика манипулирования. Когда мы выделяем какую-то подзадачу и говорим «ну дак время её выполнения не изменилось», постоянно всем этим тыча. Но, это никого не волнует, ведь нас не интересует время выполнения под-задачи — нас интересует время выполнения задачи. А ваше решение задачи усложняет(т.е. замедляет) все остальные(некоторые другие) подзадачи.
Таким образом, в рамках одно части задачи разницы нет, а в рамках всей задачи — разница есть.
Ну ведь я уже десять раз объяснял. Но ваши ответы, скорее всего, связаны не с «непониманием разницы», которую(разницу) я декларирую, а с идеологическими проблемами.
Т.е. у вас есть тезисы, которыми вы пытаетесь крыть мои. Все эти тезисы работают только в заранее ограниченном фентезийном мире, т.к. мы убираем всё неудобное и оставляем удобное. А далее нам нужно просто попытаться завести оппонента в этот фентезийный мир, чтобы он начал обсуждать какой-то нелепые и никому не интересные трекинг, вместо реальных проблем и задач. Не нужно делать так.
Очень часто что раст-адепты, что крестовые адепты определяют zero-cost как «если мы напишем такой же код, который обеспечивает нашу абстракцию, то он не будет быстрее».
Пример я уже приводил выше. Допустим, у нас есть объекты, которые создаются и удаляются. Абстракции работает с памятью как с неким ресурсов, уникальным для каждой каждой аллокации, а значит должна для каждой аллокации делать обратную операцию.
Под абстракциями всё не так — я могу снести хоть весь хип. И никакой обратной операции вызывать не нужно. Это уже оверхед.
Да, подобные проблемы можно залатать добавив ещё одну абстракцию, которая будете эмулировать деаллокацию, а далее сносить всё махом, но всё это уже за рамками базовых абстракций, костыли и всё равно требуют оверхеда.
Да, эти хаки можно(в каких-то случаях) сделать и на уровне имплементации самой абстракции, но это всё происходит тогда, когда кто-то обжёгся и кто-то придумал и рассчитывать на это нельзя. К тому же — это отнимает предсказуемость и лишает возможности вообще понимать «как работает».
Подобными хаками раст-адепты очень часто обманывают и пускают пыль в глаза зелёным сишно-крестовым адептам, которых, на самом деле, очень просто обмануть и запутать.
Но факт остаётся фактом — ты не можешь рассчитывать на это(как минимум тебе нужно знать все существующие оптимизации в stdlib, что уже почти невозможно сделать), это работает в самых примитивных с случаях и работает очень плохо.
Поэтому, как только кто-то пытается повторить на расте(и подобных «безопасных» изваяниях) реальный zero-cost, когда какой-то адепт будет перепащивать очередной сишный/крестовый код — он будет заниматься сплошным взломом абстракций, либо на уровне stdlib, либо на уровне своего кода.
Не, вопрос был в том, что «раст более портируемый» и как мы выяснили «фронтенд сложнее милд/бек-ендов». И то и то опровергается.
А llvm часть инфраструктуры крестов, создавался для шланг и под шланг. Шланг настолько же портируемый как кресты/си, т.к. зависим только от них. Шланг написан на крестах, а значит является полноценный компилятором на крестах.
К тому же, куда подевался тот же gcc? А это топ1 компилятор.
Поэтому, вам просто не повезло ответить мне и результат чего был ожидаем.
Один тезис нелепей другого. У нас есть 4 компилятора, каждый «сложнее» кодогена и оптимизатора, т.е. llvm«а, но почему-то без llvm»а никуда? Как же так? Неужели опять путаница в показаниях? Какая досада.
Но я сообщу адептам важную новость — компилятор, это то, что производит из исходного кода программу, причём программу релевантную.
К тому же, мы тут видим очередную попытку врать и игнорировать контекст от адептов. О чём говорилось там? О кол-ве таргетов и о том, что у раста нет компилятора на расте и он зависит от С/С++ и в компилтайме и в рантайме.
Что же нам предлагают адепты?
Не компиляторы. Причём первый неизвестно на чём написан, т.е. уже проблема.
Первый вообще целиком и полностью на С++ и имеет его© в качестве таргета, второй генерирует llvm-ir при помощи llvm-рантайма.
И того, кол-во реальных таргетов равно нулю. Количество компиляторов — равно нулю. Есть два транслятора — rust -> ir, rust -> С, к тому же второй не является полноценным(т.з. базовой методички, ведь (i.e. without borrow checking)).
Главное верить, врать и плюсовать друг друга. В этом сила.
Об этом я написал выше.
Это всегда рантаймовое свойство. Это базовая семантика стека и чего бы вы там не придумали — оно этого факта не изменит.
Это не более чем манипуляция. Можно что угодно называть чем угодно, но это ничего не изменит. «Стораджей-ссылок» есть всегда.
Какие-то новые откровения. Почему мы все другие оверхеды игнорируем, а тут вдруг сразу «оверхед — и плохо»? К тому же, других решение нету. Но об этом позже.
Опять какие-то мантры и ни на чём не основанные утверждения. Можно мне пример с парой(активных) мутабельных ссылок? Можно мне пример подсчёта времени жизни без синтаксического мусора(с передачей объектов в функции и т.д.)?
Он будет всегда жить недостаточно — это базовое ограничение стека. Его ничем и никак не обойти. Только оверхедом, но в этом случае вы запутались в показаниях.
Они никогда не могут использовать ссылку, т.е. любой не-глобальный объект имеет непредсказуемое с т.з. замыкание/корутина/тред время жизни.
Любой адепт называет свою веру «настоящей», только это ничего не меняет. Где критерии «настоящий» и где обоснование этих критериев за «единственно верные»? Нету, ну это достаточно типичная ситуация.
О боже, эти нелепые манипуляции. Когда в одном случае показывают одно, а в другом другое. Где идентичный код на С++? Нету, потому что «не получилось» и пришлось выдумать новый пример?
Ещё более нелепые манипуляции. На кого это рассчитано? Какое отношение эти попытки имеют к move? Да никакого.
Опять попытки обмануть выдавая дефолтное поведение строки за следствие move? Для протокола поясню — метод back() не возвращает никаких ошибок, поэтому он не может сообщить об ошибке. Так сделаано для потому, чтобы не городить синтаксический мусор из которого состоит обработка ошибок на расте.
Ну манёвры я уже понял — поясню читателям. Есть данные — они хранятся в неком «локальном сторедже»(т.е. время жизни привязано к потоку выполнения). Эти данные перемещать никуда нельзя — только копировать.
Так что же такое перемещение? В объекте могут быть данные хранящиеся в глобальном сторедже(т.е. там, где их время жизни ничем не ограничено) — это некие ресурсы. В том же raii время жизни этих ресурсов привязывает к времени жизни объекта — это владелец ресурса. В базовом виде владелец всегда один и move — это и есть передача владения.
Мало того, что это уже оверхед и не zero-cost, т.к. привязка одного к другому может быть менее эффективно, нежели отсутствие каких-либо привязок, а следовательно отсутствие вообще какой-либо проблемы «времени жизни».
Два основных тезисы — все объекты из локального стореджа копируются ВСЕГДА. Все проблемы связанные с временем жизни — вызваны raii.
Оверхед. Ссылка предполагает передачу без копирования. move — копирование. Никаких «фактическое», «перемещение» и прочих нелепых базвордов — не существует. Это всё про ресурсы, а не объекты в локальном сторедже(стеке).
Опять же, подмена понятий. Не перемещение, а копирование. Перемещение — это про глобальные ресурсы, у которых адреса никак не изменяются.
Кстати, тут можно заметить — как человек игнорирует некий основной момент. Дело в том, что "(самоссылающиеся структуры)" — это не единственный кейс, в котором происходит «инвалидации этих ссылок». Любая ссылка на объект — это уже та самая "(самоссылающиеся структуры)" и любое «перемещение» объекта — вызовет инвалидацию всех ссылок на этот объект.
Именно поэтому там выше выдаётся убогость за плюс:
Из этого следует, что b уже ссылка, а не сторедж. В любом случае — это инвалидирует все ссылки на b. Ах да, как я могу забыть — мы же можешь жить в мире поней, где «ссылки иметь нельзя» и в этом мире всё нормально. Только это не более, чем убогие абстракции, которые никоим образом не являются zero-cost.
Копировать — опять манипуляции. Копирование — уже оверхед. Ссылочная передача не вызывает копирования и не приводит к оверхеду. На этом уже можно закончить, вы уже запутались в показаниях.
Это не имеет смысла. В этом случае всё можно передавать по ссылкам, не получая никакого оверхеда.
Опять какие-то нелепые манипуляции. Это типичная тактика — сражаться с соломенным чучелом. Кто и где говорил, что отслеживание подобного вообще кому-то интересно? Я об этом говорил? Нет. Сам придумал — сам опроверг, как говориться.
К тому же, оверхед здесь есть и я об этом сообщил выше — «копирование», которое тут манипулятивно называется каким-то «перемещением».
Хотя ладно, я разоблачу и эту историю. Дело в том, что в подобных попытках все рассуждения существуют в рамках подложного контекста. Допустим, в данном случае предполагается, что поток управления — основание, под которым ничего нет.
В реальности же, я могу сделать что угодно — хоть привязать время жизни стека к времени жизни корутины, хоть скопировать контекст, хоть остановить поток на уровне ОС. Очевидно, что ничего из этого подобные схемы не учитывают, но адептами подобных изваяний выдаются за «аналоги», либо за полные(т.е. те, которые учитывают всё).
Опять же, тут видно явные подлоги. Адепт выдумывает какие-то два случая, которые существуют в рамках его фентейзиного мира, но при этом выдаёт их за реально — т.е. будто был ТОЛЬКО эти два случая существуют. На самом деле нет, и об этом я уже говорил выше.
Дак мало того, что два случая — вранье, дак ещё и каждый случай — враньё. На самом деле тут прослеживается типичная тактика, когда адепт какого-то учения говорит тезисами понятиями этого учения, которые непротиворечивы в рамках этого учения(этого понятийного аппарата). Но проблема в том, что мне как-то вообще не интересно это учение и эти понятия никак не соотносятся с реальным миром, и их «внутренняя корректность» никак и ничего не означает.
Т.е. это обычный такой фентезийный мир, где существует какая-то физическая модель и всё повествование ей соответствует. А далее приходит подмена контекста, мы подменяем мир фентезийный на мир реальный, в котором действуют совершенно другие законы и существуют совершенно другие понятия. И вся аргументация адептов этого мира сводится к жонглированию этими самыми фентейзиными понятиями и упование на их корректность. Но они не работают за рамками контекста(фентезийного) и за рамками контекста(фентезийного) адепт ничего не знает, именно поэтому он всегда пытается затащить оппонента в этот самый контекст. Это всегда очень явно прослеживается в спорах с подобными людьми. Это видео и тут.
Банальная попытка накрутить значимости очередной нелепости, делая вид «какой же оппонент тупой — не читал такого чтива».
Тут мы видим опять какие-то глупые попытки манипулировать, выдавая убогость за плюс. Но я расшифрую это.
Мы просто запретили всё, но срочно понадобилось решение проблемы. Поэтому наделали unsafe-хаков, и везде раструбили о том, что «мы нашли решение» — на самом деле нет. Это значит только одно — начальная модель несостоятельна, раз требуется её взламывать. Но вера есть вера.
На самом деле это фундаментальная манипуляция на котором основан раст. Раст разделён на два языка — язык на котором НИЧЕГО НЕЛЬЗЯ НАПИСАТЬ(базовый), и язык на котором НАПИСАТЬ ЧТО_ТО МОЖНО(unsafe). Как дальше действуют адепты, т.к. на базовом языке ничего написать нельзя, то они пишут на unsafe-языке базовые примитивы, а далее выдают их корректность за корректность языка(на самом деле тут такой же подлог. Корректность модели — не означает корректность имплементации). Далее, путём компоновки этих примитивов уже пишется код на базовом языке.
По-сути они пытаются впарить корректность библиотеки за корректность языка, сравнивая это с тем же С++. В С++ любые библиотеки так же корректны, но в чём заключается подлог? А подлог заключается в том, что язык не разделён на два, хотя раст тоже не разделён на два, но его адепты всегда поют мантру «unsafe всегда видно» и это единственное отличие их языка от любого другого.
А далее происходит ещё более нелепая схема. «ты в крестах можешь передать по ссылке и сломать, а у нас не можешь», только вот адепты тебе не скажут, что «не можешь» относится не к «сломать», а к «передать».
Их модель не работает с исключениями? Зачем исключения — мы придумаем очередную мантру и будем в неё верить. Мы придумаем свои трактовки zero-cost, будем всегда врать и подменять понятия.
Это как? Будут минусовать неугодынх и плюсовать своих, которые засирают те темы, которые к ним никакого отношения не имеют? Плюсовать просто пофакту того, что «мы одной веры»? О да, всегда мечтал о таком.
Да. Как ещё можно что-то поменять в ядре и дефолтном окружении? Либо пишешь своё, либо ешь что дают — другого ms не предлагает.
В чём смысл достижения? Это банальность банальная — константный указатель. К тому же, в ситуации с C++ — это вообще ненужно, т.к. ссылка итак pinned. Это какая-то борьба с расто-проблемами не актуальными в С++? Или это действительно такая наивность?
К тому же, это никак не решает проблему времени жизни — если локальный сторедж для объекта умрёт — объект умрёт. А временем жизни этого стореджа — управлять нельзя. Управлять временем жизни можно только в глобальном сторедже — т.е. в хипе. А это уже оверхед и подобные рассуждения:
По умолчанию являются несостоятельными.
К тому же, все всегда забывают, что «ограничение» — есть оверхед и никакого zero-cost уже нет. Допустим, если мы вводим ограничение на кол-во мутабельных ссылок — это уже оверхед и не zero-cost и любые попытки назвать это zero-cost — враньё и манипуляции.
К тому же, существует так же синтаксический оверхед, который адептами раста постоянно игнорируется. Если какое-то решение требует от меня во много раз больше синтаксического мусора, нелепой помощи компилятору и прочей борьбы с ограничениями и костылями — это решение не может сравниваться с другим решением без учёта этих нюансов. А это очень важные нюансы.
Какая глупость.
Поздравляю, вы умножили на ноль основной довод к существованию раста, который каждый день ретранслируется на хабре.
Оно верно по-факту. И вы даже не сообщили в чём именно оно неверно.
Какие основания у этого утверждения?
В конечном итоге я так и не увидел основания для «неверно». К тому же, как всегда был проигнорирован основной тезис, а именно «без бубна компилируются под разные архитектуры.» — тут говорится именно о лучшей портируемости раста. Попытки вида «потом что-то будет» не работают, даже если в них поверить. Ведь он не просто должен быть портируемым на пару платформ, но и портироваться проще и шире(как минимум не уже).
Ну и конечно же, я мог бы сослаться на
Это настоящие время, а не фентезийное. И этого уже было достаточно для опровержения ваших рассуждений.
Так же, даже если мы забудем об этом факте — хост-компилятор раста зависит от С/С++ кода и не может быть более портабельным, нежели С/С++-код, т.к. напрямую зависит от него.
Так же, даже в рантайме раст зависит от llvm-рантайма и libc — таким образом тут он не может быть портабельнее С/С++ т.к. напрямую зависит от них и в рантайме.
Rust ничего не может поддерживать — поддерживает llvm.
Я не вижу тут векторизации.
Действительно, в 7 шланге работает, даже в их транковом работает. В моём не работает. godbolt.org/z/usAV3s — тут(восьмая версия) аналогичная проблема. Значит где-то они что-то сломали.
Так же, если переписать цикл нормально:
Сразу заработала автовекторизация в шланге, а в gcc заработал openmp.
В любом случае — качество этой векторизации не особо высокое.
Это про то, как add/xor и ещё много чего может иметь трупут 1/4 такта.
BM_SSE_COUNT_NG_NAIVESUMM_ARRAY 18.3 ns 18.3 ns 38331316BM_SSE_COUNT_NG_NAIVESUMM 35.8 ns 35.8 ns 19558590
Я очень сомневаюсь в том, что подобная разница может существовать. Опять явно что-то не так.
Шланг написал:
Судя по выхлопу gcc — он тоже не смог ничего векторизовать, но почему-то об этом не сообщил.
Там 4 строчки кода(пишется за пару минут), можете продемонстрировать «сторону openmp»?
cnt += (((int16_vec_t*)allignedArr)[i] == VAL) & 1;
cnt += (((int16_vec_t*)allignedArr)[i + 16] == VAL) & 1;
cnt += (((int16_vec_t*)allignedArr)[i + 32] == VAL) & 1;
cnt += (((int16_vec_t*)allignedArr)[i + 64] == VAL) & 1;
Очевидно, что это неверный код.
Это попытка подбить неверное представление под результат. Для того, что такого не было — надо взять флоаты, где различия уже более существенны и даже в таком колхозе сложно что-то перепутать.
Я не про это, а про реорганизацию вычислений в теле цикла, которому может(и делает) компилятор.
Вообще трупут — это очень глупая метрика от интела. Хотя интел нигде не писал 1/4 такта — это скорее всякие таблицы. Но я дам объяснение — man «zero idioms».
По поводу всего остального — считаю, что там всё неверно. У меня сейчас нет времени на «почему?». Как будет — отвечу подробнее.
Это ничего не меняет, это изменит лишь одну константу в нормальном коде, а в хорошем коде вообще само всё заработает.
Ну да, чтобы он не смог.
Дело не в объёме программы, а сложности задачи, которая вынесена в ту самую «функцию». С простой может повести, с чем-то более-менее сложным — поможет только чудо.
Это итак работает без проблем. Допустим, мой код, который BM_SSE_COUNT_NG_NAIVESUMM — спокойно собирается и под старые процессоры и под другие архитектуры. Для автоматической поддержки AVX2/AVX512/AVX1024/AVX2048/… — там нужно только реализовать обобщённую функцию summ();
Далее можно поменять __vector_size__(16) на __vector_size__(32) и будет не sse, а avx2, на 64 — будет avx512.
И как я уже говорил — она без проблем собирается и для других процессоров/архитектур: godbolt.org/z/muBfnL
Для подобных вещей существуют специальные библиотеки, т.к. компиляторы обобщают не все возможности симдов.