Если c -O0 собирать, то очень даже не глупо. Да и вообще если перестараться можно сделать так, что на любых процессорах кроме твоей отдельно взятой модели будет всегда мисс.
Вот именно проблема в том, что кэши везде разного размера, поэтому подстраиваться под какое-то значение нельзя.
Если оптимизируешь, то нужно прикидывать, где софт может быть запущен и ориентироваться на самое слабое железо с самым базовым набором инструкций и хреновенькой производительностью.
Насколько я помню там основная проблема не с размером связана. Компилятор может упороться и код на процессоре будет делать совсем не то, что от него ожидалось. В частности может наркоманить из-за некорректной на его взгляд синхронизации.
Ну вот я допустим сортирую массив. Если знаю что кэшь процессора 1MB я сортирую блоками <1MB, если меньше то меньшими. Такая оптимизация будет работать?
gcc точно умеет в некоторые специфичные оптимизации.
з.ы. и да - думается мне, за исключением компиляторов есть очень мало применений, где это оправдано. Всё же это усложняет поддержку и добавяляет зависимость от конкретных железок (что. впрочем, может быть приемлемо).
Это так и работает. А мешает то, что кто это будет писать? Писать некому. Это есть в глибц, но даже для глибц это некому писать и реализации там так себе.
Какое отношение модель имеет к микроархитектуре? За последние 10лет микроархитектур от интела было 4 + ещё столько же от амд. нехалем+сандик+хасвел+скайлайк/бульдозер+шмульдозер+экскаватор - я не шарю. Ну где-то то же 4. И то нехалем считай тот же кора2, а скайлайк хасвел. Т.е. реально надо 1) последние коры+нехалем - на это окаменелое дерьмо можно уже нассать, 2) vex_sse + avx_fp - это всё до хасвела, 3) vex_avx - это хасвел/скайлайк. У амд та же фигня.
А можно узнать у уважаемых знатаков: Какое отношение ассоциативность имеет к обращению внутри блока длинную с кеш? Подсказка - она никогда не закольцуется.
На самом деле, я неправ: непрерывный блок размером в кэш в него таки влезет. Тем не менее, бить данные на такие куски всё равно плохая идея: во-первых, не очень понятно, о каком кэше речь — ЕМНИП L1 на многих микроархитектурах кэширует только код, а на более высоких уровнях уже возникнут проблемы с влезанием в него; во-вторых, в памяти могут случайно оказаться используемые при сортировке переменные.
Чё? Хотя ладно - спрашивать что-то со знатаков глупо, но раз я социализируюсь - объясню тебе нормально.
Кеш-линия никакого отношения ни к чему не имеет - это просто те части, которыми «адресуется» кеш и собственно ассоциативность работает для них.
Далее - ассоциативность - это просто кольцевое отображение на кеш, но отражения не байтов, а блоков, которые называются кеш-лайнами. Это значит, что если кеш 32кб с блоками по 64байта - память просто отображается теми же самыми блоками на 512 этими же самыми блоками.
Это значит то, что в рамках любых последовательных 512 елеметов их mod 512 будет УНИКАЛЕН ВСЕГДА. И никак они перекрывать друг друга не будут - кеш будет вмещать в себя ровно 32кб.
Ассоциативность работает против ёмкости кеша на обращение к памяти выше этого окна - т.е. когда мы обращается к блокам с шагом 512, то кеш может хранить 1блок * на его n-way - т.е. его ёмкость 64 * n-way байт. И ты слышал именно про эти все случаи.
Поэтому перед тем как рассуждать - надо научиться понимать то, о чём рассуждаешь, а не ретранслировать какой-то звон, если ты не знаешь где он.
Тем не менее, бить данные на такие куски всё равно плохая идея: во-первых, не очень понятно, о каком кэше речь man sysconf()
на многих микроархитектурах кэширует только код
Никого не интересуют эти архитектуры. В прикладном мире существует одна архитектура - х86. В мире мейнфремов ещё 2, которые почти такие же.
Остальные недомобилки с жабкой и прочая херня - никого не волнует.
а на более высоких уровнях уже возникнут проблемы с влезанием в него во-вторых, в памяти могут случайно оказаться используемые при сортировке переменные.
опять же man sysconf - используй блок чуть меньше объёма кеша. Всё это считается.
Опять же - эти оправдания ничего не оправдывают, ибо с таким же успехом можно сказать, что на многозадачной системе вообще кеш хрне пойми что кеширует и хрен пойми как работает, но это не повод его не использовать.
Всё учитывается и всё спокойно используется. Естественно всё это делается осознанно, поэтому никаких проблем с этим нет.
Чёрт, я не распарсил «<» во фразе «Если знаю, что кэш процессора 1MB, я сортирую блоками <1MB» и думал, что чувак берёт ровно такие куски, сколько у него кэша. Посыпаю голову пеплом.
В прикладном мире существует одна архитектура - х86
x86 — архитектура набора инструкций, разве она как-то регламентирует кэши и прочие микроархитектурные вещи? Или в прикладном программировании существует одна микроархитектура — та, которая в последнем поколении интеловских процов?
Чувак просто предполагает - зачем искать неточности в его предположениях? Его предположение верно - в деталях оно чуть сложнее, чем просто взять кусок, но из этого ничего не следует.
x86 — архитектура набора инструкций, разве она как-то регламентирует кэши и прочие микроархитектурные вещи?
Опять же - зачем так юлить. Когда говорится х86 - подразумевает набор её современных микроахитектур. Всё просто. И естественно всё это регламентируется - каждый школьник знает сколько кеша в его процессоре.
При этом это никакого отношения к делу не имеет, ибо я уже сказал про sysconf() - всё это очень просто получается.
Или в прикладном программировании существует одна микроархитектура — та, которая в последнем поколении интеловских процов?
Да, существует набор микроахитектур, актуальных настоящему времени. Общее описание вида l1/lcc - работает для всех. А если не работает - ничего страшного:
if(смоглось) supersort; else sort; - всё просто и понятно. Дефолтное днище у тебя всегда есть и даунгрейднуться на него можно в любой момент и никаких проблем это не вызывает.
Работа с памятью внутри и снаружи процессора показана примерами на Си без привязки к компилятору. Жаль, что Крис написал книгу только с прицелом на семейство процессоров «Интел х86», наверное, в те времена об исполнении программ на других процессорах особо не думали. Так что книга вполне годная, если кому любопытен практический исследовательский взгляд компьютерного взломщика.