Hi all. Какое значение march соответствует наиболее общей платформе amd64? Т.е. допустим, если машина подохла, переставить винты на другую 64-битную — и чтобы всё работало.
И какие use-флаги из серии mmx,sse,sse2 в этом же плане безопасны?
Re: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, dimgel, Вы писали:
D>И какие use-флаги из серии mmx,sse,sse2 в этом же плане безопасны?
Именно эти и безопасны. amd64 всегда поддерживает sse2.
Re[2]: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, watchmaker, Вы писали:
D>>И какие use-флаги из серии mmx,sse,sse2 в этом же плане безопасны? W>Именно эти и безопасны. amd64 всегда поддерживает sse2.
Ок, а что насчёт march?
Кстати, если его вообще не указывать (оставить CFLAGS по умолчанию), то это равносильно чему? Годится для моей цели?
Re: Вопрос гентушникам про march в CFLAGS в make.conf.
There is no -march=generic option because -march indicates the instruction set the compiler can use, and there is no generic instruction set applicable to all processors.
Re[3]: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, dimgel, Вы писали:
D>Ок, а что насчёт march?
Да написать там «x86-64» — наверное сойдёт :)
D>Кстати, если его вообще не указывать (оставить CFLAGS по умолчанию), то это равносильно чему? Годится для моей цели?
Это зависит от того как компилятор был сам скомпилирован. Запусти «gcc -v» и он покажет что будет использовать по умолчанию.
Re: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, dimgel, Вы писали:
D>Hi all. Какое значение march соответствует наиболее общей платформе amd64? Т.е. допустим, если машина подохла,
тоесть ты ожидаешь что подохнет что-то кроме винчей??
ок, даже если и так... я бы не запаривался на попытку собрать такую вот "переносимую" систему. во-первых потому, что хитрые опкоды (sss3, sse4 и т.д.)
с вероятностью 99% не применяются в "обычных" программах... как правило это что-нибудь связанное с видео\аудио и в болшенстве случаев это "вручную" затюненные алгоритмы. ("обычный" С/С++ код генерит довольно скушный набор инструкций, и да, они поддерживаются даже очень старыми процессорами).
таким образом, вероятность того, что при переносе ты огребешь invalid opcode и не доберешься до рабочего shell в целом не сильно высока. более того, она практически стремится к нулю, при переносе с более старого проца на более новый (или одинаковый), а именно такой сценарий я себе могу представить (к примеру если вдруг что случится с моим ноутом (мамкой или процом, но не винчом!) -- я в принципе уже не смогу купить такой же камень... только более новое поколение, у которого набор инструкций является надмножеством моего (если конечно речь не о миграции между разными производителями))
также стоит принять во внимание, что ядро тебе все равно нужно будет пересобирать при переносе (если конечно ты не будешь делать как все дистромэйкеры -- включать вообще все что можно и нафиг не нужно...)
D>переставить винты на другую 64-битную — и чтобы всё работало.
как показывает мой личный опыт за последние N лет -- миграцию приходится делать при:
0) покупке более нового железа -- и с этим проблем нет, как уже было отмечено
1) при повреждениях -- и в первую очередь это диски... один раз у меня вылетел HDD (пару лет назад), и один раз я делал перенос системы с HDD на SSD.
в обоих этих _реальных_ случаях проблем с переносом не было...
D>И какие use-флаги из серии mmx,sse,sse2 в этом же плане безопасны?
эти USE флаги характерны в основном для пакетов работающих с аудио-видео. и это вовсе не значит, что в других пакетах не будут использованы "хитрые" опкоды если ты, допустим, будешь использовать автовекторизацию.
в целом, я бы тебе советовал не запариваться на _не_реальных_ случаях и смело использовать -march=native, выжимая максимум производительности (в т.ч. включая означенные USE флаги!)
Здравствуйте, zaufi, Вы писали:
Z>тоесть ты ожидаешь что подохнет что-то кроме винчей??
На случай подыхания винчей у меня raid1.
Z>во-первых потому, что хитрые опкоды (sss3, sse4 и т.д.) с вероятностью 99% не применяются в "обычных" программах...
Стояла у меня на одном винте ноута гента, скомпилятая с march=native, потом я взял и скопипастил её внутрь virtualbox под win8. И вообще ни одна программа после chroot не запустилась — все падали с "недопустимая инструкция" (точный текст сообщения не помню, но смысл был однозначный). Так что либо я попал в эти 1%, либо одно из двух. Отсюда, собственно, и паранойя в исходном вопросе.
Z>также стоит принять во внимание, что ядро тебе все равно нужно будет пересобирать при переносе
Это не вопрос. Вопрос в том, чтобы суметь за-chroot-иться и собственно провести пересборку ядра, да и всего `emerge -e world` до кучи желательно.
Re[4]: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, watchmaker, Вы писали:
W>Здравствуйте, dimgel, Вы писали:
D>>Ок, а что насчёт march? W>Да написать там «x86-64» — наверное сойдёт
Подтверждаю, проверено практикой.
D>>Кстати, если его вообще не указывать (оставить CFLAGS по умолчанию), то это равносильно чему? Годится для моей цели? W>Это зависит от того как компилятор был сам скомпилирован. Запусти «gcc -v» и он покажет что будет использовать по умолчанию.
Может вообще ничего не указывать. x86-64 достаточно новая архитектура, и ущерб от умолчания минимален. Это не старый i386.
The God is real, unless declared integer.
Re[2]: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, zaufi, Вы писали:
Z>ок, даже если и так... я бы не запаривался на попытку собрать такую вот "переносимую" систему. во-первых потому, что хитрые опкоды (sss3, sse4 и т.д.) Z>с вероятностью 99% не применяются в "обычных" программах... как правило это что-нибудь связанное с видео\аудио и в болшенстве случаев это "вручную" затюненные алгоритмы. ("обычный" С/С++ код генерит довольно скушный набор инструкций, и да, они поддерживаются даже очень старыми процессорами).
С тезисом про 99% совершенно не согласен — SSE уже давно не только про мультимедию. Да банальная работа со строками вроде вычисления длины strlen() уже давно реализована в glibc через SSE4, ибо так работает быстрее. То есть получить пачку SSE4 инструкций при компиляции кода 20-и летней давности на самом деле очень легко. И если явно не выключать новые расширения, то как раз наоборот с большой вероятностью на более старом процессоре ничего работать не будет, так как libc используется чуть менее чем в каждой программе, да и длинна какой-нибудь строки (хоть той же из массива argv при вызове main) где-нибудь да вычисляется.
Хотя, согласен, что если рассчитывать, что новый процессор будет не хуже старого по набору инструкций, то особо можно и не избегать более быстрого кода.
Re[3]: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, watchmaker, Вы писали:
Z>>с вероятностью 99% не применяются в "обычных" программах... как правило это что-нибудь связанное с видео\аудио и в болшенстве случаев это "вручную" затюненные алгоритмы. ("обычный" С/С++ код генерит довольно скушный набор инструкций, и да, они поддерживаются даже очень старыми процессорами). W>С тезисом про 99% совершенно не согласен — SSE уже давно не только про мультимедию. Да банальная работа со строками вроде вычисления длины strlen() уже давно реализована в glibc через SSE4, ибо так работает быстрее.
Это в каком исходном файле? sysdeps/x86_64/strlen.S не показывает ничего выше SSE1. sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S использует SSE2, но не выше.
W> То есть получить пачку SSE4 инструкций при компиляции кода 20-и летней давности на самом деле очень легко.
Даже если так (см. выше), то там наверняка рантайм-проверка. Которой пофиг, как компилировали код.
The God is real, unless declared integer.
Re[4]: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, watchmaker, Вы писали:
Z>>>с вероятностью 99% не применяются в "обычных" программах... как правило это что-нибудь связанное с видео\аудио и в болшенстве случаев это "вручную" затюненные алгоритмы. ("обычный" С/С++ код генерит довольно скушный набор инструкций, и да, они поддерживаются даже очень старыми процессорами). W>>С тезисом про 99% совершенно не согласен — SSE уже давно не только про мультимедию. Да банальная работа со строками вроде вычисления длины strlen() уже давно реализована в glibc через SSE4, ибо так работает быстрее.
N>Это в каком исходном файле? Где-то мы похожее уже обсуждали :)
N>sysdeps/x86_64/strlen.S не показывает ничего выше SSE1. \
Что-то непонятно в какие исходники ты смотришь, но в в SSE1 же для работы с байтами практически ничего полезного нет. Если уж есть там SSE, сразу SSE2. Врочем для x86-64 не важно — поддерживаются всегда оба.
W>> То есть получить пачку SSE4 инструкций при компиляции кода 20-и летней давности на самом деле очень легко.
N>Даже если так (см. выше), то там наверняка рантайм-проверка. Которой пофиг, как компилировали код.
Да, код проверки в исходниках есть. Но, во-первых, она там явно написана, а, во-вторых, она не всегда включена.
Но это даже и не важно, что она там есть — это заморочки реализации glibc. Во всех же остальных программах и библиотеках её нет (просто потому, что они написаны не на ассемблере, а на чистом C/C++, а это более высокий уровень, который не знает в какие конкретно инструкции его преобразует компилятор). И вот если компилятор использует -march=native -mtune=native, то конечно он не будет вставлять никаких проверок — ему ведь абсолютно точно известен набор инструкций, которыми он может воспользоваться.
Проверки возникать могут лишь когда march и mtune существенно не совпадают — в этом случае иногда имеет смысл ветвиться в рантайме в зависимости от процессора. Но в этом-то и смысл темы — какой задать march чтобы проверка всегда отсекала невыполнимый код.
Re[5]: Вопрос гентушникам про march в CFLAGS в make.conf.
Здравствуйте, watchmaker, Вы писали:
W>>>С тезисом про 99% совершенно не согласен — SSE уже давно не только про мультимедию. Да банальная работа со строками вроде вычисления длины strlen() уже давно реализована в glibc через SSE4, ибо так работает быстрее.
N>>Это в каком исходном файле? W>Где-то мы похожее уже обсуждали :)
Но вызовы там таки уровня MMX и SSE1. Можешь сам посмотреть.
W> Если уж есть там SSE, сразу SSE2. Врочем для x86-64 не важно — поддерживаются всегда оба.
Я по умолчанию смотрел в ветке master. Там такого нет. И не предполагал смысл смотреть в релизную ветку.
W>Но это даже и не важно, что она там есть — это заморочки реализации glibc. Во всех же остальных программах и библиотеках её нет (просто потому, что они написаны не на ассемблере, а на чистом C/C++, а это более высокий уровень, который не знает в какие конкретно инструкции его преобразует компилятор). И вот если компилятор использует -march=native -mtune=native, то конечно он не будет вставлять никаких проверок — ему ведь абсолютно точно известен набор инструкций, которыми он может воспользоваться.
В теории — да, может. Против этого (редукции до устойчивой базы) я и не возражал. Хотя реально я больше поверю в использование не векторных команд, а каких-то других добавок.
