На самом деле, UB оказалось не нужно

АХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХАХААХААХААХАХААААХАХАХ

одно дело сейчас, другое - 40 лет назад

40 лет назад не было UB, потому что не было стандартов.

А разве UB не возникло из-за зоопарка платформ под которые должен был собираться код на C++? Я про всякие микроконтроллеры и тп сейчас.

Нет. Оно возникло, потому что стандарт делали наркоманы.

Ситуация, когда весь современный IT из громадных десктопного, мобильного и серверного сегментов рынка страдает потому что в каком-нибудь паршивом DSP от TI примерно 1989 года разлива в одном байте 16 бит и потому в компиляторе сделали неопределённым такое-то поведение ибо крутить байты так на нашем TI быстрее – действительно далека от адекватной.

Давно пора все UB привести к определённости в новых стандартах языка, а всё нытьё embedder’щиков с их экзотической питушнёй не брать во внимание. Пусть форкаются и возвращают себе неопределённость i++ + ++i в каких-нибудь C-- если им это надо.

Очевидное передёргивание:

Была проверена конкретная функциональность (UB exploitation optimizations) конкретного стека компиляторов (LLVM) на трёх конкретных серверных многопроцессорных платформах (AMD EPYC 9J14, Intel Xeon E5-2680, ARM64 Neoverse N1). Было показано, что для данных платформ вышеуказанная функциональность LLVM не даёт существенного прироста производительности.

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

Налицо набивка соломенного чучела (точнее, использование уже готового жупела «UB — это плохо и с ним надо бороться») и провокация флуда.

Язабан.

в каком-нибудь паршивом DSP от TI примерно 1989 года разлива в одном байте 16 бит

Они всё ещё живые. Например, DSP на основе C55x являются «active» и продаются даже по одной штуке. Разве что, бесплатную поддержку при дизайне новых проектов сравнительно недавно всё же отменили.

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

Исследователи из университета Бухареста и технического университета Лиссабона провели испытания с инструментарием LLVM, в котором была отключена эксплуатация UB, и оказалось, что производительность кода в результате изменилась крайне незначительно

Из чего напрашивается очевидный вывод что ллвм не умеет в оптимизацию.

Ну да, а ещё интересная ситуация, что программисты массово писали код «не по стандарту», рассчитывая на определённое поведение конкретных компиляторов.
И надо этот код объявить неправильным, вместо того чтобы поправить стандарт под распространённую(видимо удобную для программиста и для человеческого разума) практику.

Всего на 6-м комментарии, всё-таки ЛОР - сила! :)

Ннуууу... Я бы не путал в коде байт и слово.

А кроме amd64 и ARM других платформ и нету. RISC-V что-то не взлетает. Остальное всё сдохло. Так что всё норм.

Налицо набивка соломенного чучела (точнее, использование уже готового жупела «UB — это плохо и с ним надо бороться») и провокация флуда.

Хочешь сказать, UB – это хорошо, и его нужно больше?

Из чего напрашивается очевидный вывод что ллвм не умеет в оптимизацию.

Да нет, делать неработающий код через оптимизации с UB он умеет.

где без эксплуатации UB

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

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

Это только у ТС категоричность зашкаливает. Сами авторы исследования пишут, что не знаю, всё ли UB они отключили флагами, и действительно ли LLVM правильно реализует эти флаги.

а в некоторых случаях даже улучшилась.

То, что -fcheck-div-rem-overflow поднял производительность, так как код в цикле стал больше размером и его выровняло не по 16, а по 32 байта. Так что повышение производительности — повод пинать оптимизатор, а не UB.

Про неработающий яи не сомневаюсь.

Из чего напрашивается очевидный вывод что ллвм не умеет в оптимизацию.

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

Нет. Оно возникло, потому что стандарт делали наркоманы.

Если мне не изменяет память, то все вот эти странные приколы крестов именно из-за кучи платформ. Читал про это в Дизайн и эволюция C++.

RISC-V что-то не взлетает

Смотря у кого

В общем, по всему выходит, что тысячи и тысячи людей уже десятки лет страдают абсолютно зря

Я всегда писал что свидетели UB страдают зря. Сам к ним не отношусь и не страдаю, ни одна прога не сломалась.

Где-то таки взлетело?

В области микроконтроллеров RISC-V давно взлетел. Например RISC-V микроконтроллеры используются в SSD и видеокартах Nvidia.

Ситуация, когда весь современный IT из громадных десктопного, мобильного и серверного сегментов рынка страдает

… скоро разрешатся сама-собой, скоро вам дадут раст и «наслаждайтесь до полного»(С) :-)))))

а всё нытьё embedder’щиков

А вот этим как раз Си и оставят :) Ибо «а как?» :)

Ох и весёлая жЫсть наступит :) В том числе и у тебя EXL …

В области микроконтроллеров RISC-V давно взлетел.

Мне «нас-орда» было на ARM-ы пока они были вонтролеррами хЫдЫдЫ :) Сколько там - 30 лет заняло, чтоб? Удачи …

UB — это плохо и с ним надо бороться

Да автор (и его титулованный клон) вообще на этих UB рехнулся. Вбил сам себе в голову что для кого-то, кроме него, это огромная проблема и страдания и носится с этой идеей.

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

Наверно с начальной школы трясётся и спать не может от того, что деление на ноль не определено. Бедненький.

