Вот есть у меня сборная солянка настроек и входных данных, организованных под одним большим объектом (типа Settings). Настройки - много маленьких переменных, организованных в разных классах и подклассах, входные данные - несколько больших коллекций (до сотен тысяч даблов). Мне удобно всё хранить в одном объекте, т. к. есть сценарии, где это всё передаётся куда-нибудь далеко через сеть.

Надо передать мне этот объект в функцию на расчёт. Как это происходит и какие затраты при этом будут?

Вот хранится объект этот в ОЗУ. Вот я вызываю функцию, в которую передаю этот объект по ссылке. В этой функции из объекта используются не все данные, а входные в указанных пределах (т. е. циклом for, например, прохожусь где-нибудь по двум тысячам элементов из исходных ста тысяч, причём берутся эти две тысячи где-нибудь из середины) и настройки из полей разной вложенности. Вопросы, что при этом происходит:

1) при этом в кеш процессора грузится весь объект?

2) если не весь, то коллеция, из которой я прохожусь только по части, грузится в кеш вся или только в указанных пределах?


А то я тут прочитал, что надо все расчёты укладывать в кеш, тогда разницы между что вашим ассемблером, что СиШарпом почти не будет. А если в кеш не укладываешься, то простое обращение к ОЗУ снижает производительность уже на порядок из-за задержек и простоев ЦПУ.

pationuser7320А то я тут прочитал, что надо все расчёты укладывать в кеш, тогда разницы между что вашим ассемблером, что СиШарпом почти не будет. А если в кеш не укладываешься, то простое обращение к ОЗУ снижает производительность уже на порядок из-за задержек и простоев ЦПУ.

где прочитал?
Сейчас ссылку не приведу, но это была одна из статей на МСДН от создателя Дотнета, за 2003 год. Название, как-то связанное с производительностью.

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

Насчёт "скопом инициализировать" - да прсто это исходные данные такие. Я получаю настройки и массивы чисел в виде исходных данных. Обрабатываю числа, используя настройки. Поскольку на каждом этапе расчёте используется свой набор настроек и свой массив чисел, то думаю, не проще ли в каждую функцию расчёта передавать сразу весь объект настроек, чем выделять из него кучку перепенных и массивы?

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

beg-in-erавторвашим ассемблером, что СиШарпом почти не будет
да, да , не будет. особенно если асмом гвозди заколачивать, и не использовать расширенный набор команд.
Насколько я знаю, это уже отсекает старые процессоры от вашей программы, а компиляторы заточены по умолчанию на максимальнуюж совместимость. Т. е. если настроить на последние модели процев с их SSE4,5,...25, то разница будет буквально минимальной в большинстве случаев.

pationuser7320А то я тут прочитал, что надо все расчёты укладывать в кеш, тогда разницы между что вашим ассемблером, что СиШарпом почти не будет. А если в кеш не укладываешься, то простое обращение к ОЗУ снижает производительность уже на порядок из-за задержек и простоев ЦПУ.

где прочитал?
http://msdn.microsoft.com/en-us/library/ms973852.aspx

Глава "Of Cache Misses, Page Faults, and Computer Architecture".

авторNow our fastest PCs can issue up to ~9000 operations per microsecond, but in that same microsecond, only load or store to DRAM ~10 cache lines. In computer architecture circles this is known as hitting the memory wall. Caches hide the memory latency, but only to a point. If code or data does not fit in cache, and/or exhibits poor locality of reference, our 9000 operation-per-microsecond supersonic jet degenerates to a 10 load-per-microsecond tricycle.

Думаю, что ситуация в принципе не изменилась и в наше время.

Согласен, что про ассемблер вроде там ничего не говорится. Значит, запамятовал и свои мысли выдал за то, что якобы в статье написали. Но вроде это и логически вытекает - на ассемблере ты сам памятью управляешь и знаешь, чего куда сколько загрузил. А на C# ты только примерно знаешь, где чего и сколько, ибо выяснить, что за собой потянет тот или иной объект, особенно если он из сторонней библиотеки, можно только тестируя каждый такой объект и выясняя его размер. Согласитесь, это не то, что мы хотели получить, переходя на высокоуровневое программирование.

