Что значит «заоптимизировал sse, fpu»?

То и значит, что сгенерировал код, использующий оптимизацию участка с SSE, и FPU (в других участках)

То есть есть более компакнтый способ работать с плавающей точкой?

Ты читаешь сообщения?? Конфликт флагов INC. Знаешь, что это?

И причём тут более компактный? Использование SIMD это признак включённого флага оптимизации, однако, как я понял, компилировалось на MinGW, и был опущен флаг -march=native, вследствие чего компилятор упустил в оптимизации INC, а авторы, естественно, этого проверить не смогли. Но если бы это писал человек, то он бы это смог увидеть. Ответ?

Компилятор обычно оптимизирует не под конкретный процессор а под некоего абстрактного коня в вакууме, так как можно использовать инструкцию которой на данном конкретном проце нет. Пример, софтины использующие КУДА, новые нвидиевские СДК, какзалось бы причем проц, но на моем проце оно не работает, ему там какая то инструкция нужна которой в моем проце нет. И оно по сути нафиг не нужно и люди патчами обходят эту фигшулину, но как пример переоптимизации думаю подходит. То есть чем лучше оптимизирован код, тем больше геммороя с переносимостью

То есть ты сейчас признал, что компилятор оптимизирует код, чтобы при этом он лучше переносился, а не быстрее работал?

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

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

Аватар не прогрузился, я думал это Сашка ответил. Да, согласен с тобой насчёт предпосылок, и в целом насчёт флагов компилятору. Но как раз в этом и суть, что человек не всегда на большом проекте сможет проверить, какой ответ он выдал, и не всегда может убедиться, что он взял допустимые настройки. Максимум, что сейчас могут сделать, так это использовать профайлер. Но всегда ли он прав? Вряд ли в него поместятся все аспекты работы инструкций, в том, или ином контексте - например, в том же цикле INC будет медленнее, чем ADD, однако без цикла 2 INC уже будут выигрывать по скорости ADD EAX, 2 Это всё сложно предугадать, поэтому пропуски бывают. Ну а нанимать ресёрчера сейчас мало, кто будет. Т.к дело это дорогое

Да я не знаю как с этим аватаром быть. Уже масса случаем была когда люди по аватару принимали за других людей 😿

Кстати, стоит затронуть, что профайлер может дать участок, который медленно работает. Может это поможет, если загуглить, и найти какой-нибудь флаг для компилятора

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

В ruct такой профайлер встраивают, плюс есть утилита которая замордует советами Для gcc только отдельные искать, ну и опыт опять таки

Компилятор сделает то что я попрошу? Допустим я делаю либу под win окружение, заведомо однопоточную DisableThreadLibraryCalls, и далее я хочу снять со строк потокобезопасные навороты (которые сводятся к невозможности работать со строками напрямую когда объявляю их как string, т.е. к копированию этих строк ТИПО в потокобезопасные места, а уже потом работа с ними). Как?????????? как снять навротоы потоковой хрени? порядка 14МБ вспомогательных процедур которые мне никаким боком не приперлись.

Ээээ батенька, а вы либы посмотрели, какие используете? Проверили все зависимости которые тянутся?

а вот либы идут вместе с типом стринг. Если во всех местах без стрингов тупо PCHar`ы то разница как раз эти 14 Мб.

Ну и как должен компайлер поступить тогда? Он ровно то что попросили и сделал. Взял ваш код, транлировал объектник и слинковал с тем, что у вас в системе. Дайте либы с другим стрингом будет другой стринг. Но вообще проблемы трансляции объектного кода нельзя мешать с проблемами линковки. Хотя и в линковке компайлер делает то что просят

Компилятор не способен снять потокобезопасность с типа стринг даже когда целевое приложение однопоточно. Это "матершинное слово" как не оптимизировано.

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

вот, тупа в приведение типов к стрингу зашита фигня и она внутри компилятора (не вынуть).

Она в либе обычно. В случае винды это херь растущая со времен OLE и COM

нет

тоже нет. при чем тут флаги?

Сашка не хочет признавать поражение

Называй как хочешь. Из-за INC в цикле будет потеря тактов

а из-за add не будет, внезапно?

Нет, он обновляет все флаги, и не сохраняет их в потоке. Господи, Сашка, ну иди ж ты Агнера почитай, ну что ж ты стыдишься!!