Объясните сишную магию v2

Это всё равно говнокод.

А если бы было типа такого:

fLastMoveToIndex ^= ~sex(fLastMoveToIndex);

и например на функцию sex была бы документация. Всё равно говнокод?

FPC не смог вроде - https://godbolt.org/z/1PjchT

Запуск «fpc -io» примерно поясняет, почему. Это полный список оптимизаций. А теперь сравни со шланговым "-mllvm -debug-pass=Arguments".

Теперь я поясняю, чё-почём. Если ты добавишь "-ftime-report" к какому-нибудь шлангу, то увидишь, что при "-O0" LLVM работает пару микросекунд, при "-O1" уже пять микросекунд, при "-Ofast" — шесть. Теперь включаем "-vs" у FPC, и что же мы видим? Компиляция неизменно выдает одну микросекунду. На самом деле микросекунда здесь — это это затраты на ввод-вывод, а не на компиляцию. Компилятор способен обрабатывать 100-200 тысяч строк в секунду, потому реальная компиляция занимает долю микросекунды.

И вот представь, что ты к этой доле микросекунды докидываешь еще пять микросекунд? У тебя время компиляции растет на один-два порядка. В 2020 году никого вообще не волнует, что пару строк кода будут работать на 10% быстрее, что даст ±0% прироста производительности работы программы, зато много кого волнует невозможность разработки крупного проекта на C/C++ без билд-сервера с десятками ядер (локального и удаленного).

Отсюда у меня вопрос: какие оптимизации есть в GCC и Clang для оптимизации времени компиляции? Когда я смогу на свои четырех ядрах собрать Linux или Firefox за минуту? Вот это реальная оптимизация, и ею нужно заниматься, а не погоней за проценты производительности в тонкой оптимизации под архитектуру, результаты которой резко становится бесполезными при смене архитектуры процессора.

И еще, у авр есть проблемы с ветвлением? Хотя такие короткие прыжки не вызовут проблем даже у современных x86.

У AVR нет предсказания ветвлений, нет кэшей, нет конвейера и вообще это примитивный проц, для него это всё не нужно

Старнно, что никто не упомянул ARM:
https://gcc.godbolt.org/z/n9hrEK — версия с «if» выдает короче код.
https://gcc.godbolt.org/z/hWx4dv — а шланг выдает одинаковый код.

Также для меня странно, что кто-то называет ARM RISC архитектурой на фоне инструкций вроде:
«movn» — сделать битовое отрицание и поместить результат в регистр;
«eon w0, w0, w0, asr 31» — сдвинуть w0 на 31 бит, инвертировать результат, выполнить XOR результата с w0, поместить результат в w0. Или вот:
«ldrh w0,[w1,-w2]!» — прочитать полуслово по адресу w1-w2, и записать его в регистр w0.

Отличный сокращенный набор инструкций, ага. Для справки, спеки инструкций SPARC примерно раз в десять меньше спек ARM. Потому ARM тупо копирует принцип CISC архитектур, вроде x86, но с небольшими и важными изменениями:
— в два раза больше регистров;
— в одной операции не могут сочетаться чтение и запись;
— следствие: атомарные операции заменены на LL/SC.
— следствие: менее строгая модель памяти, поскольку теряется необходимость соблюдения порядка чтение-чтение, чтение-запись, и запись-запись между ядрами.

В остальном ARM — это самая обычная CISC архитектура.

Эти функции логически одинаковы с точки зрения виртуальной машины языка

Нет никакой виртуальной машины языка. Стандарт Си ссылается на виртуальную машину, но никак не определяет ее поведение.

А насколько приведенный фрагмент мультиплатформенный? Вроде же были платформы, где знаковый бит хранится отдельно или представление отрицательных чисел не ввиде дополнительного кода. Или таких уже не осталось в живых?

Они платформозависимы если делаются с числами а не набором байтов

Нет, конечно, всё строго определено:
http://eel.is/c draft/expr.shift

Right-shift on signed integral types is an arithmetic right shift, which performs sign-extension.

Еще в 2018 году это было implmenetation-defined:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4727.pdf

Вроде же были платформы, где знаковый бит хранится отдельно или представление отрицательных чисел не ввиде дополнительного кода. Или таких уже не осталось в живых?

Видимо, не осталось. Сейчас все используют дополнительный код и первый бит знаковый: ARM, AVR, SPARC, PowerPC.

