Есть потребность в реализации высокопроизводительного алгоритма для математических вычислений на основе данных MSSQL. Результаты вычислений так же сохраняются в MSSQL.

Первая версия алгоритма реализована на T-SQL. Оптимизация программы показала невозможность избавиться от операций записи в журнале транзакций даже при отказе от использования физических таблиц в процессе расчета. Вывод - вынести расчет за пределы SQL Server.

Вторая версия алгоритма реализована на C# в виде CLR-сборки (Safe/DLL) под .Net 3.5. Производительность повысилась на несколько порядков. Однако ряд ограничений C# не позволяет добиться максимума производительности.
1. Сборщик мусора не позволяет самостоятельно удалять объекты, а их в процессе вычислений создается целая куча -> перерасход памяти.
2. Тип структур является типом данных и не может быть использован для построения индексных массивов (с элементами типа ссылки на структуру), что приводит к использованию классов вместо структур, а значит перерасходу памяти и возможному снижению производительности.
3. Требуется кодогенерация (переопределение математических функций) при создании экземпляра объекта. В C# - это делегаты, анонимные и лямбда-методы. В С++ это просто ссылка на функцию. Существует большое отличие с точки зрения производительности при использовании этих подходов.
4. Судя по тестам в Интернете C# существенно уступает С++ в производительности математических программ.
Вывод - сделать CLR-сборку на C++.

Проблема в том, что в VS2012 ultimate я не нашел типа проекта SQL CLR для VC++. Есть только шаблон SQL Server для C# и VB.NET. Когда я пытался собирать DLL на базе шаблона C++ CLR, то какие бы я ни ставил настройки компилятора, MSSQL2008 всегда отказывался импортировать сборку по самым разным причинам.

Вопросы:
1. Что думаете по поводу описанных выше недостатков C#. Я не писал на нем ранее, поэтому могу многого не знать и делать неверные выводы.
2. Был ли опыт создания CLR-сборок для MSSQL на C++? На MSDN есть примеры кода для VS2008, которые не работают в VS2012. Неужели нужно даунгрейдить VS???
3. Стоит ли использовать связку MSSQL->CLR на C#->DLL на C++? Здесь C# будет использоваться только для обращения к БД и передаче данных в DLL на C++ для вычислений.

Буду признателен, если укажете ссылки на тематические статьи в Интернете или примеры кода/настроек компилятора VC++.
Спасибо!

xstoredandreybs,

Я бы не заморачивался с CLR а создал бы обычную extended stored procedure на C

Я тоже сначала думал проапгрейдить SQL до 2012 и использовать его возможности инлайн-процедур. Но одной процедурой не обойтись. И сохранять промежуточные результаты нужно в независимой области памяти для быстрого повторного обращения к ним. Все таки это должна быть внешняя библиотека.

ИзопропилandreybsИ сохранять промежуточные результаты нужно в независимой области памяти для быстрого повторного обращения к ним.
ещё один источник геморроя с CLR

Проблема только в неуправляемости процессом освобождения памяти. Там есть свои "лазейки", но в С++ это делается просто и наглядно. Поэтому и хочется найти возможность собрать CLR-сборку на С++.

Изопропилandreybs,

соберите её без всяких визардов, как unsafe регистрируйте на сервере

Пробовал, не получилось. SQL Server в этом случае ругается, что сборка не является нативной .NET (хотя я использовал библиотеки .Net 2.0.0.0).

ИзопропилandreybsSQL Server в этом случае ругается, что сборка не является нативной .NET
регистрируемая сборка должна компилироваться с /clr:pure, а дальше эта сборка может уже обращаться к нормальному коду через P/Invoke

Начиная с MSSQL2005 это не поддерживается для VC++, если верить MSDNу

MasterZivandreybsпропущено...


Проблема только в неуправляемости процессом освобождения памяти. Там есть свои "лазейки", но в С++ это делается просто и наглядно. Поэтому и хочется найти возможность собрать CLR-сборку на С++.

А тебе зачем собственно CLR ?

Потому что вызов пересчета должен происходить изнутри SQL Server, а он использует либо CLR, либо unsafe сборки. Последнее заколебешься дебагить в случае ошибки. Хотя и это ограничение можно обойти, собрав простое консольное приложение на С++ (в перспективе виндовс-сервис), которое лезет в сиквел и делает тоже самое, что и CLR на C#. Но тут сложность - как управлять этим консольным приложением. В конечном счете основную часть кода можно будет вынести в DLL и дебагить ее с помощью вызова из консольного приложения, а в рабочем режиме эта DLL будет цепляться к SQL как unsafe сборка с external или unrestricted access. Как то так, но до этого еще не скоро. Сначала отлажу алгоритм на C# и посмотрю на результаты. Может овчинка выделки не стоит...

ИзопропилandreybsНачиная с MSSQL2005 это не поддерживается для VC++, если верить MSDNу
Поддерживается (сборки /clr:pure)