А кстати, когда на ассемблере пишешь, там есть разные адресные пространства для каждого уровня кеша и для ОЗУ? Вот на C# или С++ попробуйте обратиться к адресу переменной на каком-нибудь уровне кеша. По-моему, это вообще не контролируется из языка такого уровня - максимум доступ к ОЗУ есть. Разве нет?

Изопропилuser7320Разве нет?
неа, просто думать нужно что происходит с кэшом данных при обработке больших массивов
А чего тут думать? - Знать надо.

Вот в ОЗУ есть большой массив, который явно целиком не укладывается в кеш. Передаю я его по ссылке в функцию. В кеше на данный момент чего? Адрес первого элемента массива в ОЗУ?

ОК. Дальше работаю не со всем массивом, а только в каком-то диапазоне, начальный и конечный индексы которого тоже в функцию передаю. Теперь в кеше уже адрес первого элемента массива и два индекса. Так?

Дальше иду for'ом по массиву, где, скажем, складываю по десять соседних элементов массива, делю результат на десять (интерполяция) и записываю результат в другой массив. Теперь уже на каждой итерации цикла for в кеше адрес первого массива, два индекса, значения десяти элементов первого массива, адрес второго массива и адрес ячейки второго массива, в которую я записываю результат интерполяции. Примерно так?

Есил так, то я не выхожу за пределы кеша, т. к. не гружу все массивы в него. Я крут?

МСУuser7320Дело в том, что я не знаю, когда данные переносятся в кеш, а когда остаются в ОЗУ.
Стоп, давай определимся с терминами. Что ты имеешь ввиду по словом "кеш"? Покажи пример кода, как ты кешируешь данные.
Кеш - это кеш процессора. Я не знаю, когда я кеширую данные. В том-то и штука. Как я из СиШарпа узнаю, что я данные в данный момент кеширую? Я могу только сказать, что если я в данные момент работаю с какой-то переменной, то её значение и её адрес прошли через кеш.

авторЕще раз - давай на пальцах (с примерами кода), откуда, что и как ты получаешь в виде исходных данных.
У меня есть класс в отдельной сборке, в котором есть основная функция расчёта. Программа загружает мою сборку и передаёт моей функции один объект, который содержит в своих полях и настройки, и массивы данных. Моя функция расчёта по мере продвижения этого расчёта берёт разные части входящего объекта.

Ну вот, например, не придираясь к правильности кода:




Буквари я погуглю про кучи и управление памятью, но попозже.

авторЗабудь о нём при работе с .NET. Договорились?
А чего тогда Jan Gray о нём говорит? http://msdn.microsoft.com/en-us/library/ms973852.aspx
Пишет о Дотнете, а говорит а кеше процессора.

автор1. То есть ты не знаешь, когда кешируешь данные, но при этом ты точно уверен, что их кешируешь?
2. Бред сивой кобылы. Срочно читай основы .NET и перестань молоть языком про "кеш процессора".
Да хоть куча, хоть стек - если я работаю СЕЙЧАС с этой переменной, то она в кеше БЫЛА ИЛИ ЕСТЬ, и вообще СЕЙЧАС она в конвейере процессора, в регистрах данных. Но мне туда доступа нет.

Жан Грей заикнулся про кеш и сказал, что негоже, мол, выходить за рамки кеша при вычислениях. Я так понимаю, что я могу это ПРИБЛИЗИТЕЛЬНО контролировать, не запрашивая огромные массивы данных без надобности. Т. е. это доступно даже для дотнетчиков с их управляемой памятью. Так?

МСУuser7320, к внимательному прочтению и освоению:

Автоматическое управление памятью
Автоматическое управление памятью в .NET
Сборка мусора
Сборка мусора
Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework
Garbage Collector Basics and Performance Hints
Я там слов "кеш" и "кэш" в смысле кеш процессора не встречал. Да и понятно, что эти кучи и стеки все в ОЗУ организуются. Я же про кеш процессора говорил.