Много лет назад, на лекциях NATO Кристофер Страчи, один из авторов CPL сказал: «То, как люди учатся программировать, отвратительно. Они снова и снова учатся каламбурить. Они используют операции сдвига вместо умножения, запутывают код используя битовые маски и числовые литералы, и вообще говорят одно, когда имеют ввиду что-то совсем другое. Я думаю, у нас не будет инженерного подхода к разработке программного обеспечения до тех пор, пока у нас не закрепятся профессиональные стандарты о том, как писать программы. А добиться этого можно лишь начиная обучение программированию с того, как писать программы должным образом. Я убежден, что в первую очередь необходимо начать говорить именно то, что вы хотите сказать, а не что-то другое».

В 2020 году никого вообще не волнует, что пару строк кода будут работать на 10% быстрее

Сказки от недопрограммистов, ну вернее не для всех проектов это правдиво.

Отсюда у меня вопрос: какие оптимизации есть в GCC и Clang для оптимизации времени компиляции?

От precompiled headers до форков.

какие оптимизации есть в GCC и Clang для оптимизации времени компиляции?

И как ты собираешься оптимизировать время бесконечности, куда может уйти тьюринг-полная машина в лице с++-шаблонов и constexpr? Проблема в сложности языка.

лекциях NATO Кристофер Страчи

Пруфов нет, но прокоментирую.

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

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

В общем, если это правда, то он спорол очередную начальническую чушь.

на лекциях NATO

Это что за лекции? Неужто тот самый военный блок? Или это буржуйский университет какой-то?

Инженер - в первую очередь творческая личность - художник, и рисует так, как видит.

Что то явно не то. Не, Вам виднее. Но я под таким даже близко не подпишусь. То что инженер в глубине души - Кулибин, это да. Но художник? Чо то изврат какой-то.

художник?

Художники применяют заранее изученные в «консерваториях» техники (смешения красок, нанесения красок, измерения изображаемых объектов и тд и тп). Но выбор применямых техник лежит на стороне художника, а не начальника (драйвера печатающей машины). Инженер - это художник, а не шестеренка в машине. Шестернка в машине - это тупой кодер, а не инженер.

Лучше подумай, что нет так с тобой.

В 2020 году никого вообще не волнует, что пару строк кода будут работать на 10% быстрее

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

Ну давай, назови мне проект, для которого критично 10-20 % скорости работы? Или ты про хотспоты, которые оптимизируют до дыр на хасвеле, а потом получают двухкратное падение производительности на скайлейке?

Отсюда у меня вопрос: какие оптимизации есть в GCC и Clang для оптимизации времени компиляции?

От precompiled headers до форков

И сколько оно даст? Хотя бы в половину сократит время?

И как ты собираешься оптимизировать время бесконечности, куда может уйти тьюринг-полная машина в лице с++-шаблонов и constexpr? Проблема в сложности языка

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

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

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

Чем проще код - тем лучше. Хочешь извращений - пиши тесты и документацию.

В большинстве случаев описанной тобой проблемы нету

В «большистве» случаев, компиляция без оптимизации «pure c» кода сравнима со скоростью паскаля. Тормозит именно применение сложных частей языка. Ах да, кроме проблемы останова, есть еще P ≠ NP

Опять ты - забавный персонаж - вылез?

Опять ты

Просто интересно: Ты, Малевич, нас к живописи приобщить хочешь, чтоле? Чую щас и Страдивари в ход пойдут. Только на ЛОРе обратный культурный эффект наблюдается: приходят культурные люди, а уходят… Да не, не уходят, культуры уйти не хватает.

Ну давай, назови мне проект, для которого критично 10-20 % скорости работы?

Вероятно я зря пытаюсь что-то донести до столь убежденного в собственной правоте персонажа, как вы, но полагаю, что 20% скорости критичны для всех, кто:

• тратит на софт собственные деньги (вроде профессиональных фотографов или видеографов);
• зарабатывает на софте (например, владельцы платежных шлюзов);
• вынужден тратить собственные деньги на обслуживание софта и инфраструктуры, на которой этот софт работает (типа владельцев хостинговых платформ или компаний вроде Yandex, Facebook, Google, Netflix и пр.).

Получить вот так просто прирост в 20% (или сократить собственные расходы вот так просто на 20%)… Да кто от такого откажется?

Ну разве что вы. И то на словах доказывая что-то кому-то в срачах на LOR-е. А как дело дойдет до денег из вашего собственного кармана…

А как дело дойдет до денег из вашего собственного кармана…

…Так повыгоняет сразу всех «шибко умных» и сократит свои расходы изрядно.

Просто интересно

Миф про лекцию НАТО Кристофера Стрейчи - это плод твоего забавного воображения (а инженер, по твоему, не может иметь воображение, тем более воплощать в деле), или все таки будет пруф?

