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

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

В качестве случайной сырой идеи для примера: может надо подумать над тем, чтобы большую часть процессов вообще не допускать к L1? Ну, зачем, например, гуёвому приложению L1? Реакция на ивенты в большинстве случаев не требует высокой производительности, там есть ограничения по допустимой latency. Ну так пускай весь gui живёт в L2 и DRAM. А к L1 допускать только тех, кому реально надо. Так, мне кажется, вполне можно резко уменьшить количество перезагрузок кешей, без просадки в производительности, связанной с тем, что какие-то процессы работают без L1. Ядерные обработчики прерываний ведь делают так подчастую, отключая кеширование первой же инструкцией обработчика, чтобы не портить содержимое кеша, только потому, что надо инкрементировать один байт в RAM. Почему бы не попытаться провернуть что-то аналогичное в юзерспейсе для event-driven программ? Но не на уровне отключения кеширования вообще, а на уровне отказа от использования L1, в пользу использования L2.

Или может зайти вообще с другой стороны -- пускай процесс по мере необходимости создаёт виртуальную архитектуру процессора, заточенную под задачу. Надо сделать что-нибудь в стиле arr.sort().uniq().map(|x| println(x)), пускай процесс закажет под эту задачу пяток ядер, к ним L1 памяти столько, сколько будет удобно для sort, декларирует время выполнения, настроит пайпы между ядрами, и отдаст всё это на исполнение ядру, ядро всё это запустит, гарантируя что вся эта штука будет работать заказанное время без прерываний, в результате чего данные между DRAM и L1 будут пересылаться ровно столько раз, сколько это необходимо.

Сейчас, на мой взгляд, создана почва для того, чтобы совершить революцию в архитектуре процессора: есть куча накопленного опыта создания CPU, GPU, всяких там векторых расширений к ним, есть куча накопленного опыта в разработке языков программирования и оптимизирующих компиляторов к ним; налицо сложности с наращиванием мощности через тупое увеличение чего-нибудь (размера кеша, тактовоый частоты, ...). Но вместо революции, мы видим продолжающуюся, хоть и буксующую, эволюцию. Даже ИТМиТВ, со своими претензиями на революцию, на самом деле эволюционен по своей сути, они десятилетия тянут одну и туже идею, ассимилируя туда все новые знания, которые добываются интелами при разработке их процессоров. Это чистой воды эволюционный процесс.

> Знаете ли, фраза "файл регистров" мне тоже режет слух, набор регистров - привычнее.

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