Изопропилandreybsоптимизировал как мог, чтобы сохранить читабельность кода при минимуме размеров
не торопитесь с оптимизацией кода - оптимизируйте сначала алгоритм


Согласен. Но у меня закончились идеи. Сам по себе алгоритм достаточно прост. Он представляет из себя множество одинаковых операций умножения и сложения и взятия экспоненты. Операции выполняются последовательно, некоторые в качестве параметров используют результаты предыдущих вычислений. Операции агрегируются в группы по нескольким уровням. На С++ я бы сделал длиннющий одномерный массив double Arg[] и "массив операций" трех аргументов (операция, аргумент А, аргумент Б, аргумент Б). Каждый аргумент - это ссылка на элемент из Arg[]. Каждая операция - это поле int или byte над тремя аргументами: А=F(В,С). Таким образом группу всех вложенных циклов (как сейчас) можно было бы развалить в одну длиннющую портянку элементарных операций, выполняемых последовательно. И такая портянка вызывалась бы много-много раз. Я бы даже исполнение этих операций сделал бы с использованием Inline Assembler, поскольку аргументы часто будут повторяться, то их даже нет смысла возвращать в память, достаточно оставить в регистре проца. Все бы летало. Вот это была бы максимально возможная производительность - никаких циклов, условных переходов, вызовов функций и пр. Я еще думаю на тем, чтобы такое реализовать потом в обычной DLL, прилинкованной к CLR-сборке. Нужно будет только разобраться с импортом в sql clr-сборок с unmanaged кодом.

ИзопропилandreybsВыделил 4 типа данных T, для каждого из которых применил подобную модель
особого смысла в выделении типа D - не вижу. Каковы отношения между четырьмя типами T и C?


Это одно и тоже, только разных типов. Правильнее будет сказать так: есть C1, C2, C3, C4. Объекты C1 содержат объекты C2, С3, С4, C2 содержат С3 и т.д. - это вертикальные связи. Есть еще горизонтальные связи типа объекты C3 связаны друг с другом через объекты C4. Короче, имеем некого рода сеть.

D выделено исключительно для удобства. Эта структура содержит исходные данные объекта в БД. Структуру просто передавать по ссылке при импорте-экспорте данных.

ИзопропилandreybsВсего одновременно живет до 1000 объектов (пока, в перспективе до 10000).
10000 - это очень мало.


Да, не много. правда это на одну сессию. Ну, допустим будет 20 сессий, т.е. 200тыс элементов будут жить одновременно. НО! Примерно каждую секунду после окончания очередной итерации вычислений они будут полностью пересобираться на основе данных в БД, т.е. старые объекты будут отчуждаться, а новые будут создаваться на основе импортированных данных из БД. Я ожидаю достаточно интенсивную работу с памятью.

ИзопропилandreybsВсе управление классами делается на базе внешнего статического класса (экономим на таблице методов в каждом классе).
ничего не экономим - все экземпляры класса используют одну общую таблицу методов


Возможно, тут я не разобрался пока. Мне казалось, что чем больше методов содержит класс, тем больше ссылок на них он должен содержать. Если этот класс копируется много раз в памяти, то вынос методов в отдельный статический класс позволит сэкономить на этих ссылках. Ну, как минимум, код стал на порядок читабельнее и масштабируеме при добавлении в алгоритм новых возможностей вычислений.

Изопропилandreybs1. Нужно ли ставить Parent=null, чтобы разорвать сильные связи объектов и облегчить работу сборщика мусора.
облегчить таким способом нельзя. Если на экземпляр класса в программе нет никаких ссылок - мусоросборщика не волнует, на кого ссылается этот экземпляр. Рихтера почитайте.


Это хорошо, т.к. эти ссылки у меня readonly... :)

Изопропилandreybs2. Нужно ли ставить Links.Capacity=0 после очистки массива, чтобы высвободить память для повторного использования новым объектом.
нет, не нужно. Capacity влияет только на начальное выделение памяти для списка

Ясно. Жаль, я надеялся влиять таким образом на очистку памяти до прихода мусорщика.

ИзопропилandreybsНо хотел бы сделать это на С++. Но собрать сборку, которую схавает SQL пока не получилось.
и не получится. MSSQL схавает c++ только сборку safe или pure.Смешаную - никак.
А по возможностям в этом случае не будет разницы между managed c++ и c#


А вообще-то c# поддерживает работу с неуправляемыми указателями