Технически да, поддерживаются, но с целым рядом ограничений , которые в моем случае не позволят обеспечить прямое взаимодействие SQL<->DLL, только через интерфейсную прослойку SQL<->DLL/CLR<->DLL/Unmanaged. Это возможно, но очень геморно с точки зрения дебагинга, о чем я писал выше. Если проигнорировать ограничения, то при импорте такой DLL/CLR MSSQL выдаст ошибку - "unsupported clr code", а если /pure заменить на /safe, то даже не используя элементы unmanaged code все равно при импорте вылетает ошибка " assembly not supported " вне зависимости от того, на базе какой версии .Net это все собрано.


ИзопропилUNSAFE enables assemblies unrestricted access to resources, both within and outside an instance of SQL Server. Code running from within an UNSAFE assembly can call unmanaged code.
http://msdn.microsoft.com/en-us/library/ms189524.aspx

P.S. крики о deprecated extended stored procedure слышны уже много лет

Да понятно, но лично я не встречал юзабельных возможностей по поддержке deprecated SP в mssql. Говорят, в 2012 они тали лучше. Не знаю, посмотрим. Но судя по документации, в которой нет примеров на c++, только c# и asp.net, Майкрософт развивает свою технологию clr в связке с .Net и им нафиг сдалось поддерживать c++ с его unmanaged кодом. Так что писать библиотеки для mssql на c++ становится все сложнее и сложнее.

ИзопропилВопрос замены сервера на PostgeSQL не рассматривался?

Не рассматривался. В MSSQL реализованы алгоритмы обработки данных, на базе которых далее производятся вычисления. Объемы данных довольно большие. Тут нужна мощная СУБД.

MasterZivandreybs,

Про С++ тут нет ничего. Перенесу тему в C#, если нет возражений.

Не возражаю.

Модератор: Тема перенесена из форума "C++".

Изопропилandreybs, что приводит к использованию классов вместо структур, а значит перерасходу памяти и возможному снижению производительности.
сколько байтов считали?

Добавляет ли readonly property к размеру класса?

Точно не считал, но оптимизировал как мог, чтобы сохранить читабельность кода при минимуме размеров. В итоге получилась примерно такая модель:

struct D
{
... 5-7 переменных типа Int32 и Double
}

Class C
{
T Parent; // ссылка на родительский объект
List<T> Links; // 10-20 связей на каждый объект
D Data; // структура с данными
C(...) { конструктор }
}

Выделил 4 типа данных T, для каждого из которых применил подобную модель. Всего одновременно живет до 1000 объектов (пока, в перспективе до 10000). За счет перекрестных ссылок все данные представлены одновременно в иерархическом/сетевом (для вычислений) и плоском представлении (для импорта/экспорта). Все управление классами делается на базе внешнего статического класса (экономим на таблице методов в каждом классе). Использовать структуры не получится, т.к. для создания перекрестных ссылок нужно ссылаться на объект из нескольких индексных массивов одновременно.

В этом все деле меня больше всего интересует освобождение памяти после отчуждения объектов (на примере класса выше):
1. Нужно ли ставить Parent=null, чтобы разорвать сильные связи объектов и облегчить работу сборщика мусора.
2. Нужно ли ставить Links.Capacity=0 после очистки массива, чтобы высвободить память для повторного использования новым объектом.

ИзопропилWinnipuhSQLCLR есть и надо пользоваться.
так топикстартеру не нравится.

Я не против. Но хотел бы сделать это на С++. Но собрать сборку, которую схавает SQL пока не получилось.

Изопропил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 полная задача.
во что ты с ней дальше творишь...

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

ИзопропилandreybsКороче, не работает. Ваши предложения, по настройке проекта?
блд, русским языком говорил - /clr:safe или /clr:pure

Да блин, а это что? 38 попугаев??

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

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


Строка компоновщика:

/Yu"stdafx.h" /GS /analyze- /W3 /Zc:wchar_t /Zi /Od /Fd"Debug\vc110.pdb" /fp:precise /D "WIN32" /D "_DEBUG" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Oy- /clr:pure /FU"C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll" /FU"C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll" /FU"C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll" /FU"C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll" /MDd /Fa"Debug\" /EHa /nologo /Fo"Debug\" /Fp"Debug\TestCPP.pch"

Только толку от этого нет. Работает только через Platform Invoke. А это черте-что цеплять DLL на C#, которая цепляет другую DLL на С++. Как этого монстра дебагить ваще не ясно.

Изопропил- только возможкности ничем не будкут отличасться от c#

Вот именно. CLR он и в африке CLR. Тогда что говорить о том, что код С++ в два раза быстрее?

SeVaЕсли нужно быстродействие,то зачем какие-то бубны со сборками в sql server?

Ваши варианты? Пользовательское приложение? Я пока не придумал, как взаимодействовать с ним из БД. Предполагается, что источник вызова на вычисление - ХП в БД.

ИзопропилandreybsПредполагается, что источник вызова на вычисление - ХП в БД.
попробуйте вызвать ХП из клиентского приложения.

Это кажется более разумным, чем WCF. Как-то не верится, что HTTP-шная прослойка (мы же о веб-сервисах горовим, если я не ошибаюсь) обеспечит быстрое взаимодействие со сборкой. Возможно, перенос управления в модуль C++ (клиентское приложение) будет самым производительным и верным решением. Попробую реализовать такой вариант, посмотрим, как это повлияет на производительность.