Миф про лекцию НАТО

Какие лекции? Ты о чём, Малевич?

инженер, по твоему, не может иметь воображение

Кулибин не имел воображения? Хреново ты «картину маслом» рисуешь, Малевич, всё чёрный квадрат получается.

Контрольный вопрос: кулибин - инженер?

А с воображением у тебя явно плохо - в метафоры не можешь.

Контрольный вопрос: кулибин - инженер?

Риторический вопрос, приятель. Пук в пустоту.

в метафоры не можешь.

Оч даже могу. Только с метафорами у тебя явная лажа получилась, Малевич.

Продолжай нюхать пустоту, забавный риторик.

Продолжай нюхать

Разъясняй давай нам «некультырным», это «перформент» или вторая какая то лабудень. Мы ж художественных гимназий не заканчивали, неучи так сказать.

лабудень

По стили общения ты похож Пурум-пум-пум, или SAIL: Библиотека декодирования изображений

По стили общения

Так ты ещё и лингвист? (во даёт, клоун). Ну так давай, распиши нам культурную составляющую ЛОРа.

Сперва залогинься, забавный персонаж!

Сперва залогинься

Рега не имею! (и не собираюсь иметь)

Не ломайся, как целочка. Небось, не раз замужем была (имеешь пару-тройку запасных рег).

Не ломайся, как целочка

Да у тебя ещё то «воображение». Это ты «его» пользуешь в кодинге? Шикарно, Малевич. «Шедевры» тебе обеспечены.

Ну, давай же, «целочка». Сама сперва начала приставать, а теперь ломаешься.

Ну, давай же

Чо тебе давать то, олень? Ты у нас художник, ты и давай свои «воображаемые глобусы».

(Голосом Дроздова) Вы наблюдаете типичное поведение приставучих целок.

Голосом Дроздова

Ещё и чревовещатель? Да ты человек-оркестр целый! А на ЛОРе по что?

А на ЛОРе по что?

Приставучие целки - это более забавные персонажи.

Приставучие целки

Объясните сишную магию v2 (комментарий)

Объясните сишную магию v2 (комментарий)

Объясните сишную магию v2 (комментарий)

Объясните сишную магию v2 (комментарий)

Объясните сишную магию v2 (комментарий)

Зачем ты ссылаешься на то, что является следствием? Ты вылез, как приставучая целка чертик из табакерки с заявлением про культуру общения. Примени к себе свои заявления, художественный критик.

В «большистве» случаев, компиляция без оптимизации «pure c» кода сравнима со скоростью паскаля. Тормозит именно применение сложных частей языка

Сложные части языка — это «#include ...». Если забыть на секунду про эту проблему, то да, Си возможно компилировать ненамного медленнее. Ядро линукса на 20 млн строк компилируется где-то два часа процессорного времени - несложная арифметика дает около 3+ тысяч строк в секунду. Мой паскалевый проект на 3 млн строк с хвостиком компилируется вместе с линковокой где-то за 5 минут процессорного времени, из которых 2 минуты занимает линковка — 17 тыс строк в секунду, и я знаю, как ускорить компиляцию в разы, но эти изменения уже не будут внесены.

Ядро линукса на 20 млн строк компилируется где-то два часа процессорного времени

У вас первопень? Ядро линя собирается пару минут на современном железе.

с заявлением про культуру общения

Ты наркоман, чтоле? Со стенами не разговариваешь? Лечиться надо.

Вспомнил, ты та самая «неверующая» мартышка, которая не верит в высадку на Луну. Мне не очень хочется с тобой общаться. Зря я влез в эту дискуссию, как чертик из табакерки :)

Разве еще где-то остались «чистые» RISC?

Вон в POWER тоже есть stwu (store word and update), так что, теперь POWER RISC’ом не называть?

Никто не строит RISC-систему просто для того, чтобы сделать систему с сокращенным набором инструкций. Главное - производительность. Если новые инструкции показывают повышение производительности, то они будут добавлены.

тратит на софт собственные деньги (вроде профессиональных фотографов или видеографов)

Им чаще всего фичи важнее каких-то крох производительности — железо не жалко, пусть пашет.

зарабатывает на софте (например, владельцы платежных шлюзов)

Для этих людей «стабильность и безопасность >>> производительность».

вынужден тратить собственные деньги на обслуживание софта и инфраструктуры, на которой этот софт работает (типа владельцев хостинговых платформ или компаний вроде Yandex, Facebook, Google, Netflix и пр.)

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