Да, знаю, в области unmanaged. Я пока не разбирался с деталями импорта таких сборок, знаю только что "в лоб" они не импортируются в sql. Он ругается, что нужны расширенные права для владельца сборки и еще что-то там... Наверное, это решаемо, просто пока не добрался до этого. Сначала нужно будет разобраться с использованием памяти. Если сборка мусора при интенсивной работе с памятью будет снижать производительность, то C# не спасет даже указатели в области unmanaged, т.к. указатели нужно хранить в отдельном массиве, а это еще большие расходы памяти (если хранить указатель на каждый аргумент, как я писал выше).

Изопропилandreybsто C# не спасет даже указатели в области unmanaged, т.к. указатели нужно хранить в отдельном массиве
никаких лишних массивов
память под свою неуправляемую кучу попросить у операционной системы(Marshal.AllocHGlobal например)
указатели неплохо хранятся в unsafe struct
как в типизированом, так и в нетипизированом виде (void*)
может потребоваться хранение в виде ulong(с приведением к void* или к чему надо и обратно)



andreybsони будут полностью пересобираться на основе данных в БД, т.е. старые объекты будут отчуждаться
замечательно - можно иметь примитивный аллокатор и грохать всё ненужное простым вызовом Marshal.FreeHGlobal


Интересный способ, буду иметь ввиду. Один только вопрос - к чему прикрутить "деаллокатор"? Ведь деструкторы в C# не принято использовать, чтобы не замедлять мусорщика. Или все таки сделать один деструктор только для управляющего класса, объекты которого не пересоздаются все время?

ИзопропилP.S. Надеюсь, под 64 бита хозяйство?

Конечно... :)

MasterZivЧто ж делается-то на свете?
Что ж так плохо то все?
Автор, может тебе какую-то задачу попроще взять для начала?
А то класс от объекта не отличаем, а уже сразу ESP для mssql писать беремся?
Ты возьми хоть на голом шарпе напиши сначала все, данные хоть из файла, хоть константами в программу вбей, отладь, потом уже в сервер суй.
Оно может и без сервера тебя утроит.

Если вам что не понятно, спрашивайте, я поясню... А истерики и наезды нам точно не помогут.

Изопропилэтим советом MasterZivна голом шарпе напиши сначала все воспользуйся, 10000*20 - не так много памяти занимает, а главное - не начинай преждевременную оптимизацию

Я уже сделал это. Все работает достаточно быстро. Сейчас я рассматриваю варианты оптимизации с использованием unsafe кода. Поскольку с C# работаю впервые, то его нюансы работы с памятью мною пока не освоены.

У меня вопрос немного в сторону от темы - можно как-то обратиться по индексу (не ключу) к элементам словаря Dictionary?

Изопропилandreybsможно как-то обратиться по индексу (не ключу) к элементам словаря Dictionary?


это точно то что требуется? Может просто перебрать словарь как IEnumerable<T> нужно без всяких индексов?

Да, это то что нужно. Но такого метода не существует. Почему не годится перебор - потому что во время вычислений нужно попеременно осуществлять перебор то в одном, то в другом направлении. Для максимально быстрой работы реализовать это можно только через прямой индекс (порядковый номер) и for и ни в коем случае не через сортировку и feach. При этом в момент генерации структуры для вычислений активно используется поиск по ключу, поэтому в кое-где приходится использовать словарь. В идеале нужен массив, удовлетворяющий следующим критериям:
- динамическая структура (только добавление объектов)
- поиск по ключу сложности О(1) (в качестве ключа используется одно из свойств объекта)
- поиск по индексу сложности О(1) (в качестве индекса используется порядковый номер при добавлении в массив)

К сожалению, не нашел таких массивов, поэтому где-то использую List<T>, а где-то Dictionary<T>.

И еще вопрос по поводу затрат на упаковку/распаковку обращение по ссылкам.
Что из этого будет менее затратным при многократном вызове:

Вариант 1:

for( int i=0; i<20; i++)
ObjectA[1].Data.Value += ObjectB[i].Data.Value * ObjectC[i].Data.Value;

Вариант 2

Double x;
for( int i=0; i<20; i++)
x += ObjectB[i].Data.Value * ObjectC[i].Data.Value;
ObjectA[1].Data.Value = x;

В варианте 1 вроде не должно быть упаковки/распаковки, т.к. значения прямо из кучи должны писаться в регистры CPU для вычисления, но мало ли... Зато много двойных переходов по ссылкам объект.объект.значение.

В варианте 2 здесь должна быть распаковка при каждом "+=", но всего одна упаковка в самом конце.

Какова цена обращения по ссылке по сравнению с распаковкой?

beg-in-erandreybs Что из этого будет менее затратным при многократном вызове:

ловля блох. это не оптимизация.

