__builtin_expect есть смысл использовать чтоб помочь компилятору предугадать ветку?

Тебе — нет

[[likely]]/[[unlikely]] (с поддержкой пока что проблемки, насколько я помню).

Ну хотя бы использовать там где поддерживается

Ты опять оптимизациями преждевременными занимаешься? Самому не надоело херней маятся?

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

Я вообще то пишу concurrent free queue

А что плохого в извлечении дополнительной производительности там, где это возможно (особенно малой кровью; особенно одним кейвордом)?

Да уже мне рассказали как ты придумал мьютекс и назвал это локфри Молодец конечно

Как минимум еще одним макросом, если подразумевается не только C++20

К чему этот разговор? Вопрос был адресован в чат, не нравится вопрос - не отвечай

Преждевременная оптимизация — корень всех зол © Кнут

А кто сказал, что оно есть на платформе X?

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

Никто не говорил

Я пытаюсь тебя на истинный путь направить, а ты как всегда Как об стенку горох

Тогда зачем его юзать?) Про C++20 уже подсказал Sergey выше: [[likely]]/[[unlikely]]

Преждевременная оптимизация - такая, которая не требуется? Здорово, уничтожает всю компетитивность и прогресс, опосредованно. Как Вы определите, например, какой тик-рейт в Вашей симуляции достаточен? Какая точность измерения достаточна? Особенно когда пишете компонент для повторного будущего использования (библиотеку, например).

это он про алгоритмы?

Это про всё

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

Вы просто не понимаете, что преждевременная оптимизация может сделать хуже и ухудшить перф :) Программисты — люди глупые, они думают что лучше знают, а на самом деле компиляторы умнее достаточен — устраивает заказчика

тогда возникает вопрос, что такое "преждевременная оптимизация"?

Что за бред

То, чем занимается @r_mustang

тогда следом еще один вопрос, зачем тогда вводить likely/unlikely если компиляторы и так умные?

компиляторы настолько умны, что в константу всё разруливают

Если у вас библиотеки не решают никакие задачи, мне вас жаль

Заходи в чатик по WinAPI. Тебе быстро пояснят, что написанное на асме несравнимо быстрее и плюсовые компиляторы далеко не так умны :))

Ну как же это. Вы выше написали, что "про все". Написание кода для предположительного будущего повторного использования - преждевременная оптимизация затрачиваемого на разработку времени. Или Вы не согласны?

Все современные программы состоят из одной инструкции return 42, все остальное игра нашего воображения

Для предположительного будущего использования — это называется оверинжениринг :)

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

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

Если возвести в абсолют, без оптимизаций ваш код будет как-то работать, пусть и ужасно. Без проектирования кода вы, вероятно, не сможите закрыть первую же открытую скобку

Верно. Я там говорил, правда, про "Написание кода для предположительного будущего повторного использования".

Вы не против продолжить во флудилке? @stdvector

(хитро)