Там где взлетел исходников всё равно нет, потому непонятна причина для радости

Таки да.

А где тут радость-то?

RISC-V что-то не взлетает

Смотря у кого

Ни у кого. Мощных SoC до сих пор нет, только всякая бесполезная мелочь. То есть, да, твой SSD будет на пару баксов дешевле потому что вендору не нужно платить лицензию на ARM. Но только и всего.

Резюмируя.

RISC-V не нужно, как UB. RISC-V - это UB.

И чо?

Резюмируя.

RISC-V не нужно, как UB. RISC-V - это UB.

Какой-то тупой анонимус сегодня :(

Можно нам другого, умного анонимуса в тред?

В общем, по всему выходит, что тысячи и тысячи людей уже десятки лет страдают абсолютно зря

Я всегда писал что свидетели UB страдают зря. Сам к ним не отношусь и не страдаю, ни одна прога не сломалась.

Да-да, традиционное УМВР. А потом у тебя лялекс с паникой ядра падает.

Сначала нужен не тупой ТС.

Ничего не падает.

топовые треды говорят об обратном

Сишечники всё равно будут страдать с UB, тому що диды так пейсали.

К логопеду, быдло!

Ф Бабруйск, жывотное.

Наверно с начальной школы трясётся и спать не может от того, что деление на ноль не определено

Одно дело — остановить выполнение программы, другое — непредсказуемое поведение.

Так что, раст нужен или нет? /sarcasm

Сишечники всё равно будут страдать с UB, тому що диды так пейсали.

Деды писали с UB на ограниченном по мощности железе.

Внуки пишут условный HelloWorld, который для своей работы требует оперативной памяти больше чем Windows, Office вместе взятые.

Ждем результата правнуков.

По мне от ub особо ни кто не страдает, но то что их уже давно надо определись тоже думаю ясно. Возможно стоит ввести «два» стандарта один широкий, обратно совместим и соответственно с ub, а другой узкий под чисто конкретные железки, которые занимают 99% рынка и без ub. И в параметрах компилятора и передавать чего хочется прт сборке. В какомто таком ключе - и тем и сем.

Мощных SoC до сих пор нет, только всякая бесполезная мелочь

define мощных, вон, DC-ROMA II будет по-мощнее моего ноута.

То есть, да, твой SSD будет на пару баксов дешевле потому что вендору не нужно платить лицензию на ARM

Вопрос тут скорее не для конечного потребителя, а для производителя. Сэкономишь на штате юристов как минимум, ну и белые дяди из Арма за попу не схватят если ты какой-нибудь risc-v стартап купишь с их SoC и впихнёшь в свой Пежо.

Наблюдаю повышение градуса агрессии в интернетах. Это то самое «весеннее обострение»?

Деды писали с UB на ограниченном по мощности железе.

Компиляторы тоже были ограничены мощностью железа, что ограничивало возможности оптимизации и всякого рода compile-time вычислений. Приходилось прибегать к UB-костылям.

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

Вот выйти за границы буффера - UB. Не потому что компилятор это определяет и такой «о! попался сука! у тебя указатель указывает вне буффера, ща я тебе покажу, нажрусь, изнасилую всех гусей и заоптимизирую программу до return 42», а потому что компилятор всего лишь никак этот случай специально не обрабатывает, и вообще про него не знает.

А чтобы знал нужно выполнить очень нетривиальные действия, потому что в C/C++ у тебя просто прилетает какой-то указатель и всё - поди разберись куда он может указывать, а куда не может. Был бы это индекс, можно было бы проверить на границы (с runtime ценой, но давай ей пренебрежём, индустрия уже сошлась во мнении что это допустимый оверхед), но нет, это не индекс (и даже если, индексируемый объект может быть таким же сырым указателем, а не явным контейнером с границами). Можно было бы указатели сделать жирными, хранить смещение и ссылку на контейнер. Но нет, пока язык позволяет кастануть к void* или intptr_t и обратно. Можно хранить карту всех выделений с границами и даже типами, только прикинь сколько будет стоить по ней ходить. И, опять же, тебе из сторонней библиотеки прилетает просто указатель, а он там был получен просто смещением в mmap памяти, какая нахрен карта каких выделений? Поэтому компилятор просто ничего не делает. Вышел, не вышел, ноль получил, wraparound произошёл (или ты просто сместился влево?) - всё быстро и просто, и всё на твоей совести.

Доходит, не?

Не, какие-то проверки можно добавить. На знаковое переполнение, например. Не будет в каждой арифметической операции у тебя бранч, подумаешь. И нужно ещё решить что в нём делать - saturation, wraparound, abort или исключение кидать. Для этого нужно язык менять. Всего-то. Но меняют же! Вон сколько новостей было за последний код про безопасные расширения к C. Используй. В конце концов, собирай с UBSAN в проде. Что тебе стоит. UB не нужен.

Исследователи из университета Бухареста и технического университета Лиссабона

Это просто чья-то курсовая.

Наверно с начальной школы трясётся и спать не может от того, что деление на ноль не определено

Одно дело — остановить выполнение программы, другое — непредсказуемое поведение.

Ну тебе конкретно с детства говорили что на дорогу выбегать (сдвигать целое на отрицательную величину) нельзя – там может машина сбить, а может и нет. И это нанесло тебе душевную травму, ведь так хотелось. Какой ужас.