При вызове 1000 или даже 10тыс раз - да. А при вызове 10млн или 100млн раз это ооочень заметно. Там даже лишний if заметен. не нужно недооценивать то, с чем не сталкивались.

Изопропилbeg-in-erне зная , что там у тебя за расчёт
топикстартер, не темни, выдай начальную задачу. И про освоение инструмента не забывай

Изначальная задача - реализация нейросети прямого распространения с обучением методом обратного распространения ошибки. Нейросеть произвольного размера, т.е. с любым кол-вом входов, выходов, слоев, синапсов. Это что-то меняет? :)

beg-in-erне зная , что там у тебя за расчёт но моя практика оптимизации математических задач говорит, что основное усилие надо приложить на оптимизацию самого алгоритма. если его тряхнуть скорость может вырасти качественно. ну и разумеется старатся отказываться от тормознутых Ienumerable в пользу чистых массивов.


"Чистые" массивы это Array[]? Или ты вообще про С++ говоришь? Если первое, то я понимаю, что нужно их использовать, но не получается, т.к. не знаю заранее их размера. Я на эту тему уже извелся... :(
У меня два варианта:
1. Загрузить все данные из БД в большие массивы, а затем их раскладывать по маленьким массивам Array[]. Минус в том, что при регистрации связей между объектами придется делать многократный фулскан по большим массивам, выбирая связи, относящиеся к конкретному объекту.
2. Обрабатывать считанные данные из БД построчно, раскладывая их по динамическим массивам List<T>. Минус в том, что приходится использовать динамические массивы, а не "чистые". И еще минус в том, что выделение памяти пообъектно должно работать медленнее, чем выделение памяти для всего массива сразу.

Сейчас я обдумываю третий вариант - сначала загрузить из БД статистику объектов (кого есть в каком кол-ве с каким кол-вом связей). Затем создать структуру в программе. Затем заполнить ее данными из второго обращения в БД.

beg-in-erС++ быстрей шарпа где то раза в 2. и кстати 32 битные приложения могут работать заметно быстрее 64 битных.


Раз уж подняли вопрос про С++ снова, давайте его добьем...

Открываем VS2012, создаем проект Visual C++ / CLR / библиотека классов. Заходим в "Свойства проекта" / "Свойства конфигурации" / "Поддержка общеязыковой среды CLR" выбираем "CLR-поддержка чистого MSIL (/clr:pure)". Компилим, импортируем в MSSQL2008.

CREATE ASSEMBLY for assembly 'TestCPP' failed because the assembly is built for an unsupported version of the CLR runtime.

Далее меняем на "CLR-поддержка безопасного MSIL (/clr:safe)".

CREATE ASSEMBLY for assembly 'TestCPP' failed because the assembly is built for an unsupported version of the CLR runtime.

"Поддержка CLR-среды (/clr)"

CREATE ASSEMBLY for assembly 'TestCPP' failed because assembly 'TestCPP' is malformed or not a pure .NET assembly.
Непроверяемый заголовок PE/собственная заглушка.

Брехня. Собрано на базе .Net 2.0. Должно подходить для MSSQL2008.

Короче, не работает. Ваши предложения, по настройке проекта?

beg-in-erandreybsЭто что-то меняет? :)
ну как бы да.
причём тут БД? мну кажется ошибка где то тут, и оптимизировать надо начиная с этого места.


Ну нейросеть то не в воздухе висит, ей данные нужны, а они подготавливаются в БД. Таблицы с миллионами записей... БД в самый раз.


beg-in-erчистый массив это типа int[]
у массива есть свойство Resize. размер всегда можно поменять как в С.


Ну здрасьте. Цитирую документацию - этот метод создает новый массив и копирует его на место старого. Операция сложности О(n). Для сравнения List<T>.Add сложности O(1). Ну и где тут преимущество на массиве, скажем, из 1000 элементов?

beg-in-erавтор Минус в том, что при регистрации связей между объектами придется делать многократный фулскан по большим массивам, выбирая связи, относящиеся к конкретному объекту.
ну эта работа для словаря. правда он довольно прожорлив по памяти. им можно попользоваться для установки связей и удалить.


Супер! Его я использую в некоторых случаях. Но не нравится он мне, т.к. не умеет извлекать элемент по индексу. Не нравится. :)

beg-in-erне скажу что задача плёвая, но ничего особого сложного из себя , на первый взгляд не предствляет. это же не NP полная задача.
во что ты с ней дальше творишь...

А дальше это будет кластер нейросетей. Поверь, я готов каждую запятую учесть, чтобы не потерять в производительности.