Вот есть у меня сборная солянка настроек и входных данных, организованных под одним большим объектом (типа 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
Я там слов "кеш" и "кэш" в смысле кеш процессора не встречал. Да и понятно, что эти кучи и стеки все в ОЗУ организуются. Я же про кеш процессора говорил.

Изопропилuser7320Т. е. это доступно даже для дотнетчиков с их управляемой памятью

Не для всех.
Чего трудного понять, что кеш процессора маленький и лучше брать АМД, чем Интел и вообще АМД лучше не стоит в расчётах использовать слишком много данных сразу - стоит разделять расчёты на более мелкие задачи, тогда их можно будет проворачивать в кеше, не обращаясь на середине операции в ОЗУ за новой порицей. Обращаться стоит только переходя к новой подзадаче. Как-то так.

user7320Изопропилпропущено...


Не для всех.
Чего трудного понять, что кеш процессора маленький и лучше брать АМД, чем Интел и вообще АМД лучше не стоит в расчётах использовать слишком много данных сразу - стоит разделять расчёты на более мелкие задачи, тогда их можно будет проворачивать в кеше, не обращаясь на середине операции в ОЗУ за новой порицей. Обращаться стоит только переходя к новой подзадаче. Как-то так.
Ну вот, скажем, я могу весь расчёт запихать в одну функцию. А могу разбить на подзадачи, потом ещё на подзадачи, где в каждый момент будет обрабатываться только небольшой объём данных. Тогда в первом случае у меня будет огромное число локальных переменных, включая тяжёлые массивы, и всё это с болшой вероятностью захочет попасть в кеш, вытесняя друг друга оттуда, а во-втором случае локальных переменных будет немного и в кеше им найдётся место всем. Такой уровень понимания доступен же дотнетчикам? Это вообще элементарная логика, по-моему.

Я понимаю, что реальная картина будет несколько другой и точно контролировать размер данных в кеше я не смогу. Но приблизительно же могу? Могу наделать миллиард локальных даблов и кеш будет постоянно обращаться к ОЗУ. А могу всего тысячу и все операции с ними не выйдут за рамки кеша, пока я не закончу текущую подзадачу.

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

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

Как-то так.

Arm79user7320,

мне кажется, что это вы не понимаете ответов, которые вам озвучивают.

На .Net нет языков, позволяющих управлять железом на уровне ассемблера. Компилятор сам выбирает нужное множество команд процессора. И сам рулит размещением данных в регистрах. А "конвейер команд" в применении к .Net вообще выглядит смешно. Код в любом языке будет исполняться быстрее, если там мало ветвлений. Тогда больше шансов на то, что процессор сможет предугадать следующие команды.

Что касается скорости, то один громоздкий метод будет работать быстрее, чем он же, декомпозированный на тысячу методов. Переход из метода в метод - не самая быстрая операция в .Net

Если у вас какая то мания насчет сверхскорости исполнения задач, переходите на чистый C/С++. Преимущество dotNet не в сверхскорости работы программ, а в сверхскорости разработки этих программ.
Т. е. никаких рекомендаций про мой первоначальный вопрос дать в мире Дотнета нельзя? Хошь, цельный объект передавай. Хошь, по частям. Всё равно мой код пройдёт через такую кучу интерпретаторов-компиляторов, а возможности котроля не то, что ограничены, а вообще отсутствуют, так что как-то повлиять на конечный результат не представляется возможным?

Ну ладно. Спасибо.

beg-in-erИзопропилот задачи зависит - на передачу данных в память GPU и обратно тоже нужно время.
в некоторых случаях AVX может дать лучший результат
если сурьёзно этим заниматься то надо брать видяху с количеством универсальных шрейдеров более 1500. хоть каждый из них слабее ЦПУ, но вся эта толпа должна разнести любой ЦПУ в клочья. будь он трижды Xeon.
но , разумеется , это уже не в рамках .Net
Я ж говорил, что АМД лутше...

SeVabeg-in-erпропущено...

понятно , что можно и задницу обернуть в длл обёртку и дёргать её в шарпе.
Но!
в частности есть язык hlsl. у него свой синтаксис, своя задача. портировать его шарп невозможно без потерь, как в скорости, за которую бъёмся , там и потеря в полноценности.
Да, если написать на этом языке нужный метод с параметрами , и потом его дёргать, то ессесно работать будет . но его надо сначала написать.
иначе получится какой то франкеншейн, в духе SQL<->ORM, мегасрач по которому тут недавно прошёл

Слишком сильное утверждение. Шейдеры есть wpf/sl. Компилируются отдельно с помощью DirectX SDK, а потом спокойно используются
Эка штука получается. Теперь игровой программист может и в каком-нибудь НАСА поработать или каком другом институте ресёрчером, а может ресёрчер в игровую индустрию податься. Если, конечно, и тот и другой изучали HLSL для своих расчётов. Ну, игровец-то понятно, что изучал, а вот ресёрчер.