Судя по тому, что я начитался, обратиться к кешу процессор напрямую (указать адрес в кеше, например) нельзя даже из ассемблера. Это внутренняя вотчина процессора и он сам ей управляет. Тогда единственный плюс ассемблерных вставок по отношению к попыткам "уложиться в кеш" на языке высокого уровня под виртуалной машиной (Дотнет, например), это то, что есть гарантия, что на ассемблере кроме тех данных, что вы используете в данный момент, виртуальная машина не потащит в кеш ещё чего-нибудь. Т. е. для виртуальной машины и разных высокоуровневых библиотек по отношению к объёмам кеша процессора надо вводить понятие "доступно пользователю", как в своё время на коммуникаторах с маленькой памятью было. Скажем, кеш 7 МБ, а при программировании под виртуальной машиной он постоянно на 3 МБ забит всякими служебными данными вертуальной машины. Так что попытки уложиться в 7 МБ могут просто ни к чему не привести.

Но при этом непонятно, как отследить, сколько в данный момент отправлено служебных данных. Если вызывать функции, показывающие, сколько в данный момент памяти занимает такой-то объект, то это будет относиться только к ОЗУ, а не к кешу, как я понимаю. Т. е. такие попытки мониторинга для высокоуровневых систем обречены на провал без специальных инструментов (которых, может, и нет). Ну т. е. да, согласен с автором выше, что лучше не заморачиваться "экономией памяти" в Дотнете и использовать более контролируемые в этом смысле ассемблерные вставки. Хотя, опять же, понятие "доступно пользователю" бы не помешало, ибо использование обёрток не загромождает ли кеш так же служебными данными, как и при попытках "экономить" чисто под виртуальной машиной? Ведь вызоввы этих обёрток происходят всё равно из-под виртуальной машины.

И ещё вопрос. Как я понимаю, под ассемблером вы понимаете именно процессорный ассемблер, а не какой-нибудь CIL? На CIL распространяется вся эта виртуальщина со сборками мусора и управляемостью, да? Тогда вопрос: какое может быть преимущество в написании каких-нибудь кусков кода непосредственно на CIL?

beg-in-eruser7320 какое может быть преимущество в написании каких-нибудь кусков кода непосредственно на CIL?
вы определитесь , што вам треба, какая задача стоит. а уж потом лезте в методы решения.
максимальное быстродействие можно достичь целым спектром методов, помимо асма.
Т. е. при определённых условиях много есть каких преимуществ при написании кода на CIL вместо какого-нибуди СиШарпа, помимо чисто академических целей "а как же это работает там внутри"?

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

SeVaПрежде, чем озадачиваться оптимизацией на уровне регистров, лучше разобраться, что происходит во время такого косяка как list.add. Одно это убьет всю производительность на корню. Первый принцип разработки эффективного кода на net - минимизация выделения памяти.
Эмм... ну а что со списком и конкретно с добавлением в него элементов можно сделать, кроме как во время создания указать фиксированный размер?

И меня всё равно интересует вопрос в моём предыдущем посте - есть ли разница при передаче по ссылке объектов разного размера?

Если ли разница, передавать в функцию один большой объект по ссылке и считывать нужные свойства, или лучше эти свойства по отдельности в параметры загнать?