[gentoo] подробное описание USE-флагов?

>Размер кеш линий что-то значит, только в очень старых процессорах.

Пруфа опять нет?

у Фогнера к примеру. Самое главное в том, чтобы при обращении к памяти не пересекать эти самые линии. Даже выравнивать данные внутри линий не обязательно. Но так как более-менее вменяемые компиляторы всегда выравнивают данные по их размеру, то пересечений быть не может по определению. И нафига им размер линий понадобился не представляю, да даже на старых процах это ненужно знать.

>компиляторы всегда выравнивают данные по их размеру

уже нет, к тому же Pentium IV и выше не требуют этого

>уже нет, к тому же Pentium IV и выше не требуют этого
Откуда информация что не выравнивают? Pentium IV точно требует.

Крис Касперски пишет что начиная с P4 не требует, многие другие указывают что _современные_ (не указывая уровень) не требуют

если взять linux kernel, оттуда тоже убрали всякие align-loops и align-jumps

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

>если взять linux kernel, оттуда тоже убрали всякие align-loops и align-jumps
Э, мы сейчас о чём о коде или о данных?

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

Главное, чтобы разрабы компиляторов представляли.
Лобовой пример:

char a[32];
bla-bla-bla;
...
bla-bla-bla;
char b[32];
bla-bla-bla;

for(i=0;i<32;i++) a[i]&=b[31-i];


В случае, если компилятор разместит a[] на границе строки кэша, а b[] сразу за a[], то цикл отработает всего за одно обращение к памяти(при cacheline=64 на цпу, ес-но). Таких моментов особенно в мультимедиа, кодерах и тп полно и на производительность может повлиять драматически.

Как долго же он собирается вначале :(

>В случае, если компилятор разместит a[] на границе строки кэша, а b[] сразу за a[], то цикл отработает всего за одно обращение к памяти
Как за одно? Тут же по-байтово. А на запросы к памяти оно не густо повлияет, если размер массива маленький, то сработает перфетч и данные прочитаются за один запрос. Если массив большой, то это вообще не имеет значения.

Вообще говоря, в инфраструктуре Gentoo предусмотрено указание
подробных описаний юзфлагов в metadata.xml, просто многие на это
забивают. Для mplayer он, конечно, заполнен, ты можешь его
посмотреть.

искать информацию для каждого флага по всему инету как-то долго

Почему ты не можешь просто посмотреть в ебилд, если значение
флага неочевидно?

А в данном примере скорее-всего данные уже будут в кеше, так как стек, а он кешируется очень хорошо.

>Как за одно? Тут же по-байтово.

Оба массива попадут в одну строку кэша одним обращением в память(их суммарный размер 64). Это если компилятор сделает все правильно.

>Оба массива попадут в одну строку кэша одним обращением в память(их суммарный размер 64). Это если компилятор сделает все правильно.
Какая разница в одну или две, если они обе будут прочитаны из памяти одновременно. Процессоры не читают по одной линейке.

>А в данном примере скорее-всего данные уже будут в кеше, так как стек, а он кешируется очень хорошо.

Где там сказано, что это локальные переменные в стэке?)
И там есть «bla-bla-bla» между a[] и b[], т.е. в исходнике там могли бы быть описаны другие переменные, и компиллер должен бы додуматься их правильно перегруппировать.

>И там есть «bla-bla-bla» между a[] и b[], т.е. в исходнике там могли бы быть описаны другие переменные, и компиллер должен бы додуматься их правильно перегруппировать.
Для чего их перегруппировывать? А если там много такого пересекающегося кода? Да и вообще бабушка на двое сказала, что компилятор такой умный и сделает всё в лучшем виде.

>Какая разница в одну или две, если они обе будут прочитаны из памяти одновременно. Процессоры не читают по одной линейке.

Ага, их хлебом не корми, дай только почитать.


ЗЫЖ помнится, во времена 486, была демка rotozoom, как наглядная иллюстрация организации данных с учетом кэша. Уверен, он и на современных процах был бы актуален, если собрать.

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

Сейчас опровергается тезис о ненужности учета кэша при оптимизации, а не о возможностях конкретного компилятора.

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

Что мешает сгруппировать что-то самостоятельно и как тут повлияет размер чего-то? А если компилятор нашурует в худшую сторону? Тут уже идёт вторжение в вотчину разума.

> Вообще говоря, в инфраструктуре Gentoo предусмотрено указание
подробных описаний юзфлагов в metadata.xml, просто многие на это
забивают.

Спасибо, учту, но я только-что посмотрел несколько - там похоже то же, что в use.local.desc

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

флага неочевидно?

Уже пробовал - не каждый флаг добавляет зависимость, большинство просто меняют флаги компиляции, и тогда надо смотреть еще ниже, в configure или makefile. Впрочем, это тоже вариант

А почему когда появилось предложение поделиться make.conf, поделились именно make.conf, а не emerge --info? Ведь make.conf действует не с пустого места, а с выбранного профиля. Или все пользуются одним профилем?

Только здесь удалось найти больше 2 строчек на некоторые флаги и что-то похожее на советы (но мало). Пожалуй, я все-таки много слишком хочу. Отмечу тему как решенную.

а какие профиты от нескольких профилей?

В смысле «от нескольких»? Можно поставить только один, и у меня самый дефолтный предефолтный - default/linux/x86/10.0. А зачем нужные те, у которых номер больше 6, я даже и не знаю.

вот-вот
тоже дефолтный

> а иногда флаги обозначают разные вещи
Приведи пример, если не затруднит.

> use.local.desc

Сегодня собирается из файлов metadata.xml.